-
Notifications
You must be signed in to change notification settings - Fork 339
fix(zIndex-execution-during-local-init): update zIndex handling durin… #2640
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
fix(zIndex-execution-during-local-init): update zIndex handling durin… #2640
Conversation
…g initialization and extend tests
|
|
Resolve #2608 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.
Co-authored-by: Thijs Louisse <[email protected]>
tlouisse
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! 🙏
Can you maybe remove the checks with expect(ctrl.manager.shownList).to.have.lengthOf(1); ?
Or are thet relevant within these z-index tests?
| await ctrl.show(); | ||
| // @ts-expect-error find out why config would/could be undfined | ||
| expect(ctrl.content.style.zIndex).to.equal(`${ctrl.config.zIndex + 1}`); | ||
| expect(ctrl.manager.shownList).to.have.lengthOf(1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR looks good to me.
Any reason we should check for the shownList length here in these tests, instead of in the manager? https://github.com/ing-bank/lion/blob/master/packages/ui/components/overlays/test/OverlaysManager.test.js#L83
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
f I understand correctly, if there is more siblings, it always should have higher zIndex than the previous sibling by one. It's probably a little more than that. Let me know
|
@SebayK we discussed this in person, but I leave a comment here for transparency... This one needs a bit more investigation. I see we applied zIndex on 3 nodes (should have been one I think). Also: now that we moved to dialog, (n case it's configured as modal) it paints to the top layer. It will win from every other layer regardless of zIndex (that's what I expect). I think this should somehow be reflected in the tests. (this will play an even bigger role once we move to popovers for (local) overlays) |
fix(zIndex-execution-during-local-init): update zIndex handling during initialization and extend tests
What I did