You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I fail to find spec text covering the following scenario, which I think should be covered by the spec:
Focus is in an iframe. The iframe loads another document. See demo.
Findings:
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.
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 should not make it into the spec. (I.e. without the pending fix for the bug the focus behavior is as if the iframe got removed from the doc and a new one got inserted for focus purposed.)
Non-Fission Firefox fires the focus event on each framed document upon unsuppressing painting. Chrome and Safari either don't fire the event or fire it unobservably early.
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.
Based on the above, I think it should be non-controversial for the spec to say that if focus is somewhere inside an iframe and the iframe loads a new document, the iframe should remain as the activeElement of the document that contains the iframe and the body of the newly-loaded document in the iframe should get focused.
What's less clear is when exactly the body of the newly-loaded document should become focused and whether the newly-loaded document should experience a focus event when that happens. In Firefox, the body of the newly-loaded document becomes focused and the focus event is fired when painting is unsuppressed, which happens from a timer. In Safari and Chrome, either an event isn't fired or the focusing happens before a parser-inserted script in head has the chance to register an event handler. (I.e. those event handlers get added before the body element is even inserted into the document…)
The text was updated successfully, but these errors were encountered:
I fail to find spec text covering the following scenario, which I think should be covered by the spec:
Focus is in an iframe. The iframe loads another document. See demo.
Findings:
about:blank
) non-Fission Firefox, Chrome, and Safari all keep theiframe
as theactiveElement
of the parent.body
of the parent when the iframe changes remoteness. In the light of the previous point, this is clearly a bug and should not make it into the spec. (I.e. without the pending fix for the bug the focus behavior is as if the iframe got removed from the doc and a new one got inserted for focus purposed.)focus
event on each framed document upon unsuppressing painting. Chrome and Safari either don't fire the event or fire it unobservably early.body
element of the last framed document focused in the end state: Clicking it doesn't refocus it. However, in Chrome, clicking it fires thefocus
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.Based on the above, I think it should be non-controversial for the spec to say that if focus is somewhere inside an iframe and the iframe loads a new document, the iframe should remain as the
activeElement
of the document that contains the iframe and the body of the newly-loaded document in the iframe should get focused.What's less clear is when exactly the body of the newly-loaded document should become focused and whether the newly-loaded document should experience a
focus
event when that happens. In Firefox, thebody
of the newly-loaded document becomes focused and thefocus
event is fired when painting is unsuppressed, which happens from a timer. In Safari and Chrome, either an event isn't fired or the focusing happens before a parser-inserted script inhead
has the chance to register an event handler. (I.e. those event handlers get added before thebody
element is even inserted into the document…)The text was updated successfully, but these errors were encountered: