Hi

I have more info about this problem.

It is due to the CSS element <div class="msdlgOverlay" with a display:blocked being called when the Nintex dialog opens.

I've sent a support request to Nintex but if anyone else has a quick workaround that would be helpful

Cheers

Laurie

Hi Laurie,

Are you running a custom theme in your Sharepoint? 

Thanks

Mike

Yes

I've also experienced this issue when the forms of the list are configured to be modal.

The issue appears randomly and it depends on the browser used (sometimes only in IE, sometimes only in Chrome...).

It is due to CSS and more precisely to the z-index property.

Do you experience the same behaviour ?

Let us know the feedback from Nintex support.

Thanks,

Caroline

Hi Caroline,Mike

Thanks for taking the time to reply.

My issue is to do with the grey shading that is applied when a pop up window appears i.e. a Nintex form is opened.

Sometimes the Form will remain greyed over.

I "fixed" my issue by using some custom CSS to disable the grey pop up. This fixed all my issues and now opening Nintex Forms works over slow connections and the sharepoint edit button opens the Form in edit mode correctly every time. Nintex engineers are looking at the issue and I will post their answer

Here is what I added to company Style library CSS file ( I know that !important is poor form)

div.ms-dlgOverlay {

display:none !important;

}

Awesome and thanks for sharing! I was going to suggest adding in some CSS but I wasn't sure what tag you'd have to accommodate.   Reason being I saw similar things happen when a custom theme was in place and usually the CSS is the culprit.

From what I can tell, if 'Launch forms in a dialog' (Advanced list setting) is set to Yes, then JavaScript code runs and sets the z-index of ms-dlgOverlay to be greater than the preceeding div with the class ms-dlgContent. Within this ms-dlgContent div is the iframe that holds the Nintex form. Within the form itself, if you set a custom style to try to elevate the z-index of ms-dlgContent, decrease the z-index of ms-dlgOverlay or try to hide it all together, as it is within an iframe the CSS rules it will not trigger.

The simplest fix is to update the advanced settings of the list and specify that forms should not load in a dialog, but if you want to keep the forms loading in a dialog, then add the following Custom JavaScript to your form:

NWF$(document).ready(function(){

   parent.$('body').find('div.ms-dlgOverlay').css('z-index', '1500');

});

What realy seems strange to me is that the z-index of the ms-dlgOverlay "randomly?" changes. Sometimes it is set to 1504 and everything works fine, and sometimes it is set to 1509, which causes the unwanted effect of the dialog beeing covered.

I have not been able to find out what/where/who actually assigns the value. Can anybody help clear this up?

Regards

Leif

Actually there can be several modal dialogs opened, that's why the z-index is automtically calculated and is not a fixed value.

I don't how it is calculated but you can use javascript in your Nintex Forms to get the z-index of the current modal dialog and then decrease the z-index of the overlay.

Hope this helps

I use this code to examine and set the z-index:

NWF$(document).ready(function(){

var overlay =     NWF$('.ms-dlgOverlay');

var dialogue = NWF$('.ms-dlgContent');

console.log("z-index of overlay before: " + overlay.zIndex());

console.log("z-index of dialogue before: " + dialogue.zIndex());

    NWF$('.ms-dlgOverlay').zIndex( '1500');

    NWF$('.ms-dlgDialogue').zIndex( '1600');

console.log("z-index of overlay after: " + overlay.zIndex());

console.log("z-index of dialogue after: " + dialogue.zIndex());

});

Strangely, my console output reports 0 on both elements, both before and after:

When I then examine the actual values through the browsers DOM explorer I get this:

Is there something wrong with my code, or is there another explanation for z-index not beeing available?

I run the code at NWF$(document).ready...

Maybe this is "too soon" because there is an algorithm somewhere in Sharepoint that tries (and fails) to assign some meaningfull z-index values?

Is there and alternative to (document).ready that is "a bit later"?

Regards

Leif

You can try to execute your code at this event :

NWF.FormFiller.Events.RegisterAfterReady(function(){

// Add your code here

});

OK - I think I got it now:

NWF$(document).ready(function(){

   var dialog  = window.parent.document.getElementsByClassName('ms-dlgContent')t0].style.zIndex = 1510;

});

The problem with the code I tried before, seemed to be that I was not succesfull in actually getting to the right elements, since the dialogue itself was in an IFRAME. This is why the "window.parent..." is needed, instead of just looking in the current document with NWF$.

That is actually also what Alan suggested with his code: parent.$('body').find('div.ms-dlgOverlay').css('z-index', '1500');

But when I tried that, I got an error that the "$" was unknown. That got me sidetracked, and I only now got back to examining the parent.

Out of curriosity - why can I not refer $? ANd given that i CAN refer NWF$, how would my jquery syntax be to accomplish the same thing?

Regards

Leif

Exactly that's a great idea to get it from the parent window.

Nintex has added his own version of JQuery that's why NWF$ (Nintex' JQuery version) is available and not $. But standard JQuery ($) is included in SharePoint 2013. The version included by SharePoint may not be already loaded when document ready event fires or to avoid JQuery conflict, it is maybe not available when NWF$ is included (I'm not sure about this point).

So, the syntax would be parent.NWF$('body').find('div.ms-dlgOverlay').css('z-index', '1500');

Hope this helps

[if IE 9]  endif] 

While I appreciate that there's an Accepted Solution, this is not actually a solved issue.  Any idea if Nintex is planning to actually fix the problem?  It's been years, and it's an issue with the modern forms, too (which don't accept custom code/script so easily).  I've tried adding the CSS into a hidden label field, but it does not resolve the issue.  Any thoughts would be welcome.

I happily bump that topic up one year later. Amazing how Nintex is just ignoring customer feedback.

I'll +1 needing this to be addressed in the core Nintex Forms (2019, please 🙂 ) product as well...

I'll add the solution that seems to work well for us (a combination of all of these answers with a brief 500ms delay just to be "safe"). Also, at least in our environment, parent.NWF$ is undefined so this code assumes that's likely globally true (YMMV):

Hello.  Nintex did respond to our request and rolled-out an update to correct the Z-layer issue.  If people are still experiencing the problem, but recommendation would be to ensure that the most recent updates have been applied, and then to contact Nintex's support team.