26907 2014-09-25 23:25:58 +0000 Spec for reference fragment navigation to a non-focusable element does not match reality 2014-11-07 01:09:48 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED P3 normal Unsorted 1 rob ian ian mike contributor oldest_to_newest 112222 0 1518 rob 2014-09-25 23:25:58 +0000 Created attachment 1518 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. 112940 1 ian 2014-10-10 04:11:59 +0000 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.) 112942 2 rob 2014-10-10 08:53:12 +0000 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 112964 3 ian 2014-10-10 17:59:52 +0000 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 114626 4 contributor 2014-11-07 01:09:48 +0000 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 1518 2014-09-25 23:25:58 +0000 2014-09-25 23:25:58 +0000 Test case for checking the focus behavior upon a reference fragment navigation focus-navigation-test.html text/html 1776 rob PCFET0NUWVBFIGh0bWw+CjxoZWFkPgo8c3R5bGU+CmxhYmVsIHsKICAgIGRpc3BsYXk6IGJsb2Nr OwogICAgbWFyZ2luOiAxZW07Cn0KaW5wdXQgewogICAgd2lkdGg6IDgwJTsKfQouZm9jdXNlZCB7 CiAgICBiYWNrZ3JvdW5kOiAjRUVFCn0KPC9zdHlsZT4KPC9oZWFkPgo8Ym9keT4KPGxhYmVsPgog ICAgPGlucHV0IGlkPSJmb2N1c2FibGUtcmVmZXJlbmNlLWZyYWdtZW50IiBwbGFjZWhvbGRlcj0i cmVmZXJlbmNlLWZyYWdtZW50Ij4KPC9sYWJlbD4KPGxhYmVsIGlkPSJub24tZm9jdXNhYmxlLXJl ZmVyZW5jZS1mcmFnbWVudCI+CiAgICBub24tZm9jdXNhYmxlLXJlZmVyZW5jZS1mcmFnbWVudAo8 L2xhYmVsPgo8aHI+CjxsYWJlbD4KICAgIFdoZW4gYW4gaW5wdXQgZWxlbWVudCBpcyBmb2N1c2Vk LCB0aGUgZm9jdXMgY291bnQgd2lsbCBiZSBpbmNyZW1lbnRlZCBhbmQgZGlzcGxheWVkLjxicj4K ICAgIGRvY3VtZW50LmFjdGl2ZUVsZW1lbnQgd2lsbCBoYXZlIGEgZ3JleSBiYWNrZ3JvdW5kLiBJ ZiB0aGUgYm9keSBpcyBncmV5LCBpdCBwcm9iYWJseSBtZWFucyB0aGF0IG5vbmUgb2YgdGhlIGVs ZW1lbnRzIGFyZSBmb2N1c2VkLgo8L2xhYmVsPgo8bGFiZWw+CiAgICBvbmZvY3VzID0gbmF2aWdh dGUgdG8gI2ZvY3VzYWJsZS1yZWZlcmVuY2UtZnJhZ21lbnQ8YnI+CiAgICA8aW5wdXQgb25mb2N1 cz0ic2V0VGltZW91dChmdW5jdGlvbigpIHsKICAgIGxvY2F0aW9uLmhyZWY9JyNmb2N1c2FibGUt cmVmZXJlbmNlLWZyYWdtZW50JzsKICAgIH0pOyI+CjwvbGFiZWw+CjxsYWJlbD4KICAgIG9uZm9j dXMgPSBuYXZpZ2F0ZSB0byAjbm9uLWZvY3VzYWJsZS1yZWZlcmVuY2UtZnJhZ21lbnQ8YnI+CiAg ICA8aW5wdXQgb25mb2N1cz0ic2V0VGltZW91dChmdW5jdGlvbigpIHsKICAgIGxvY2F0aW9uLmhy ZWY9JyNub24tZm9jdXNhYmxlLXJlZmVyZW5jZS1mcmFnbWVudCc7CiAgICB9KTsiPgo8L2xhYmVs Pgo8bGFiZWw+CiAgICBvbmZvY3VzID0gbmF2aWdhdGUgdG8gI25vbi1leGlzdGVudC1yZWZlcmVu Y2UtZnJhZ21lbnQ8YnI+CiAgICA8aW5wdXQgb25mb2N1cz0ic2V0VGltZW91dChmdW5jdGlvbigp IHsKICAgIGxvY2F0aW9uLmhyZWY9JyNub24tZXhpc3RlbnQtcmVmZXJlbmNlLWZyYWdtZW50JzsK ICAgIH0pOyI+CjwvbGFiZWw+Cgo8cHJlPgpSZWZlcmVuY2VzOgpodHRwczovL2NvZGUuZ29vZ2xl LmNvbS9wL2Nocm9taXVtL2lzc3Vlcy9kZXRhaWw/aWQ9NDE3NjM2Cmh0dHBzOi8vaHRtbC5zcGVj LndoYXR3Zy5vcmcvbXVsdGlwYWdlL2Jyb3dzZXJzLmh0bWwjc2Nyb2xsLXRvLWZyYWdpZApodHRw czovL2h0bWwuc3BlYy53aGF0d2cub3JnL211bHRpcGFnZS9pbnRlcmFjdGlvbi5odG1sI2ZvY3Vz aW5nLXN0ZXBzCjwvcHJlPgoKPHNjcmlwdD4KW10uZm9yRWFjaC5jYWxsKGRvY3VtZW50LnF1ZXJ5 U2VsZWN0b3JBbGwoJ2lucHV0JyksIGZ1bmN0aW9uKGVsZW0pIHsKICAgIHZhciBmb2N1c2NvdW50 ID0gMDsKICAgIGVsZW0uYWRkRXZlbnRMaXN0ZW5lcignZm9jdXMnLCBmdW5jdGlvbigpIHsKICAg ICAgICB0aGlzLnZhbHVlID0gKytmb2N1c2NvdW50OwogICAgfSk7Cn0pOwpzZXRJbnRlcnZhbChm dW5jdGlvbigpIHsKICAgIHZhciBvbGQgPSBkb2N1bWVudC5xdWVyeVNlbGVjdG9yKCcuZm9jdXNl ZCcpOwogICAgaWYgKG9sZCkgb2xkLmNsYXNzTmFtZSA9ICcnOwogICAgZG9jdW1lbnQuYWN0aXZl RWxlbWVudC5jbGFzc05hbWUgPSAnZm9jdXNlZCc7Cn0sIDIwMCk7Cjwvc2NyaXB0Pgo8L2JvZHk+ CjwvaHRtbD4K