-
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
Close watchers: history-action user activation is consumed even for the first close watcher #10046
Labels
Comments
domenic
added a commit
that referenced
this issue
Jan 11, 2024
5 tasks
1 task
1 task
m-akinc
added a commit
to ni/nimble
that referenced
this issue
Feb 22, 2024
…1848) ## 🤨 Rationale There is a change to the HTML spec introducing the `CloseWatcher` API, which affects the way the native `dialog` element behaves. Recently, Chrome had released their implementation, and it broke our drawer and dialog (see issue #1713, as well as resulting [Chromium issue](https://bugs.chromium.org/p/chromium/issues/detail?id=1512224)). Though they rolled back their release of that feature (by moving it back to experimental), it will eventually be implemented in Chrome and other browsers in some form. We want to at least guard against leaving the drawer/dialog in a bad state. Also fixes #1445 ## 👩💻 Implementation The issue is that the `cancel` event is intentionally not fired in a couple cases where the `dialog` is dismissed with ESC. - One such case was when the there is no user interaction (e.g. clicking, scrolling) in the `dialog` before pressing ESC. Apparently, this is [viewed as a mistake and will likely be changed](whatwg/html#10046). - Another case that is [more fundamental to the `CloseWatcher` API](https://github.com/WICG/close-watcher#abuse-analysis) is when there are two ESC presses without an intervening user interaction. I have added a `close` event handler in both the drawer and dialog that resolves and clears the promise, if there is one still set. This ensures we are not left in a bad state where the drawer/dialog can't be reopened. Note there are still problems: - the drawer closes without animation (because we rely on the `cancel` event to trigger the animation) - the drawer/dialog can be closed with ESC even if `prevent-dismiss` is set Depending on the ultimate `CloseWatcher` specification, we may decide to deprecate the `prevent-dismiss` option. OTHER CHANGES: - Gave the dialog proper focus styling, rather than the default. ## 🧪 Testing I added tests for the specific case now being handled, though these won't currently be running against any browser versions that would exhibit the problem behavior. I did manual testing using a [version of Chromium](https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/1241130/) with the `CloseWatcher` API enabled. ## ✅ Checklist <!--- Review the list and put an x in the boxes that apply or ~~strike through~~ around items that don't (along with an explanation). --> - [x] I have updated the project documentation to reflect my changes or determined no changes are needed.
domenic
added a commit
that referenced
this issue
Feb 28, 2024
As noted in #10046, the close watcher anti-abuse measures were overly strict, and would prevent firing the cancel event even when the close watcher was created with user interaction. Additionally, the "is grouped with previous" infrastructure used to track close watcher groups was buggy, since close watchers could be destroyed and this would cause groups to spuriously collapse. To fix both of these problems, we re-do the close watcher anti-abuse protections. We now track the groups as a list-of-lists, and explicitly track how many groups should be allowed at a given time. We can then compare them when making decisions about whether to group a new close watcher, or whether to fire a cancel event. Note that the initial fix proposed in #10046 (and implemented in #10048) is incorrect, as it allows indefinite trapping of the user. Closes #10046.
5 tasks
domenic
added a commit
that referenced
this issue
Mar 14, 2024
As noted in #10046, the close watcher anti-abuse measures were overly strict, and would prevent firing the cancel event even when the close watcher was created with user interaction. Additionally, the "is grouped with previous" infrastructure used to track close watcher groups was buggy, since close watchers could be destroyed and this would cause groups to spuriously collapse. To fix both of these problems, we re-do the close watcher anti-abuse protections. We now track the groups as a list-of-lists, and explicitly track how many groups should be allowed at a given time. We can then compare them when making decisions about whether to group a new close watcher, or whether to fire a cancel event. Note that the initial fix proposed in #10046 (and implemented in #10048) is incorrect, as it allows indefinite trapping of the user. Closes #10046.
rubberyuzu
pushed a commit
to rubberyuzu/html
that referenced
this issue
Mar 21, 2024
As noted in whatwg#10046, the close watcher anti-abuse measures were overly strict, and would prevent firing the cancel event even when the close watcher was created with user interaction. Additionally, the "is grouped with previous" infrastructure used to track close watcher groups was buggy, since close watchers could be destroyed and this would cause groups to spuriously collapse. To fix both of these problems, we re-do the close watcher anti-abuse protections. We now track the groups as a list-of-lists, and explicitly track how many groups should be allowed at a given time. We can then compare them when making decisions about whether to group a new close watcher, or whether to fire a cancel event. Note that the initial fix proposed in whatwg#10046 (and implemented in whatwg#10048) is incorrect, as it allows indefinite trapping of the user. Closes whatwg#10046.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the issue with the HTML Standard?
Consider a case like
or
The intent of the close request and close watcher infrastructure introduced in #9462 was that the
cancel
event would fire for these close watchers, consuming the history user-action user activation that was created on clicking the button. Basically, close watchers can be used to extend the required number of back gestures/presses by 1; see this section of the explainer.However, the spec currently consumes the history user-activation created by clicking the button when establishing the CloseWatcher: https://html.spec.whatwg.org/#establish-a-close-watcher .
We should swap steps 3 and 4 in this algorithm, so that we only consume history user-activation if we've already used up the "one free close watcher" slot.
This will help ameliorate issues like https://bugs.chromium.org/p/chromium/issues/detail?id=1512224, where at least two web developers have managed to fall into the 0.000015% of page views cases that we determined was OK to break when merging #9462. (See also my summary comment on that bug.)
/cc @josepharhar @lukewarlow
The text was updated successfully, but these errors were encountered: