Following an on-page anchor link loses the focus

ASSIGNED
Unassigned

Status

()

Core
Layout
ASSIGNED
12 years ago
3 years ago

People

(Reporter: Philip Pawley, Unassigned)

Tracking

(Blocks: 1 bug, {regression, testcase})

Trunk
x86
All
regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
wanted-next +
blocking1.9 -
wanted1.9 -
blocking1.8.1 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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).
(Reporter)

Comment 1

12 years ago
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.
(Reporter)

Comment 2

12 years ago
*** Bug 298790 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

12 years ago
Version: unspecified → 1.5 Branch
I would think this is a regression of bug 258514.
Blocks: 258514
Component: Keyboard Navigation → Layout
Keywords: regression, testcase
Product: Firefox → Core
QA Contact: keyboard.navigation → layout
Version: 1.5 Branch → Trunk
(Reporter)

Comment 4

12 years ago
Thanks for that Martijn, if there is anything I can do to help with this, please let me know.
Aaron, this is all you...
Assignee: nobody → aaronleventhal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9a1?
Flags: blocking1.8.1?

Updated

12 years ago
Assignee: aaronleventhal → mats.palmgren

Updated

11 years ago
Flags: blocking1.8.1? → blocking1.8.1+

Comment 6

11 years ago
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.
Status: NEW → ASSIGNED
OS: Windows 2000 → All

Comment 7

11 years ago
(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

11 years ago
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.
Flags: blocking1.8.1+ → blocking1.8.1-
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.
Attachment #232092 - Flags: review?(mats.palmgren)

Updated

11 years ago
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [wanted-1.9]

Updated

11 years ago
Attachment #232092 - Flags: superreview?(jst)
Blocks: 321493
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Martijn, it's been nearly two years, you should follow up on those reviews :-).
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+

Updated

8 years ago
Attachment #232092 - Flags: superreview?(jst)
Attachment #232092 - Flags: superreview?(Olli.Pettay)
Attachment #232092 - Flags: review?(matspal)
Attachment #232092 - Flags: review?(Olli.Pettay)
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
Attachment #232092 - Flags: superreview?(Olli.Pettay)
Attachment #232092 - Flags: review?(Olli.Pettay)

Comment 14

8 years ago
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".

Updated

7 years ago
Duplicate of this bug: 334030

Updated

6 years ago
Assignee: matspal → nobody

Comment 16

3 years ago
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
You need to log in before you can comment on or make changes to this bug.