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).
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.
*** Bug 298790 has been marked as a duplicate of this bug. ***
I would think this is a regression of bug 258514.
Thanks for that Martijn, if there is anything I can do to help with this, please let me know.
Aaron, this is all you...
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.
(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.
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.
Created attachment 232092 [details] [diff] [review] 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.
Martijn, it's been nearly two years, you should follow up on those reviews :-).
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.
Martijn, any chance for a testcase? Even better would be to have also a mochitest for this.
Comment on attachment 232092 [details] [diff] [review] patch? This doesn't apply cleanly anymore. Focus handling has moved from ESM for FocusManager
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".
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"  when :target is not focusable.  https://html.spec.whatwg.org/multipage/interaction.html#sequential-focus-navigation-starting-point