diff options
Diffstat (limited to 'testing/web-platform/tests/close-watcher/user-activation/nn-activate-dialog.html')
| -rw-r--r-- | testing/web-platform/tests/close-watcher/user-activation/nn-activate-dialog.html | 16 |
1 files changed, 1 insertions, 15 deletions
diff --git a/testing/web-platform/tests/close-watcher/user-activation/nn-activate-dialog.html b/testing/web-platform/tests/close-watcher/user-activation/nn-activate-dialog.html index 5cc866044c..eaffb4d9a7 100644 --- a/testing/web-platform/tests/close-watcher/user-activation/nn-activate-dialog.html +++ b/testing/web-platform/tests/close-watcher/user-activation/nn-activate-dialog.html @@ -7,20 +7,6 @@ <script src="/common/top-layer.js"></script> <script src="../resources/helpers.js"></script> -<!-- - This test has different expectations for dialogs vs. CloseWatchers because - dialogs queue a task to fire their close event, and do not do so for their - cancel event. Thus, when you have two dialogs grouped together, you get the - somewhat-strange behavior of both cancels firing first, then both closes. - Whereas CloseWatchers do not have this issue; both fire synchronously. - - Note that scheduling the cancel event for dialogs 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, test the - strange behavior. ---> - <body> <script> const type = "dialog"; @@ -35,6 +21,6 @@ promise_test(async t => { await sendCloseRequest(); await waitForPotentialCloseEvent(); - assert_array_equals(events, ["watcher2 cancel", "watcher1 cancel", "watcher2 close", "watcher1 close"]); + assert_array_equals(events, ["watcher2 cancel[cancelable=true]", "watcher1 cancel[cancelable=true]", "watcher2 close", "watcher1 close"]); }, "Create two dialogs without user activation; send user activation"); </script> |