Clicking on a non-text input element does not give it focus

Bug 22261 - Clicking on a non-text input element does not give it focus

Expected behavior:
* clicking on a button should give it focus and raise the onfocus event

Actual behavior:
* clicking on a button DOES NOT give it focus or raise an onfocus event
* clicking on a button when another element has focus DOES blur that element
* tabbing to a button DOES give it focus

Possibly related: 
* Bug 18425 (similar issue for hyperlinks)
* Bug 19104 (similar issue for radio/checkbox inputs)
* Bug 20138 (similar issue for file inputs)

Issue also present in Google Chrome 0.3.154.9

Demo attachment to follow.

Created attachment 25169 [details]
page demonstrating bug

Confirming that I can reproduce this in both Safari 3.1.2 (525.21), and Google Chrome 0.3.154.9.

I also confirm this bug. It still happens in latest stable release Safari 4.0 build 530.17.
Focused <input type="button" ...> with mouse-clicking does not render outline borders. 
This also affects CSS rules like:

input:focus
{
outline-width: 4px;
outline-style: solid;
outline-color: red;
}

A good testcase for this bug is

http://www.gtalbot.org/DHTMLSection/AdvancedCSSButtons.html

regards, Gérard

Confirm still a problem in Safari 4.0 540.17 and Google Chrome 3.0.197.11 (Official Build 22553)...

Created attachment 40241 [details]
Fix for the html elements not focused by mouse

It appears that this bug is fixed already for GTK build.
I suggest to take this fix into all versions by removing GTK #ifdef.

Comment on attachment 40241 [details]
Fix for the html elements not focused by mouse

This is wrong for Mac OS X at least, so please don't check this in without further discussion. This might need to be discussed on the webkit-dev mailing list rather than just in this bug.

Also, this patch has no change log or test case, so it needs to be review- in any case.

