-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Popovers are broken when shown in a contextmenu
event listener
#10905
Comments
Perhaps the light dismiss behavior should be tweaked to not close any popovers that are shown immediately before in |
Maybe wrap it in a |
That doesn't work in Chrome, FF or Safari. Once you increase the timeout to at least 100ms, then it sometimes works. But at that point you start to have a noticeable delay. |
Ah, interesting. I just tested it, the reason is because To test this, try wrapping the What's also interesting is it doesn't seem that the "close popovers on click/mouseup" can be canceled. At least no combination that I tried with canceling click/mouseup/pointerup resulted in canceling the popover close. So that doesn't seem like a viable option either.
|
Found a workaround by using document.querySelector('span')?.addEventListener('contextmenu', (event) => {
event.preventDefault();
});
document.querySelector('span')?.addEventListener('mouseup', (event) => {
if (event.which === 3 || event.ctrlKey) {
document.querySelector('[popover]').showPopover();
}
}); No |
This sounds similar to #10890 (comment). |
Yeah, we are running light dismiss kind of unconditionally whenever there is a pointerup event. Maybe we should add a flag for the case that a popover is shown in between pointerdown and pointerup and skip doing light dismiss in that case? I don't think that would help with #10890 (comment) though. |
Interesting bug!
Yeah, this sounds like a good solution to me. Might be tricky to keep track of which popover(s) were open, but we can probably do something. Does this sound like a reasonable solution to others?
Perhaps it could, basically if we keep track of the list of open popovers during pointerdown, and compare to pointerup, and exempt any popovers that changed (either direction) from the light dismiss behavior? |
Another solution is to check for the event button of the pointerup event? (Just to be clear, I don't have a strong preference on how to resolve this, just throwing options out there) |
Sounds interesting, but help me understand. In the repro for this issue, the pointerdown and pointerup both happen on the same |
If you right click, there should be a different event.button used right? Why should right click trigger light dismiss in the first place? |
If you mousedown over the span, move the mouse elsewhere and then release when it's not over the span, it still light dismisses. Aside from technical questions: a common way to invoke a context menu item is to mousedown, hover over a specific menu item and the release. |
Ahh, mouse "button", not "the
You mean right-mouse-down, etc.? Yeah, mouse drags also (per spec) light dismiss the popover, unless the drag starts or ends on the popover. That's so that you can e.g. select text on the popover.
That is common, at least on Mac platforms. I do think we should work on a solution to this issue. I'd love to make that solution also fix #10890 (comment). |
What is the issue with the HTML Standard?
https://codepen.io/jpzwarte/pen/OPLQypz?editors=1010
If you want to use a popover for a context menu, you cannot use the
contextmenu
event to display the popover. The problem is that the popover is immediately light dismissed.(not sure if this belongs in whatwg/html or whatwg/dom)
The text was updated successfully, but these errors were encountered: