fix: pointer-events when content has CSS animations #173
Conversation
|
Fails in Safari and iOS Safari. Needs a bit more work. (Edit: fixed) |
Makes modal state and focus restoration behaviour synchronous (without depending on possible closing/opening animation being finished).
| if (event && event.target !== this) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
This part is most of the fix. This makes overlay ignore any unrelated animationend events that might be triggered by anything inside the dialog (e.g. if using <vaadin-text-area> inside the dialog which triggers a CSS animation on init).
| if (!this.modeless) { | ||
| this._enterModalState(); | ||
| } | ||
| this.removeAttribute('opening'); |
There was a problem hiding this comment.
Removing the opening attribute was moved to be the very last thing in finishOpening() so we can use it (e.g. in MutationObserver) to detect when the opening has been completely finished (including possible animations).
Other stuff (the modal state update) was moved out of this method to be run earlier/synchronously as it doesn't need to be tied to the completion of the possible animation.
There was a problem hiding this comment.
Similar changes to finishClosing() below.
There was a problem hiding this comment.
In my opinion, this refactor is important, in the future, we can use the opening/closing to check something because we know the status state: opening/ opened or closing/closed.
This fix addressed the bug and refactored code better. Thank you for the great fix.
| // Disable pointer events in other attached overlays | ||
| OverlayElement.__attachedInstances.forEach(el => { | ||
| if (el !== this && !el.hasAttribute('opening') && !el.hasAttribute('closing')) { | ||
| if (el !== this) { | ||
| el.shadowRoot.querySelector('[part="overlay"]').style.pointerEvents = 'none'; | ||
| } |
There was a problem hiding this comment.
This was simplified a bit as this works like this now with the updated logic above. Now pointer-events: none might also be applied to closing or opening overlays here but that should be fine. Closing dialogs will remove it themselves after the closing animation finishes (in finishClosing()).
| <dom-module id="overlay-test-styles" theme-for="vaadin-overlay"> | ||
| <template> | ||
| <style> | ||
| :host([animate][opening]), | ||
| :host([animate][closing]) { | ||
| animation: 50ms overlay-dummy-animation; | ||
| } | ||
|
|
||
| @keyframes overlay-dummy-animation { | ||
| to { | ||
| opacity: 1 !important; /* stylelint-disable-line keyframe-declaration-no-important */ | ||
| } | ||
| } | ||
| </style> | ||
| </template> | ||
| </dom-module> |
There was a problem hiding this comment.
This is an animation similar to what vaadin-dialog applies on the dialog overlay (where the issue was found using vaadin-text-area in vaadin-dialog).
Fixes #158
Fixes vaadin/vaadin-dialog-flow#152