(In reply to comment #6)
> (From update of attachment 40241 [details])
> This is wrong for Mac OS X at least,

Have tried it on Mac. 
Good test page http://testsuite.nokia-boston.com/content/xhtml_forms/text_input/form_input.xhtml

1. Radio buttons and check boxes are not focusable by mouse
2. Radio buttons and check boxes also not focusable through tabbed browsing. Weird! It's different from all other browsers.

So, radio buttons and check box lists are some special exceptions?

> so please don't check this in without further discussion. 

Yes, that's what I want.

> This might need to be discussed on the webkit-dev mailing
> list rather than just in this bug.

Could you start this discussion? I hope this way it will attract more attention.

> Also, this patch has no change log 

I never hoped that this will go as it is. It just to start the discussion.

> or test case, 

Isn't it so, that tests attached to the bug are also tests for the fix?
In any case, here is good test page: http://testsuite.nokia-boston.com/content/xhtml_forms/text_input/form_input.xhtml

> so it needs to be review- in any case.

That's Ok.
1st I need to figure out what is correct behavior in this case.
My impression now, that #if PLATFORM(GTK) should be changed to 
#if PLATFORM(MAC)
    return false;
#else
    return HTMLElement::isMouseFocusable();
#endif

Created attachment 40393 [details]
Fix for the html elements not focused by mouse.

Created attachment 40394 [details]
Fix for the html elements not focused by mouse.

Previous diff is wrong.

this is still a bug even today in google chrome 5.0.322.2 dev

somebody posted a fix below - any news when it will be implemented?

Created attachment 53227 [details]
Fix with layout test.

ostapenko, did I missing something or LayoutTests/platform/qt/fast/events/click-focus-control-expected.txt and LayoutTests/fast/events/click-focus-control-expected.txt are equal?

if so, you only need the latter.

Created attachment 53258 [details]
Fix update

Created attachment 56930 [details]
Add comment to Changelog.

Patch makes Mac the only port where html elements are non-mouse-focusable, which seems reasonable. So although patch LGTM, I would rather ask in the mailing list first if there are other ports interested in keeping the current behaviour, e.g. Chromium and Qt on Mac (?) for consistency.

also, adding ap as a potential reviewer.

+# Mac shouldn't focus on some control elements 
+# https://bugs.webkit.org/show_bug.cgi?id=22261 
+fast/events/click-focus-control.html 

The test should have Mac-specific results then, to guarantee that this doesn't regress.

I'm not sure how to decide where this is desirable. I'd expect Windows Safari to behave the same as Mac Safari does. And maybe Mac versions of all WebKit-based browsers. Or perhaps all WebKit based browsers should work the same - there is no discussion of actual user facing problems here, so I'm not sure what exactly needs to be fixed.

(In reply to comment #17)
> +# Mac shouldn't focus on some control elements 
> +# https://bugs.webkit.org/show_bug.cgi?id=22261 
> +fast/events/click-focus-control.html 
> 
> The test should have Mac-specific results then, to guarantee that this doesn't regress.

Ok. Do I have to add MAC specific ...-expected.txt to MAC folder?

> I'm not sure how to decide where this is desirable. 
> I'd expect Windows Safari to behave the same as Mac Safari does. 

Actually, this bug is reported against windows safari ;)
And I find somewhat weird, that some UI elements are "more equal" than others on MAC. Why some elements can be focused and some not? There was similar issue with keyboard tab stops on MAC (for all dialogs), but recently it was fixed and now it is possible to enable "Full Keyboard Access".

> And maybe Mac versions of all WebKit-based browsers. 
> Or perhaps all WebKit based browsers should work the same

There is an opinion, that html control elements should work the same on all platforms (at least for qtwebkit). 

> - there is no discussion of actual user facing problems here, so I'm not sure what exactly needs to be fixed.

There are several reports about the same issue here, so I think there is an issue.

> There are several reports about the same issue here, so I think there is an issue.

OK, so what the issue is? Is it just being different from other browsers, or causing problems to users? Are there any sites affected?

The problem is just different behaviour to other browsers - affects Chrome and Safari on Windows where this is definitely not the expected behaviour.

From this comment it seems that the original intention was just to create a different behavior for Safari on the MAC.

<<In Safari we don't want to take the focus away from a text field when we click on, say, a form button. But I suspect this could be something specific to Macintosh, so I am leaving this code here inside !APPLE_CHANGES. This will probably change when we do more of the keyboard navigation work.>>

This changeset - http://trac.webkit.org/changeset/5345 factored the APPLE_CHANGES guard out and lost the original intention to make this change only for MAC.

Any update on this? Antonio, is this slightly related to what you have been working on? like the editing behaviour that is also different for each platform?

(In reply to comment #22)
> Any update on this? Antonio, is this slightly related to what you have been working on? like the editing behaviour that is also different for each platform?

I think it can be a platform specific editing behavior, yes. Darin, Ojan, what do you think?

Making this a Mac vs. Windows difference could lead to websites that work only on Mac or only on Windows. So it’s undesirable.

But generally speaking, clicking on a button on Mac OS X does not focus that button.

(In reply to comment #24)
> Making this a Mac vs. Windows difference could lead to websites that work only on Mac or only on Windows. So it’s undesirable.

What about other browsers? Only webkit based browsers have this kind of behavior.

> But generally speaking, clicking on a button on Mac OS X does not focus that button.

But other platforms do focus. And this was initial behavior here, as I understand, and later #ifdef was lost.

(In reply to comment #25)
> (In reply to comment #24)
> > But generally speaking, clicking on a button on Mac OS X does not focus that button.
> 
> But other platforms do focus.

Yes.

> And this was initial behavior here, as I understand, and later #ifdef was lost.

Don’t read too much into the #ifdef. At first, every single WebKit change had APPLE_CHANGES around it.

(In reply to comment #24)
> Making this a Mac vs. Windows difference could lead to websites that work only on Mac or only on Windows. So it’s undesirable.
> 
> But generally speaking, clicking on a button on Mac OS X does not focus that button.

I agree that making this a Mac vs. Win/Linux difference is undesirable. It's not clear to me what conclusion to draw from that though. 

Every other browser, including Firefox-Mac and Opera-mac, focuses buttons on mousedown. For the sake of compatibility with other browsers, I think we should make buttons mouse focusable. Otherwise, we put a burden on web developers to send WebKit down a different codepath.

It's hard to find sites that break due to this because they'll often work around it. For example, Gmail used to have code to work around this before they moved to div-based buttons. I'm sure other sites have the same. Consistency with other browsers seems like a sufficient argument to me.

(In reply to comment #27)
> Every other browser, including Firefox-Mac and Opera-mac, focuses buttons on mousedown.

OK, I think we can live with it in future Safari.

Now we just need to deal with that other issue, Safari has done it this way for 8 years so there’s a good chance sites have Safari-specific code paths depending on the old behavior. And this goes even more for things like Dashboard. So ... we have to find out if that’s true and figure out what to do about it.

This comes up often in the WebKit project, so there is some understanding about how to make changes like this. We need some time and some testing to find out if we can just completely drop the old behavior or if we need it in some places.

fwiw, spun off Qt only bug is bug 40641

> This comes up often in the WebKit project, so there is some understanding about how to make changes like this. We need some time and some testing to find out if we can just completely drop the old behavior or if we need it in some places.

Darin, just checking back in on this. Is this still on someone's TODO list?

(In reply to comment #30)
> Darin, just checking back in on this. Is this still on someone's TODO list?

Maybe there’s a misunderstanding. I don’t think I said it was on anyone’s to do list.

> Maybe there’s a misunderstanding. I don’t think I said it was on anyone’s to do list.

Yup, there is a misunderstanding. :) Can you describe what you had in mind in comment 28 for testing whether we can make this change? I'm just trying to understand how to move this forward.

(In reply to comment #32)
> > Maybe there’s a misunderstanding. I don’t think I said it was on anyone’s to do list.
> 
> Yup, there is a misunderstanding. :) Can you describe what you had in mind in comment 28 for testing whether we can make this change? I'm just trying to understand how to move this forward.

Someone working on WebKit needs to do some research to see if Dashboard widgets are affected by the change. And do some additional research to see if there are websites depending on the old behavior.

Anyone with a Mac can also get the widgets at <http://www.apple.com/downloads/dashboard/>.

Some people may have a way to do research on what sites on the web might be affected. I’ve heard that Google has some tools that might help with this sort of research.

> Someone working on WebKit needs to do some research to see if Dashboard widgets are affected by the change. And do some additional research to see if there are websites depending on the old behavior.

Is there any documentation on how to test Dashboard widgets with a local WebKit build?

> Some people may have a way to do research on what sites on the web might be affected. I’ve heard that Google has some tools that might help with this sort of research.

The only tool I know of for this sort of thing is a instrumented Chrome with and without a given patch that loads web pages and looks for "significant" layout differences. I don't think it would work for this since it requires mouse interaction.

I'll try and make some time to do this testing (or find someone who can).

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

Comment on attachment 56930 [details]
Add comment to Changelog.

The change to mac/Skipped is wrong.  Also this patch is blocked on compat testing.

This bug should not block QtWebKit 2.0 tracker bug.

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

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

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

Any updates on this issue and what has the conclusion been to get this fixed? Since we are in the realm of browsers, isn't it better to be consistent whenever possible with the prevailing majority (assuming logically-correct behavior of course)? Right now I notice that hyperlinks and inputs etc get focus in IE and FF and opera irrespective of the platform, however Chrome and Safari on either platform don't. I just hope this issue is not ignored because Safari on mac had a behavior X that is dictating the same behavior on other platforms and Chrome.

As for imapact, I think focusing on hyperlinks (Bug 18425) would be useful and :focus working. As people will notice with CSS3 becoming more popular, lot of website have started using <a> decorated with css as buttons. Events being fired properly will help developers just in case they are doing something when this type of button gets focused.

Some other site issues
http://code.google.com/p/chromium/issues/detail?id=42157

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

FWIW, Bug 38696 is similar, and similarly stalled on testing I'm not sure how exactly to do.

Related issue: http://code.google.com/p/chromium/issues/detail?id=142188

Maybe we need to tie this due to editing behavior. I'm pretty certain we want it be focusable on all non-Mac platforms.

(In reply to comment #44)
> Related issue: http://code.google.com/p/chromium/issues/detail?id=142188
> 
> Maybe we need to tie this due to editing behavior. I'm pretty certain we want it be focusable on all non-Mac platforms.

Perhaps it should depend on tab-focus policy. My feeling is that this behavior is appropriate if and only if buttons are tab-focusable. In Safari on Mac (and probably other Mac browsers) they are not by default, but can be set to be in the tab cycle (via both System Preferences and Safari Preferences).

(In reply to comment #45)
> (In reply to comment #44)
> > Related issue: http://code.google.com/p/chromium/issues/detail?id=142188
> > 
> > Maybe we need to tie this due to editing behavior. I'm pretty certain we want it be focusable on all non-Mac platforms.
> 
> Perhaps it should depend on tab-focus policy. My feeling is that this behavior is appropriate if and only if buttons are tab-focusable. In Safari on Mac (and probably other Mac browsers) they are not by default, but can be set to be in the tab cycle (via both System Preferences and Safari Preferences).

So, to be clear, you're disagreeing with Darin's preference to avoid Mac vs Windows differences? I'm OK with making this a Setting. I'd rather do that than an editing behavior since Chrome will want to do this on Mac as well.

FWIW, here's another bug report we've received about how this causes web developers difficulties:
"I have a div which is set to -webkit-user-modify: read-write. When i place my cursor in the div, it gets focus and indeed accepts input. When I tap outside of the div, I get a blur event on the div, and lose focus. So far so good and as expected.

If I however tap on a button which is outside of the div, then I do get a blur event, yet my cursor remains on screen and indeed continues to accept input. Even though the div now no longer has focus (it even loses the blue focus border).  I've attached a quick demo html to this email.

My code had assumed that when my content editable div loses focus (receives a blur), then I stop listening for DOM Mutations. Clearly, if it still can receive input even when it hasn't got focus that means my code is broken. Is this is a bug, or should I somehow use something else than the blur event to determine when my div will stop accepting input ?"

(In reply to comment #46)
> If I however tap on a button which is outside of the div, then I do get a blur event, yet my cursor remains on screen and indeed continues to accept input. Even though the div now no longer has focus (it even loses the blue focus border).  I've attached a quick demo html to this email.
> 
> My code had assumed that when my content editable div loses focus (receives a blur), then I stop listening for DOM Mutations. Clearly, if it still can receive input even when it hasn't got focus that means my code is broken. Is this is a bug, or should I somehow use something else than the blur event to determine when my div will stop accepting input ?"

This is not caused by this bug. The focus has moved. The selection hasn't. See https://bugs.webkit.org/show_bug.cgi?id=38696 and https://bugs.webkit.org/show_bug.cgi?id=61310.

(In reply to comment #47)
> This is not caused by this bug. The focus has moved. The selection hasn't. See https://bugs.webkit.org/show_bug.cgi?id=38696 and https://bugs.webkit.org/show_bug.cgi?id=61310.

I suppose there are multiple bugs here. document.activeElement points to the body, not the button after the click. The focus moved, but not to the button. That said, I agree that fixing the other two bugs would address that issue.

(In reply to comment #46)
> (In reply to comment #45)
> > (In reply to comment #44)
> > > Related issue: http://code.google.com/p/chromium/issues/detail?id=142188
> > > 
> > > Maybe we need to tie this due to editing behavior. I'm pretty certain we want it be focusable on all non-Mac platforms.
> > 
> > Perhaps it should depend on tab-focus policy. My feeling is that this behavior is appropriate if and only if buttons are tab-focusable. In Safari on Mac (and probably other Mac browsers) they are not by default, but can be set to be in the tab cycle (via both System Preferences and Safari Preferences).
> 
> So, to be clear, you're disagreeing with Darin's preference to avoid Mac vs Windows differences? I'm OK with making this a Setting. I'd rather do that than an editing behavior since Chrome will want to do this on Mac as well.

My suggestion is not to make it any of a hardcoded Mac vs Windows difference, a Setting, or an editing behavior. My suggestion is that non-text form controls such as buttons should be focusable by click if and only if they are focusable in the tab cycle. And likewise for links.

This could be achieved by making HTMLFormControlElement::isMouseFocusable() check document()->frame()->eventHandler()->tabsToAllFormControls(), which has platform-specific implementations, some of which always return true, and others of which (Mac in particular) make it a runtime setting and others which might return always false.

For clarity it may make sense to add EventHandler::allFormControlsAcceptMouseFocus() which just calls tabsToAllFormControls.

It is true that this will create a web-content-observable difference that is partly a platform difference. However, we already have such a difference for tab-focus. It seems sensible to me to make mouse-focus consistent with tab-focus, even though it slightly expands the scope of the difference.

This would also allow removing the hardcoded special case for Gtk and Qt.

[...snip specific issue report because I agree with Ryosuke that it's actually a different bug...]

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

It's been 4.5 years since this bug was first reported. Presumably the fix is simple (I looked at the patch) but it seems Apple folks (Darian, Alexey, etc.) can't agree to it and the debate is still going on. Let me make another pitch for it:

This makes webkit different from everything else on Windows. I don't care about Safari on Mac or Windows but sadly this affects Chrome on Windows, which I do care about. See comment #20 from Daniel. I strongly urge the Apple folks to be a little open minded about this. It DOES affect end users.

This was apparently not the behavior in the original webkit but it was inadvertently introduced due to "code cleanup". See comment #21 from Lazlo.

Regarding the option to make it configurable (comment #49 from Maciej), that would work as long as the default on Windows is the behavior that is being asked for. Obviously, the Apple group doesn't want that default for Mac, so the default will have to be conditionally compiled. So that would essentially make the configuration choice pointless because no one would bother changing it.

Chrome has forked WebKit, and they have a separate bug database now. If you only care about Chrome, then WebKit bug database is not the right place for advocacy.

(In reply to comment #53)
> Manish: We are fixing this in Blink
> 
> https://code.google.com/p/chromium/issues/detail?id=89708
> https://codereview.chromium.org/16194013/

That's really good to hear. I look forward to the fix and will keep an eye on it. Thanks for the update, Eric.

I know it has been a while but... any update or clear status for this strange bug?

It's nothing short of bizarre that this bug is more than 12 years old and yet still plagues Safari. This is resulting in places that we would prefer using `display: flex` to instead be obliged to use `display: grid`. Someone please tell me that they're working on fixing this.