1. For a remote document, the `<browser>` itself has DOM focus in the parent process. 2. When we change from remote to non-remote, we use the same `<browser>` element. 3. For a non-remote document, the parent process DOM focus needs to be inside the document itself. 4. I haven't worked out where this happens, but when we focus a `<browser>` for a non-remote document, DOM bounces focus to the document inside it. 5. My guess is that we're relying on (4) to set focus correctly, even though the `<browser>` already had focus in (1). However, because we're skipping focus for this element because it already had focus, focus doesn't get set up correctly and thus remains on the `<browser>` element. From a11y's perspective, that effectively means we get no focus change. That's also why we report "frame" (that's the `<browser>` element) when a11y forces a focus event (based on the current DOM focus) after dismissing the menu bar.
Bug 1933119 Comment 7 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
1. For a remote document, the `<browser>` itself has DOM focus in the parent process. 2. When we change from remote to non-remote, we use the same `<browser>` element. 3. For a non-remote document, the parent process DOM focus needs to be inside the document itself. 4. I haven't worked out where this happens, but when we focus a `<browser>` for a non-remote document, DOM bounces focus to the document inside it. 5. My guess is that we're relying on (4) to set focus correctly, even though the `<browser>` already had focus in (1). However, because we're skipping focus for this element because it already had focus, focus doesn't get set up correctly and thus remains on the `<browser>` element. From a11y's perspective, that effectively means we get no focus change. That's also why NVDA reports "frame" (that's the `<browser>` element) when a11y forces a focus event (based on the current DOM focus) after dismissing the menu bar.