Modal dialog is too easy to bypass

[joaomoreno]

Testing #122252

1. Have custom title bar

🐛

[joaomoreno]

Are we (should we) be using the <dialog> HTML element?

[sbatten]

no https://caniuse.com/?search=dialog

[bpasero]

no https://caniuse.com/?search=dialog

Well, we could do browser detection and still use dialog where supported to get the best experience. I would also think that using dialog elements has some impact on accessibility / screen readers.

[joaomoreno]

1. Press Alt

[sbatten]

There's some trickiness with the alt listener because both event handlers use capture on the same element. I have a fix but I don't want to check it in this late in case there are conflicts with the other consumer (cc @isidorn)

[joaomoreno]

On Windows:

1. Alt
2. V
3. Enter

[sbatten]

I'm not sure why I got lucky before with the timing, but the preventDefault just doesn't work for this now. You can bypass the dialog, but at least its not just clicking. Can try something better next week.

[sbatten]

The menubar uses capture because it needs to function "natively" intercepting mnemonics everywhere. the dialog does the same and unfortunately is always going to add its event listener after, so it doesn't have a chance to intercept. I spent some time trying to come up with something but nothing I came up with didn't involve one component having to know about another. as I stated above, the initial "too easy" bypass was clicking which is no longer an option. since we are using a custom dialog, we will not get a truly blocking experience without some more major work that I don't see a need to prioritise.

[sbatten]

To Verify: Check that you cannot click the Custom Menu Bar on Windows. Native menu bars cannot be blocked by the custom dialog.