Bug 22261 - Clicking on a non-text input element does not give it focus
Summary: Clicking on a non-text input element does not give it focus
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 525.x (Safari 3.1)
Hardware: PC Windows Server 2003
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 19104 63299 105690 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-11-14 04:15 PST by Mike Capp
Modified: 2013-06-12 10:21 PDT (History)
29 users (show)

See Also:


Attachments
page demonstrating bug (1.01 KB, application/xhtml+xml)
2008-11-14 04:19 PST, Mike Capp
no flags Details
Fix for the html elements not focused by mouse (467 bytes, patch)
2009-09-28 09:25 PDT, Viatcheslav Ostapenko
darin: review-
Details | Formatted Diff | Diff
Fix for the html elements not focused by mouse. (717 bytes, patch)
2009-09-30 13:03 PDT, Viatcheslav Ostapenko
no flags Details | Formatted Diff | Diff
Fix for the html elements not focused by mouse. (1.14 KB, patch)
2009-09-30 13:06 PDT, Viatcheslav Ostapenko
eric: review-
Details | Formatted Diff | Diff
Fix with layout test. (5.81 KB, patch)
2010-04-12 23:50 PDT, Viatcheslav Ostapenko
no flags Details | Formatted Diff | Diff
Fix update (5.10 KB, patch)
2010-04-13 10:07 PDT, Viatcheslav Ostapenko
no flags Details | Formatted Diff | Diff
Add comment to Changelog. (5.23 KB, patch)
2010-05-24 14:49 PDT, Viatcheslav Ostapenko
abarth: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Capp 2008-11-14 04:15:14 PST
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.
Comment 1 Mike Capp 2008-11-14 04:19:32 PST
Created attachment 25169 [details]
page demonstrating bug
Comment 2 Andrzej Doyle 2008-11-18 06:19:09 PST
Confirming that I can reproduce this in both Safari 3.1.2 (525.21), and Google Chrome 0.3.154.9.
Comment 3 Gérard Talbot 2009-06-14 15:28:42 PDT
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
Comment 4 Daniel Wagner-Hall 2009-08-08 03:16:44 PDT
Confirm still a problem in Safari 4.0 540.17 and Google Chrome 3.0.197.11 (Official Build 22553)...
Comment 5 Viatcheslav Ostapenko 2009-09-28 09:25:11 PDT
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 6 Darin Adler 2009-09-28 09:53:58 PDT
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.
Comment 7 Viatcheslav Ostapenko 2009-09-28 10:51:23 PDT
(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
Comment 8 Viatcheslav Ostapenko 2009-09-30 13:03:48 PDT
Created attachment 40393 [details]
Fix for the html elements not focused by mouse.
Comment 9 Viatcheslav Ostapenko 2009-09-30 13:06:52 PDT
Created attachment 40394 [details]
Fix for the html elements not focused by mouse.

Previous diff is wrong.
Comment 11 dave 2010-02-16 05:17:15 PST
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?
Comment 12 Viatcheslav Ostapenko 2010-04-12 23:50:10 PDT
Created attachment 53227 [details]
Fix with layout test.
Comment 13 Antonio Gomes 2010-04-13 07:57:05 PDT
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.
Comment 14 Viatcheslav Ostapenko 2010-04-13 10:07:23 PDT
Created attachment 53258 [details]
Fix update
Comment 15 Viatcheslav Ostapenko 2010-05-24 14:49:07 PDT
Created attachment 56930 [details]
Add comment to Changelog.
Comment 16 Antonio Gomes 2010-05-25 06:03:56 PDT
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.
Comment 17 Alexey Proskuryakov 2010-05-28 12:07:11 PDT
+# 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.
Comment 18 Viatcheslav Ostapenko 2010-06-01 12:11:20 PDT
(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.
Comment 19 Alexey Proskuryakov 2010-06-01 12:26:50 PDT
> 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?
Comment 20 Daniel Wagner-Hall 2010-06-01 12:54:49 PDT
The problem is just different behaviour to other browsers - affects Chrome and Safari on Windows where this is definitely not the expected behaviour.
Comment 21 Laszlo Gombos 2010-06-01 13:49:51 PDT
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.
Comment 22 Kenneth Rohde Christiansen 2010-06-11 19:02:28 PDT
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?
Comment 23 Antonio Gomes 2010-06-14 06:29:51 PDT
(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?
Comment 24 Darin Adler 2010-06-14 16:37:40 PDT
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.
Comment 25 Viatcheslav Ostapenko 2010-06-14 16:48:38 PDT
(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.
Comment 26 Darin Adler 2010-06-14 16:50:14 PDT
(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.
Comment 27 Ojan Vafai 2010-06-16 12:02:14 PDT
(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.
Comment 28 Darin Adler 2010-06-16 15:54:40 PDT
(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.
Comment 29 Antonio Gomes 2010-07-06 14:01:22 PDT
fwiw, spun off Qt only bug is bug 40641
Comment 30 Ojan Vafai 2010-07-22 16:04:12 PDT
> 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?
Comment 31 Darin Adler 2010-07-22 17:15:30 PDT
(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.
Comment 32 Ojan Vafai 2010-07-22 17:41:22 PDT
> 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.
Comment 33 Darin Adler 2010-07-22 18:53:31 PDT
(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.
Comment 34 Ojan Vafai 2010-07-23 11:46:42 PDT
> 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).
Comment 35 Simon Fraser (smfr) 2010-10-09 08:29:53 PDT
*** Bug 19104 has been marked as a duplicate of this bug. ***
Comment 36 Adam Barth 2010-10-10 11:15:36 PDT
Comment on attachment 56930 [details]
Add comment to Changelog.

The change to mac/Skipped is wrong.  Also this patch is blocked on compat testing.
Comment 37 Antonio Gomes 2010-10-13 06:17:52 PDT
This bug should not block QtWebKit 2.0 tracker bug.
Comment 38 Alexey Proskuryakov 2011-01-08 14:03:24 PST
*** Bug 18425 has been marked as a duplicate of this bug. ***
Comment 39 Alexey Proskuryakov 2011-01-08 14:03:31 PST
*** Bug 52102 has been marked as a duplicate of this bug. ***
Comment 40 Alexey Proskuryakov 2011-01-08 14:04:55 PST
*** Bug 22233 has been marked as a duplicate of this bug. ***
Comment 41 Darth 2011-01-08 15:23:33 PST
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
Comment 42 Daniel Bates 2011-06-23 22:45:21 PDT
*** Bug 63299 has been marked as a duplicate of this bug. ***
Comment 43 Levi Weintraub 2011-06-27 14:54:25 PDT
FWIW, Bug 38696 is similar, and similarly stalled on testing I'm not sure how exactly to do.
Comment 44 Ryosuke Niwa 2012-08-22 10:46:50 PDT
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.
Comment 45 Maciej Stachowiak 2012-09-15 21:46:29 PDT
(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).
Comment 46 Ojan Vafai 2012-10-04 11:47:58 PDT
(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 ?"
Comment 47 Ryosuke Niwa 2012-10-04 11:53:12 PDT
(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.
Comment 48 Ojan Vafai 2012-10-04 12:02:27 PDT
(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.
Comment 49 Maciej Stachowiak 2012-10-04 12:24:02 PDT
(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...]
Comment 50 Alexey Proskuryakov 2012-12-31 19:16:46 PST
*** Bug 105690 has been marked as a duplicate of this bug. ***
Comment 51 Manish 2013-06-11 12:03:25 PDT
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.
Comment 52 Alexey Proskuryakov 2013-06-11 12:11:15 PDT
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.
Comment 53 Erik Arvidsson 2013-06-11 12:13:24 PDT
Manish: We are fixing this in Blink

https://code.google.com/p/chromium/issues/detail?id=89708
https://codereview.chromium.org/16194013/
Comment 54 Manish 2013-06-12 10:21:11 PDT
(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.