diff options
Diffstat (limited to 'testing/web-platform/tests/close-watcher/user-activation/README.md')
| -rw-r--r-- | testing/web-platform/tests/close-watcher/user-activation/README.md | 25 |
1 files changed, 25 insertions, 0 deletions
diff --git a/testing/web-platform/tests/close-watcher/user-activation/README.md b/testing/web-platform/tests/close-watcher/user-activation/README.md new file mode 100644 index 0000000000..b9aa9a2123 --- /dev/null +++ b/testing/web-platform/tests/close-watcher/user-activation/README.md @@ -0,0 +1,25 @@ +# Close watcher user activation tests + +These tests are all in separate files (or test variants) because we need to be +sure we're starting from zero user activation. + +## Note on variants vs. `-dialog` and `-CloseWatcher` files + +We endeavor to have all the tests in these files cover both `<dialog>` elements +and the `CloseWatcher` API. (And sometimes the `popover=""` attribute.) + +When the test expectations are the same for both `<dialog>` and `CloseWatcher`, +we use WPT's variants feature. + +However, in some cases different expectations are necessary. This is because +`<dialog>`s queue a task to fire their `close` event, and do not queue a task +to fire their `cancel` event. Thus, when you have two `<dialog>`s grouped +together, you get the somewhat-strange behavior of both `cancel`s firing first, +then both `close`s. Whereas `CloseWatcher`s do not have this issue; both events +fire synchronously. + +(Note that scheduling the `cancel` event for `<dialog>`s is not really possible, +since it would then fire after the dialog has been closed in the DOM and +visually. So the only reasonable fix for this would be to stop scheduling the +`close` event for dialogs. That's risky from a compat standpoint, so for now, +we test the strange behavior.) |