Bug 42661 – Fragment anchor does not change tab location if connected to element id.

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: DOM

Similar to http://jimthatcher.com/news-070607.htm but in this case if the
anchor references a fragment that is the id of another element rather than the
name of another anchor, the location of the tab doesn't move.

Reproducible: Always

Steps to Reproduce:
1. Setup page as:
<a href="#content">Skip to Content><a href="foo.html">Fake Link</a><a
href="bar.html">Fake Link 2</a><div id="content"><a href="test.html">Content
Link</a></div>
2. Click on skip link.
3. Hit the tab button.
Actual Results:  
Focus should now be on the link to test.html

Expected Results:  
Focus is on the link to foo.html

At the time of the filing of this bug, the bug behavior is actually the default
behavior in all modern browsers (IE,FF,S,Ch). However, W3C's validator
recommends against using <a name="content"></a>, which was the old method.

[Ahmad Saleem]

I am able to reproduce this bug or at least all browser have different behavior:

Test Case Link - https://jsfiddle.net/j7u0b8L1/1/show


*** Safari 15.6 on macOS 12.5 ***

Upon clicking "Tab", the focus is now on address bar to type URL

*** Chrome Canary 106 ***

Focus goes to "Content Link" and show selection outline -> which is expected behavior

*** Firefox Nightly 105 ***

Upon clicking "Tab", the focus is now on address bar and on button to create new tab

________

Since all browsers are behaving different, I am going to change the status to "New" so someone with knowledge of Web-spec of desired behavior can comment.

[Radar WebKit Bug Importer]

<rdar://problem/98577689>

[Alexey Proskuryakov]

On macOS, one needs to test either with Full Keyboard Access enabled, or with Option+Tab, because Tab skips over links otherwise. When I follow these steps, but press Option+Tab in step 3, the focus goes to the last link as expected. 

Safari and Chrome both behave like this. I don't know if Firefox has an equivalent of Option+Tab, but in any case, WebKit behavior is now as requested in this bug.