-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Should "show popover" assert the element's popover invoker is null? #9383
Comments
showPopover()
updates the invoker
|
@annevk be aware that |
Ah right, I think it can assert it then, looking at the callers. |
Seems like a reasonable assertion to add given "hide popover" sets the invoker to null. |
@josepharhar @mbrodesser-Igalia Would either of you be interested in making the spec PR? |
@nt1m yes, will do it. |
I tried adding this assert in chromium, but it got hit in popover-invoker-reset.html. In popover-invoker-reset, showPopover sets an invoker but then aborts showing the popover because the beforetoggle event handler prevents default, which then leaves us in the state where the popover has an invoker set but is closed. By calling showPopover again, the assert will be hit. If we still want this assert then we need some way of clearing out the invoker at every exit point in showPopover or something. |
Should the invoker be asserted and manipulated after the "check popover validity" step? |
I think that wherever we put the assert doesn't matter. As long as it's possible to have the popover's invoker set to something while the popover is closed, I believe it will be possible to hit the assert |
@josepharhar: thanks for the explanation.
Yes, that should work. Alternatively: postpone setting element's invoker to to invoker immediately after setting element's visibility state to showing and pass the invoker as an argument to https://html.spec.whatwg.org/#topmost-popover-ancestor and use it there. That will be correct, because:
|
Anyone an opinion on the two proposals (#9383 (comment) and #9383 (comment))? |
I prototyped this and it seems to work, so I am supportive. Lets do it! What was the motivation for adding this assert in the first place though? Is it just that we shouldn't have an invoker set while the popover is closed because that state could be confusing?
What did you mean by this? |
Okay, will create a spec-patch.
Yes, exactly.
If the invoker element was supposed to stay (that is, non-null) and then be replaced by another non-null element. |
…tate to "showing" See <whatwg#9383 (comment)>. Fixes whatwg#9383.
…r" algo. r=emilio See <whatwg/html#9383 (comment)>. Differential Revision: https://phabricator.services.mozilla.com/D182709
…r" algo. r=emilio See <whatwg/html#9383 (comment)>. Differential Revision: https://phabricator.services.mozilla.com/D182709 UltraBlame original commit: 0b5333b2ef93c5e4153ac198b577c6f54c5ad538
…r" algo. r=emilio See <whatwg/html#9383 (comment)>. Differential Revision: https://phabricator.services.mozilla.com/D182709 UltraBlame original commit: 0b5333b2ef93c5e4153ac198b577c6f54c5ad538
…r" algo. r=emilio See <whatwg/html#9383 (comment)>. Differential Revision: https://phabricator.services.mozilla.com/D182709 UltraBlame original commit: 0b5333b2ef93c5e4153ac198b577c6f54c5ad538
…r" algo. r=emilio See <whatwg/html#9383 (comment)>. Differential Revision: https://phabricator.services.mozilla.com/D182709
At https://html.spec.whatwg.org/#show-popover before step 2. Or is it supposed to be replaceable?
The text was updated successfully, but these errors were encountered: