blob: b9aa9a212342470c1e4c4e5b15b38197600297e7 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
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.)
|
