Closed Bug 1310403 Opened 3 years ago Closed 3 years ago

Different behavior in Chrome/Firefox when calling focus() from a focus handler

Categories

(Core :: DOM: Events, defect, P3)

49 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla52
Tracking Status
firefox52 --- fixed

People

(Reporter: mail, Assigned: enndeakin)

References

()

Details

(Keywords: testcase)

Attachments

(2 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160916101415

Steps to reproduce:

Go to https://jsfiddle.net/68rw9cL2/6/ and click on the "Give focus to input" button.
Look at the console.


Actual results:

In Firefox:

1. The focus handler on the button gives the focus to the input
2. Then Firefox gives the focus again to the button
3. The input loses the focus

In Chrome (or Konqueror):

1. The focus handler on the button gives the focus to the input
2. The input keeps the focus


Expected results:

By calling event.preventDefault() and event.stopPropagation(), the button should not have the focus back after the onFocus handler is called.
Has STR: --- → yes
Component: Untriaged → DOM: Events
Product: Firefox → Core
Why do you need to complicate things with preventDefault etc?
Just calling focus() on the element you want to focus seems
to work fine in both Firefox and Chrome.
What is it you're trying to achieve exactly?
Flags: needinfo?(nicofrand)
Just remove the preventDefault etc. and you'll see that the issue remains the same. I simply added it to show that did not solve the issue.
I simply want to give the focus to the input when clicking (focusing) the button. But Firefox will give it the focus and then give it back to the button.
Attachment #8801538 - Attachment description: testcase that works as expected → testcase that works on Linux and Windows 10, but fails on OSX
The attached testcase works on Linux and Windows 10,
but fails on OSX for some reason.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(nicofrand)
Keywords: testcase
Flags: needinfo?(enndeakin)
The reporter's test case works as is should on Windows, Mac and Linux as far as I can see. 

If your goal though is to focus the input when the button is clicked, you should probably use a click event instead. On Mac, buttons do not become focused when they are clicked, and buttons can become focused via other means unrelated to clicking.
Flags: needinfo?(enndeakin)
Comment on attachment 8801538 [details]
testcase that works on Linux and Windows 10

> On Mac, buttons do not become
> focused when they are clicked,

Ah, good point, that's why this test appears to fail.
I've confirmed that switching to "onclick" works as expected on OSX.
Attachment #8801538 - Attachment description: testcase that works on Linux and Windows 10, but fails on OSX → testcase that works on Linux and Windows 10
Please take a look at my testcase AND the console !
Or take a look at this updated testcase: https://jsfiddle.net/68rw9cL2/8/

You'll see something is wrong.
I was told my previous might appear offensive, that was not the intention, please excuse the bad phrasing.

I just meant the console output is important too. The updated testcase output the logs in the browser's window instead.
Looking at the latest jsfiddle link, the issue seems to be that when calling input.focus() from the button focus handler, we see these events in Firefox:

Focus on button / Focus on input / Blur on input / Focus on button / Focus on input.

While on Chromium:
Focus on button / Focus on input.

So the issue seems to be that Firefox adds spurious events here (blur input/focus button/focus input).
Priority: -- → P3
The issue here is that HTMLButtonElement::PostHandleEvent seems to define its own mouse handling. Note that <input type="button"> does not have this issue with extraneous events.

The focus handling code should be removed from HTMLButtonElement. I suspect much or all of the special mouse handling here can also be removed as well (call to SetActiveManager, SetContentState in mouseover/mouseout, cancelling middle/right clicks).

Olli, any reason why all of this special handling might be here?
Flags: needinfo?(bugs)
Hmm, that is a regression from bug 178324. Before that we just set content state.
http://searchfox.org/mozilla-central/diff/15df29db77d1d7a3be46b18d65978d8e072998b5/content/html/content/src/nsHTMLButtonElement.cpp#397
So, you should know the best why the code is there ;)
But yeah, I think it is just a bug.
Flags: needinfo?(bugs)
I don't see any issues with removing all this special handling for buttons. Tests all work. The change to browser_focus_steal_from_chrome.js is because synthesizing a mouse click shouldn't trigger the button as no other element behaves this way so that seems fine, and Chrome doesn't allow this either. Am I missing some specific case?
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Attachment #8806356 - Flags: review?(bugs)
Comment on attachment 8806356 [details] [diff] [review]
Remove special mouse handling for buttons

and :hover and :active still work ok with <button>?
Attachment #8806356 - Flags: review?(bugs) → review+
I tested a variety of combinations of <button> with hover/active applied to the button and/or child content and don't see any difference.
https://hg.mozilla.org/integration/mozilla-inbound/rev/733596007d62aafce8e07da062881c24c7450e5c
Bug 1310403, Remove special mouse handling for buttons which fixes extra focus events, r=smaug
https://hg.mozilla.org/mozilla-central/rev/733596007d62
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
You need to log in before you can comment on or make changes to this bug.