This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Created attachment 1518 [details] Test case for checking the focus behavior upon a reference fragment navigation The HTML5 specification defines the algorithm for reference fragment navigation at https://html.spec.whatwg.org/multipage/browsers.html#scroll-to-fragid. In short: - If the reference fragment refers to an element, scroll this target element into view. - If the target is non-focusable, abort these steps. - If the target is focusable, focus the element (https://html.spec.whatwg.org/multipage/interaction.html#focusing-steps) It turns out that this behavior does not match the behavior of the web browsers. Visit https://robwu.nl/s/chromium/bug417636/focus-navigation-test.html and try to focus each of the fields labeled "onfocus = ...". Upon focus, the document is assigned a new reference fragment. Test subjects: - Firefox 3.6, 11, 32 - IE 8, 9, 10, 11 - Chrome 34, 39 - Safari 6, 6.1, 7, 8 ( Opera 12.15 and Safari 5.1 also tested but not mentioned below because they do not change the focus under any circumstances ) When the target is focusable, the behavior is quite consistent: - Firefox assigns the focus to the target (:focus is not applied, but sequential focus navigation [HTML5 6.4.5] takes the target as the starting point - https://bugzilla.mozilla.org/show_bug.cgi?id=308064). - IE, Chrome and Safari focuses the target. When the target is NON-focusable: - Firefox behaves identical to the case when the target is focusable. - IE focuses the non-focusable element (a caret briefly appears then disappears). - Chrome and Safari: The focus does not change. Before I continue, a bit more about the background that lead to me reporting this issue. WebKit never supported a:focus. When I added a:focus support to Chrome 39, a visual regression was reported at https://crbug.com/417636. This bug was caused by the fact that Chrome does not focus a non-focusable element after a reference fragment navigation (which is exactly what the current specification requires (non-focusable => abort steps)). The behavior of Firefox and IE are mutually consistent, and I believe that Blink and WebKit should match their behavior as well. Otherwise implementing a:focus in the Blink/WebKit will lead to visual results that differ from Firefox/IE.
It seems like the way to fix this that is sane is to make it move the focus to the viewport, not making it move the focus to the element. That would be consistent with the non-focusable element not matching :focus and activeElement returning the body. Note that what Firefox does is move the invisible caret as well. That's a different issue than what has focus. (Fit F7 in Firefox to see this working more explicitly, IIRC.)
Hi Ian, that sounds like the most widely acceptable solution. That behavior has been implemented in Blink in the past week: http://src.chromium.org/viewvc/blink?view=revision&revision=183455 The other issue is different, and only Firefox seems to behave in that way. It is however superior over the current implementations in IE/Blink, and also viewed as a desirable feature in Chrome: https://code.google.com/p/chromium/issues/detail?id=262171. The relevant specification [SFN] does not take non-focusable elements into account, so the discrepancy in implementations is not surprising. [SFN] https://html.spec.whatwg.org/multipage/interaction.html#sequential-focus-navigation
Ah, yeah, making sequential focus navigation sensitive to more than just the currently focused node would make sense. Can you file a new bug for that? Thanks. https://whatwg.org/newbug
Checked in as WHATWG revision r8845. Check-in comment: Define how focus sequential navigation works in slightly more detail; make navigating to an unfocusable control lead to the viewport being refocused. https://html5.org/tools/web-apps-tracker?from=8844&to=8845