Only use the used invoker to establish popover hierarchy#39560
Merged
chromium-wpt-export-bot merged 1 commit intomasterfrom Apr 18, 2023
Merged
Only use the used invoker to establish popover hierarchy#39560chromium-wpt-export-bot merged 1 commit intomasterfrom
chromium-wpt-export-bot merged 1 commit intomasterfrom
Conversation
wpt-pr-bot
approved these changes
Apr 14, 2023
Collaborator
wpt-pr-bot
left a comment
wpt-pr-bot
left a comment
There was a problem hiding this comment.
The review process for this patch is being conducted in the Chromium project.
4 tasks
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-4429412
branch
2 times, most recently
from
89dd9b7 to
ff37959
Compare
See [1] for more context, but the idea is that instead of using just the DOM structure to establish the popover hierarchy, the user's behavior should matter. For example, if one popover contains a popover invoker pointing to another popover, it should matter whether that invoker is *actually used* to open the second popover. An example: - Component 1 is a third party widget, which uses popover - Component 2 is another third party widget, also using popover - A page wants to use both components separately, from separate invoking buttons. - Component 1 also wants to be able to use Component 2, via a button within Component 1. In this example, the page should be able to still independently use these components. So a user clicking the page's button for Component 2 is expected to close Component 1 if it's open, because that's a direct invocation of Component 2. However, if the user clicks the button within Component 1 to get Component 2, it is natural to leave Component 1 open because this is a nested call. Important note: this often happens to be the behavior even before this CL, since the user clicking on the page-level Component 2 invoking button represents a light dismiss signal for Component 1, so it closes either way. But this CL simplifies the implementation considerably, removing the need to track all invokers on the page, and also removing the need to continuously check whether invoker relationships have changed. Spec PR: whatwg/html#9171 [1] whatwg/html#9160 Bug: 1307772 Change-Id: I60ccb133a79084db8c251218fdbd10684fea947b Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4429412 Commit-Queue: Mason Freed <masonf@chromium.org> Code-Coverage: Findit <findit-for-me@appspot.gserviceaccount.com> Reviewed-by: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1131606}
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-4429412
branch
from
ff37959 to
d20d911
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See [1] for more context, but the idea is that instead of using just
the DOM structure to establish the popover hierarchy, the user's
behavior should matter. For example, if one popover contains a popover
invoker pointing to another popover, it should matter whether that
invoker is actually used to open the second popover.
An example:
invoking buttons.
within Component 1.
In this example, the page should be able to still independently use
these components. So a user clicking the page's button for Component 2
is expected to close Component 1 if it's open, because that's a direct
invocation of Component 2. However, if the user clicks the button
within Component 1 to get Component 2, it is natural to leave Component
1 open because this is a nested call.
Important note: this often happens to be the behavior even before this
CL, since the user clicking on the page-level Component 2 invoking
button represents a light dismiss signal for Component 1, so it closes
either way. But this CL simplifies the implementation considerably,
removing the need to track all invokers on the page, and also removing
the need to continuously check whether invoker relationships have
changed.
Spec PR:
whatwg/html#9171
[1] whatwg/html#9160
Bug: 1307772
Change-Id: I60ccb133a79084db8c251218fdbd10684fea947b
Cq-Do-Not-Cancel-Tryjobs: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4429412
Commit-Queue: Mason Freed <masonf@chromium.org>
Code-Coverage: Findit <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1131606}