I can't reproduce the issue as filed on macOS. After [tab] the button is focused and [enter] closes the dialog, as expected. Also, in your screencast, when you press [tab] the fxview tab is focused and has a focus ring... Also, when testing Safari, did you enable OS "keyboard access to all controls" in the macOS system settings/preferences? Otherwise, buttons would simply never receive focus, and that would explain some of what you describe in comment 7. An alternative solution here may be for tabbing into the dialog to focus-capture (ie it should then not be possible to use the tab keys to "tab out of" the dialog at all). Historically, this was not possible in HTML/DOM/Gecko. `html:dialog` I think now supports it; I don't know if it's possible to use `inert` similarly here, without breaking other things (e.g. we'd still want users to be able to use the mouse or keyboard shortcuts to close tabs that have content dialogs open, because some websites abuse such dialogs and we don't want to remove control from users). I filed the original bug in response to UX requests. A change here would want input from UX, too. Also, for future reference, you can just hit [esc] to close (really, cancel) a dialog like that, irrespective of what is focused. (In reply to Daniel Holbert [:dholbert] from comment #8) > Created attachment 9382400 [details] > Screenshot of Nightly, with another dialog that does get the focus ring by default ("Confirm you want to leave") > > I just noticed that in another dialog that looks similar to `alert`, we *do* show the focus ring by default -- the "confirm you want to leave" dialog that pops up, if you e.g. do a "close-tab" operation after typing some text into a field in an editable PDF. Confusingly, I also cannot reproduce this. I don't see a focus rectangle by default for beforeunload dialogs (again, on macOS). It's possible we do focus differently on macOS for alerts and that is causing the difference? Either way it's really a UX question, not an engineering one.
Bug 1881811 Comment 9 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I can't reproduce the issue as filed on macOS. After [tab] the button is focused and [enter] closes the dialog, as expected. Also, in your screencast, when you press [tab] the fxview tab is focused and has a focus ring... Also, when testing Safari, did you enable OS "keyboard access to all controls" in the macOS system settings/preferences? Otherwise, buttons would simply never receive focus, and that would explain some of what you describe in comment 7. An alternative solution here may be for tabbing into the dialog to focus-capture (ie it should then not be possible to use the tab keys to "tab out of" the dialog at all). Historically, this was not possible in HTML/DOM/Gecko. `html:dialog` I think now supports it; I don't know if it's possible to use `inert` similarly here, without breaking other things (e.g. we'd still want users to be able to use the mouse or keyboard shortcuts to close tabs that have content dialogs open, because some websites abuse such dialogs and we don't want to remove control from users). I filed the original bug in response to UX requests. A change here would want input from UX, too. Also, for future reference, you can just hit [esc] to close (really, cancel) a dialog like that, irrespective of what is focused. (In reply to Daniel Holbert [:dholbert] from comment #8) > Created attachment 9382400 [details] > Screenshot of Nightly, with another dialog that does get the focus ring by default ("Confirm you want to leave") > > I just noticed that in another dialog that looks similar to `alert`, we *do* show the focus ring by default -- the "confirm you want to leave" dialog that pops up, if you e.g. do a "close-tab" operation after typing some text into a field in an editable PDF. Confusingly, I also cannot reproduce this. I don't see a focus rectangle by default for beforeunload dialogs (again, on macOS), until I start tabbing around. It's possible we do focus differently on macOS for alerts and that is causing the difference? Either way it's really a UX question, not an engineering one.