This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26907 - Spec for reference fragment navigation to a non-focusable element does not match reality
Summary: Spec for reference fragment navigation to a non-focusable element does not ma...
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
Depends on:
Reported: 2014-09-25 23:25 UTC by rob
Modified: 2014-11-07 01:09 UTC (History)
2 users (show)

See Also:

Test case for checking the focus behavior upon a reference fragment navigation (1.73 KB, text/html)
2014-09-25 23:25 UTC, rob

Description rob 2014-09-25 23:25:58 UTC
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

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 (

It turns out that this behavior does not match the behavior of the web browsers.
Visit 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 -
- 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 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.
Comment 1 Ian 'Hixie' Hickson 2014-10-10 04:11:59 UTC
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.)
Comment 2 rob 2014-10-10 08:53:12 UTC
Hi Ian, that sounds like the most widely acceptable solution. That behavior has been implemented in Blink in the past week:

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: The relevant specification [SFN] does not take non-focusable elements into account, so the discrepancy in implementations is not surprising.

Comment 3 Ian 'Hixie' Hickson 2014-10-10 17:59:52 UTC
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.
Comment 4 contributor 2014-11-07 01:09:48 UTC
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.