:focus not retained after mouse button released




DOM: Events
7 years ago
7 years ago


(Reporter: betatrash, Unassigned)


Firefox Tracking Flags

(Not tracked)



(2 attachments, 2 obsolete attachments)



7 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E)
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.01) Gecko/20100101 Firefox/4.0.1

win7-x64, not sure if this happens with another OS.

attempting this with anchors, not sure if it happens with other elements.

when clicking on a link, :focus is given, but when the mouse button is released, :focus is removed.

the behaviour is currently mirrored by :active in FX4.

Reproducible: Always

Steps to Reproduce:
1. click on an anchor with a :focus selector
2. link changes to match, now release the mouse button
3. :focus is lost

Actual Results:  
focus is lost

Expected Results:  
focus should me maintained

Comment 1

7 years ago
Created attachment 541605 [details]
ExampleHTML Comment#2

click the second link, focus is given
release the mouse button, focus is lost

Comment 2

7 years ago
what i don't understand is: if the link navigates to itself using the fragment #id, then why doesn't it retain focus?

again, possibly only on win7-x64.
Neil, Olli, any idea what's up here?
Component: General → DOM: Events
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → events

Comment 4

7 years ago
Created attachment 541608 [details]
ExampleHTML Comment#3

old example was stale
Attachment #541605 - Attachment is obsolete: true

Comment 5

7 years ago
this currently works in opera 11.1, just tested and ie8/9. chrome doesnt even apply :active on mouse events, so this doesnt apply.

Comment 6

7 years ago
why cant i edit my comments, my gawd i make so many mistakes haha. i meant to say chrome doesn't apply :focus on mouse events. that will be all.

Comment 7

7 years ago
well, narrowed it down a bit. the focus is still there, but the css style is removed.

if you tab to the second link, then press enter, the style disappears, but if you press tab again, you are at the 3rd link.

Comment 8

7 years ago
(In reply to comment #3)
> Neil, Olli, any idea what's up here?

Tracking Firefox 7, maybe?


7 years ago
Attachment #541608 - Attachment mime type: text/plain → text/html

Comment 9

7 years ago
This is because clicking an anchor that refers to the same page:
 - moves the caret to the anchor target destination
 - clears the focus on the page
This way the next tab key press begins from the anchor target instead, which is what one would want.

See http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#3957

The testcase here has an anchor that refers to itself and the code doesn't handle this case. Are self-referring anchors common enough to warrant a fix here?
Would it make sense to also focus the anchor target destination if it's focusable?

Comment 11

7 years ago
Possibly, but that would create visual noise (focus rings) that may be undesirable in some cases.

Comment 12

7 years ago
Created attachment 541779 [details]
ExampleHTML Comment#12

heres another example, the focus is moved to the next control after it is clicked.

several issues here:

opera: focus remains on the old element. this is wrong. if browsing to a frag#id, focus should be set to the new one, or should at least be reset.

chrome: focus is reset. however, chrome does not apply :focus selector to mouse events.

ie8/9: focus moves to the new frag#id. this is the correct behaviour.

firefox: focus moves to the new frag#id, but the :focus css selector is not applied.

what are focus rings? that has nothing do do with focus outlines, correct?

Comment 13

7 years ago
logically speaking, firefox is setting the focus to the new frag#id, which makes sense, because if that is a heading for example, with a form below it, the next tab press should go to the first field on the form, and not the beginning of the document.

however, if an element is given focus in the browser, then the :focus selector must be applied, because if someone decides to do a element:focus {} in their css, then the logic is broken. ie: how can my element have focus and my selector is not applied? this behaviour is broken.

then at least ie/firefox would agree that this is the correct behaviour (as it seems you already do agree by applying focus to it, except youre not applying the selector, breaking logic).

i dont care about opera/chrome, chrome still has tons of bugs/layout issues and opera just doesnt have the marketting/market share. not like they're detestable browsers, theyre just not as much of an issue for developers as IE/FX are. thanks for your understanding.

Comment 14

7 years ago
hmm ok, that's odd. browsing with tab+enter in firefox: it's like the position of the focus is maintained, but the element with the new focus will not accept keyboard commands like the enter key. although if tabbed is pressed again, focus moves to the next element.

so css :focus selector is not applied, and keyboard input is not accepted.

also, more bugs in chrome/opera, not moving focus at all (either css or browser focus) after enter key is pressed (although they change the URL).

Comment 15

7 years ago
Created attachment 541792 [details]
ExampleHTML Comment#15

fixed one typo, if you test this in IE8/9: keyboard input is accepted and the :focus selector is set.

press enter on one element and you can cycle through all of them. is this what you mean by a focus 'ring'?
Attachment #541779 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.