Welcome to the JavaScript feedback portal. We’re happy you’re here! If you have feedback on how to improve the JavaScript, we’d love to hear it!

  • Check out the features or bugs others have reported and vote on your favorites. Feedback will be prioritized based on popularity.
  • If you have feedback that’s not listed yet, submit your own.

Thanks for joining our community and helping improve Syncfusion products!

0
Votes

Hi,

I noticed some weird behaviour with dialog z-indexes when I was testing my application under chrome - they were all having their z-index set to 2147483647.

Inspecting the DOM I could see that under the body element there was a div with that as the zindex that was showing the content as "#shadow-root (closed)". After a bit of investigation I tracked that div element as coming from the PassBolt password manager extension I had installed in Chrome. I gather that sometimes browser extensions may inject a host element to have a shadow dom under, and in this case the PassBolt extension is giving the host element the highest z-index possible. getZindexPartial in popup.ts seems to scan all children of the body element to find the highest z-index of those to include in its z-index calcuations even when the parent of the popup is not the body (i.e. target is not body) and those children are not ancestors of the popup parent. There's no comment in the code visible to me so I do not know why getZindexPartial does that - it means that if an application using EJ2 popups is self-contained under a dom node that is not the body it will still get affected by the z-index of dom nodes under the body that are nothing to do with the application (including those injected by browser extensions).

Looking at the code for getZindexPartial I can see that it ignores children of the body where their z-index is 'auto' or their position is 'static'. If there is a good reason for factoring in the z-index values of children of the body even when the popup parent is not the body then changes that would stop it picking up the z-index from inject shadow dom host divs that are injected the same way as the PassBolt extension could be to do one or both of:

  • Also ignore elements where their position is "fixed" (in addition to "static" which are already ignored)
  • Ignore elements where their z-index is the maximum z-index already of 2147483647 - it's impossible to insert an element with a higher z-index so there's nothing lost by just ignoring them (as factoring that in will cause the z-index values of all popups to then also be 2147483647)
To experience the same issue that I'm seeing you'd need to install the PassBolt browser extension and then access page with some EJ2 popups. However I can simulate the issue by taking one of your dialog demos that uses nested dialogs and including a div under the body that's style the same as the one PassBolt injects.

You can see that example here.

The outer dialog has a parent of the container element, but if you inspect it you can see that getZindexPartial has allocated both it and the inner dialog the same z-index of 2147483647 because of that other child of the body with that as the z-index. The expected behaviour would be that the z-indexes of those two dialogs is not 2147483647 and are calculated without factoring in that unrelated child of the body.

Note that this demo visually looks ok just because the dialogs are nested, in my application where I have multiple dialogs that aren't nested but should overlay depending on show order they can easily end up stacking in the wrong order because they're all being given the same z-index due to this issue.