tree: 45154f6c2a205f1df2b7f302ff96a1eedd5b6d4f [path history] [tgz]
  1. n-activate-preventDefault.html
  2. n-activate.html
  3. n-closerequest-n.html
  4. n-destroy-n.html
  5. n.html
  6. nn-activate-CloseWatcher.html
  7. nn-activate-dialog.html
  8. nn-CloseWatcher.html
  9. nn-dialog.html
  10. nnn-CloseWatcher-dialog-popover.html
  11. nnn-CloseWatcher.html
  12. nnn-dialog.html
  13. nnn-popovers.html
  14. ny-activate-preventDefault.html
  15. ny.html
  16. nyn-popovers.html
  17. nyn.html
  18. nynn-destroy.html
  19. nynn.html
  20. nyyn-CloseWatcher.html
  21. nyyn-dialog.html
  22. nyyyn-CloseWatcher.html
  23. nyyyn-dialog.html
  24. README.md
  25. y-dialog-disconnected.html
  26. y-popover-disconnected.html
  27. y.html
  28. yn-activate.html
  29. yn.html
  30. ynn-CloseWatcher.html
  31. ynn-dialog.html
  32. yy.html
  33. yyn.html
  34. yyy-activate-CloseWatcher-dialog-popover.html
  35. yyy-CloseWatcher-dialog-popover.html
  36. yyy-popovers.html
  37. yyy.html
close-watcher/user-activation/README.md

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 cancels firing first, then both closes. Whereas CloseWatchers 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.)