falken@ disagrees with we https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/fast/dom/HTMLDialogElement/show-modal-focusing-steps.html?type=cs&q=third_party/WebKit/LayoutTests/fast/dom/HTMLDialogElement/show-modal-focusing-steps.html&sq=package:chromium&l=17

with me*

btw, falken@ told me over chat that `document.body` might be a special case here (and there are multiple tests that imply the same)

Yes document.body should be the only exception. From what I remember and based on the CL description at https://codereview.chromium.org/112553002, if a modal dialog is open but nothing is focusable, document.body gets focus as a last resort. I vaguely remember Blink has some assumptions over the codebase that when nothing is focusable document.body will get it, which I think is what I'm referring to here:

"a) it would make document.body inert, which violates
assumptions of document.body getting default focus when
nothing else can have focus, and"

Indeed the CL doesn't explicitly give focus to body, but instead called document().setFocusedElement(0); which effectively gives document.body focus.

Anyway that CL does recognize that the actual spec and desirable behavior would be for document.body to not get focus (I'm not sure what document.activeElement would be then... null? or maybe <dialog> should get last resort focus even if it's not focusable) but mentions the problems were a) and b) (accessibility tree gets confused).

I'm not sure if a) and b) are still problems today but that's why document.body gets focus.

Digging into history more, there was a huge spec discusssion about this. Some people were advocating for <dialog> to be focusable but Hixie was unconvinced:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23366

I'm going to bump the priority down on this since it's not new.

Tagging this with accessibility (not sure if that's the right label)--a11y people, do you have opinions here? I notice S. Faulkner on the issue linked in Comment 5 is talking about the effect this has on AT.

kochi, could you investigate what the spec requires and what other browsers do? We need to decide whether we should change the spec behavior or fix Blink.

No other browser implements <dialog> yet, so we should do whatever makes sense and provide spec feedback to change the spec to make sense too.

Mozilla seems to be implementing so now's a good time for feedback:
https://bugzilla.mozilla.org/show_bug.cgi?id=1322938

Seems like we need to implement the focus fixup rules to fix this: https://html.spec.whatwg.org/multipage/interaction.html#focus-fixup-rule-one

Alice could you take over this issue?

I don't have time to work on this in foreseeable future, changing the
status to "Available".

Update from dsexton, this is concerning spec compliance but it is also relevant to how dialogs receive focus. Includes Windows. 

@foolip, would you mind taking a fresh look at this?

I'm curious about whether you can reproduce the bug with fullscreen instead of dialog, and I imagine the fix ought to be similar.

dmazzoni@, it's been a month and a half, sorry about that.

This will affect fullscreen as well, but if the fix for this is implementing https://html.spec.whatwg.org/multipage/interaction.html#focus-fixup-rule-one then I believe the Blink>HTML component is the right one. I may run across this with fullscreen, but for now the honest status of this is that I'm not going to look at it until I run into it with fullscreen, especially given that it's a P3. I'll add myself to CC though and am adding the Blink>Fullscreen component.