Here's a demo: https://hsivonen.com/test/moz/navigation-focus/ . I think this is more approachable for understanding what's going on that the attached WPT. Findings: 1. Once the iframe has been focused (when it has the initial `about:blank`) non-Fission Firefox, Chrome, and Safari all keep the `iframe` as the `activeElement` of the parent. 2. Fission Firefox moves focus to `body` of the parent when the `iframe` changes remoteness. In the light of the previous point, this is clearly a bug. (And fixed by the attached Gecko patch.) 3. Non-Fission Firefox fires the `focus` event on each framed document. Chrome and Safari either don't fire the event or fire it unobservably early. 4. Non-Fission Firefox and Safari consider the `body` element of the last framed document focused in the end state: Clicking it doesn't refocus it. However, in Chrome, clicking it fires the `focus` event, which suggests that in Chrome the frame is left in a weird intermediate state where the frames considers the frame focused but the framee does not consider itself focused. However, if you alt-tab away from Chrome and back, the frame is eligible for focus restoration. I think the non-Fission Firefox and the Safari behaviors are defensible. I think the Fission behavior (without the patch) or the Chrome behavior aren't defensible. Whether the focus event should Fire observably as in non-Fission Firefox or whether the focus should be considered taken unobservably early as in Safari is debatable. I think our behavior is more useful for Web devs, as it allows reacting to focus. I think the actions to be taken here at this time are: 1. Taking the Gecko patch. 2. Opening a spec issue. Whether the WPTs landing along the Gecko patch should test for the event depends on how quickly the spec issue reaches agreement on what should happen.
Bug 1663931 Comment 13 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Here's a demo: https://hsivonen.com/test/moz/navigation-focus/ . I think this is more approachable for understanding what's going on that the attached WPT. Findings: 1. Once the iframe has been focused (when it has the initial `about:blank`) non-Fission Firefox, Chrome, and Safari all keep the `iframe` as the `activeElement` of the parent. 2. Fission Firefox moves focus to `body` of the parent when the `iframe` changes remoteness. In the light of the previous point, this is clearly a bug. (And fixed by the attached Gecko patch.) 3. Non-Fission Firefox fires the `focus` event on each framed document. Chrome and Safari either don't fire the event or fire it unobservably early. 4. Non-Fission Firefox and Safari consider the `body` element of the last framed document focused in the end state: Clicking it doesn't refocus it. However, in Chrome, clicking it fires the `focus` event, which suggests that in Chrome the frame is left in a weird intermediate state where the framer considers the frame focused but the framee does not consider itself focused. However, if you alt-tab away from Chrome and back, the frame is eligible for focus restoration. I think the non-Fission Firefox and the Safari behaviors are defensible. I think the Fission behavior (without the patch) or the Chrome behavior aren't defensible. Whether the focus event should Fire observably as in non-Fission Firefox or whether the focus should be considered taken unobservably early as in Safari is debatable. I think our behavior is more useful for Web devs, as it allows reacting to focus. I think the actions to be taken here at this time are: 1. Taking the Gecko patch. 2. Opening a spec issue. Whether the WPTs landing along the Gecko patch should test for the event depends on how quickly the spec issue reaches agreement on what should happen.