308064 - Following an on-page anchor link loses the focus

Status: NEW

(Core :: Layout, defect, P3)

Description

[Philip Pawley]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041122

Pressing "enter" to follow an an anchor link should move the focus to that link.
In Mozilla 1.8a5 to 1.8b1 it doesn't.

In the page I put up to demonstrate this, the 2 top links lead to each other. 
When the focus is on the first, pressing enter should move the focus to the second.
When the focus is on the second, pressing enter should move the focus back to
the first - and the url in the address bar should reflect this. In Mozilla
1.8a5, neither of these happen: the focus is lost and the address bar stays on
the second anchor.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.alexanderworks.org.uk/bugs/anchor-focus.html
2. Tab to anchor1
3. Press "enter"
4. Press "enter" again.

Actual Results:  
The focus was lost and the url in the address bar remained unchanged.

Expected Results:  
The focus should have returned to the first anchor and the url in the address
bar should have reflected this (as it does in all previous versions of Mozilla).

It also happens on Mac OSX, 10.2, with Firefox 1.5b1 (once the
"accessibility.tabfocus" preference has been set to 7 to enable tabbing).

Comment 1

[Philip Pawley]

Apologies, I've just seen I already filed this as bug #298790.
However, this one includes a clearer, simpler testcase, so I propose marking
#298790 as a duplicate of this bug.

Comment 2

[Philip Pawley]

*** Bug 298790 has been marked as a duplicate of this bug. ***

Comment 3

[Martijn Wargers (dead)]

I would think this is a regression of bug 258514.

Comment 4

[Philip Pawley]

Thanks for that Martijn, if there is anything I can do to help with this, please let me know.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Aaron, this is all you...

Comment 6

[Mats Palmgren (inactive)]

While looking at this I think I've found another bug...
The pref. "layout.selectanchor" does not seem to work - I'm guessing it should
make the anchor node contents become the primary selection, right?
I might as well fix that too since it's in the same method, I just need to
know what it's supposed to do.

Comment 7

[Aaron Leventhal]

(In reply to comment #6)
> The pref. "layout.selectanchor" does not seem to work - I'm guessing it should
> make the anchor node contents become the primary selection, right?

Correct. 

Comment 8

[Darin Fisher]

A patch would need to be baked for a while on the trunk before we'd take it for FF2.  Not going to block FF2 for this.

Comment 9

[Martijn Wargers (dead)]

Attachment: patch?

This seems to fix this bug for me, as well as bug 322588.
It's basically putting something back that the "Expose high level esm::ChangeFocusWith()." patch from bug 258514 removed, so I'm not sure if this is any good.
This doesn't seem to regress bug 258514.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Martijn, it's been nearly two years, you should follow up on those reviews :-).

Comment 11

[Johnny Stenback (:jst)]

Comment on attachment 232092 [details] [diff] [review]
patch?

Smaug, you'd probably be the best person to figure out what we want to do here.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Martijn, any chance for a testcase? Even better would be to have also a mochitest for this.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 232092 [details] [diff] [review]
patch?

This doesn't apply cleanly anymore. Focus handling has moved from ESM for FocusManager

Comment 14

[Dave]

Anyone working on this as it is still an issue?

Summarising the bug:
<a href="#link">Go to link</a>
<a id="link" href="http://www.mozilla.org/">Go Mozilla</a>
<a href="#">Go Top</a>

Selecting "Go to link" does not give focus to "Go Mozilla". Though internally the focus is there as pressing tab will give focus to "Go Top".

Comment 16

[Rodney Rehm]

Focusing the :target element is also the topic in bug https://bugzilla.mozilla.org/show_bug.cgi?id=277178


The behavior is specified in http://www.w3.org/TR/html5/browsers.html#scroll-to-fragid and applies to fragment identifier being present at document load time, as well as after a user clicked on an anchor link.

Basically, whenever :target is focusable, it should be focused.
Blink, WebKit and Trident get this right, Gecko is the only one to not focus the target.

The only thing Gecko does correct and Blink, WebKit and Trident fail is updating the "sequential focus navigation starting point" [1] when :target is not focusable.

[1] https://html.spec.whatwg.org/multipage/interaction.html#sequential-focus-navigation-starting-point

Comment 17

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 18

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 19

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 20

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 21

[Guido Bouman]

This bug is now 14 years old, is there any intention of fixing this?

This breaks the CSS-only approach to open a menu with a link to an anchor combined with :focus (& :focus-inside).

Comment 22

[gerrit.huebbers]

This breaks accessibility, especially skip links ( https://developer.mozilla.org/en-US/docs/Learn/Common_questions/HTML_features_for_accessibility ).

Comment 23

[James Teh [:Jamie]]

(In reply to gerrit.huebbers from comment #22)

This breaks accessibility, especially skip links ( https://developer.mozilla.org/en-US/docs/Learn/Common_questions/HTML_features_for_accessibility ).

What would you expect in the example on that page? The target is a section, which isn't focusable, so we can't focus it. This is frequently the case with skip links: the target isn't a focusable element. However, screen readers are informed of the target, and for non-screen reader user keyboard users, pressing tab will take you to the next link after the target.

Comment 24

[gerrit.huebbers]

(In reply to James Teh [:Jamie] from comment #23)

What would you expect in the example on that page? The target is a section, which isn't focusable, so we can't focus it. [...]

Please excuse my ambigious comment – I think you misunderstood what I wanted to convey: I provided that link for giving motivational context why working "jump-to-input-elements-and-place-the-cursor-there" anchors are important, namely for working skip links, especially for accessibility reasons (e.g. skipping to an input element and allowing to provide input), where every barrier and confusion removed makes a significant impact.

Imagine a skip link to directly jump to this Bugzilla's quick search box. You would have <a href="#quicksearch_top">Skip to Quicksearch</a> as one of the first children of the <body> element.

Try it out yourself: Skip to Quicksearch.

• Click that link in IE11, Edge, or Chrome, and a blinking cursor will appear in above search box, waiting for your input.
• Click that link in Firefox 1 to 76+, and you're lost.

Comment 25

[gerrit.huebbers]

Here is a further arguments in favor of working in-page anchors towards input elements:

For form validation errors, W3C's Web Accessibility Initiative recommends to provide direct links to the failing inputs. Such jump-to-field-for-correction links are described in WCAG's technique SCR32. They provide an example form with such jump-to-field-for-correction links, which surprisingly work in Firefox 77.0.1. I haven't understood yet, why that particular example works while in the general case it does not.

Comment 26

[Shaw]

It's mind boggling this bug is open for 16 years.

It is preventing me from toggling anchor tags using CSS while keeping focus.

https://codepen.io/Miragecraft/pen/oNzzgBw

Comment 27

[Job Bautista]

I can no longer reproduce this bug in 102.6.0 ESR, has this somehow been fixed?