| Summary: | Clicking on a non-text input element does not give it focus | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Mike Capp <mike.capp> | ||||||||||||||||
| Component: | Forms | Assignee: | Nobody <webkit-unassigned> | ||||||||||||||||
| Status: | RESOLVED WONTFIX | ||||||||||||||||||
| Severity: | Normal | CC: | 04-punch-pinyons, aaron, adele, akeerthi, alex.wayfer, anantha, andrzej.doyle, andy.blum.01, ap, arne, aroben, arv, browserbugs2, bugs.webkit.org, bugzilla, bweinstein, darin, dave.batiste, dawagner, dieter, dsuchkov511, emilio, eric, giovanni.piller, hausmann, hedgerwang, jab_creations, jasneet, kenneth, kizmarh, koivisto, laszlo.gombos, leviw, manish3177, martyn.chamberlin, matzew, m.goleb+bugzilla, mijordan, mitz, mjs, priyajeet.hora, proskater55, raphael, redux, rego, rniwa, sporter, tonikitoo, webkit, wesleydesouza | ||||||||||||||||
| Priority: | P2 | ||||||||||||||||||
| Version: | 525.x (Safari 3.1) | ||||||||||||||||||
| Hardware: | PC | ||||||||||||||||||
| OS: | Windows Server 2003 | ||||||||||||||||||
| See Also: |
https://bugs.webkit.org/show_bug.cgi?id=112968 https://bugs.webkit.org/show_bug.cgi?id=18425 |
||||||||||||||||||
| Bug Depends on: | |||||||||||||||||||
| Bug Blocks: | 26856, 267449 | ||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
|
Description
Mike Capp
2008-11-14 04:15:14 PST
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.
Comment on attachment 40394 [details] Fix for the html elements not focused by mouse. All changes require tests. Otherwise this looks fine. http://webkit.org/coding/contributing.html http://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree http://trac.webkit.org/wiki/Creating%20and%20Submitting%20Layout%20Tests%20and%20Patches 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. Manish: We are fixing this in Blink https://code.google.com/p/chromium/issues/detail?id=89708 https://codereview.chromium.org/16194013/ (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. Adding my vote that it's pretty terrible that this behavior is different than the rest of the browsers, going on 13 years. It would seem that this bug makes the recent for for ":focus-visible" pointless in Safari. Having to find work-arounds for components that rely on the focus not arbitrarily moving to the body when a user clicks a button. This bug is forcing people to do hacky things. Is their any intention of fixing this? (In reply to Dave from comment #57) > Adding my vote that it's pretty terrible that this behavior is different > than the rest of the browsers, going on 13 years. It would seem that this > bug makes the recent for for ":focus-visible" pointless in Safari. Having to > find work-arounds for components that rely on the focus not arbitrarily > moving to the body when a user clicks a button. This bug is forcing people > to do hacky things. Is their any intention of fixing this? I believe that if we use :focus-visible in the default UA stylesheet, then we could make buttons focusable even on Mac platform, as they won't be showing any focus ring (which I understand it's something people want to avoid). This will differ from the general Mac platform behavior somehow, but will align us with other browsers (Firefox has recently changed this in Mac too). Also current WebKit behavior on Mac (e.g. an <input> loses focus when you click a <button>) doesn't match exactly what happens in the Mac platform (see https://bugzilla.mozilla.org/show_bug.cgi?id=1699570#c1). (In reply to Manuel Rego Casasnovas from comment #58) > (In reply to Dave from comment #57) > > Adding my vote that it's pretty terrible that this behavior is different > > than the rest of the browsers, going on 13 years. It would seem that this > > bug makes the recent for for ":focus-visible" pointless in Safari. Having to > > find work-arounds for components that rely on the focus not arbitrarily > > moving to the body when a user clicks a button. This bug is forcing people > > to do hacky things. Is their any intention of fixing this? > > I believe that if we use :focus-visible in the default UA stylesheet, then > we could make buttons focusable even on Mac platform, as they won't be > showing any focus ring (which I understand it's something people want to > avoid). Not really. Buttons can't be focused via keyboard by default, for example, and it's non-sensical for a button to have a focus. That's not really a thing on macOS unless you change the system preferences. *** Bug 20138 has been marked as a duplicate of this bug. *** *** Bug 118043 has been marked as a duplicate of this bug. *** This is behaving as intended. *** Bug 26856 has been marked as a duplicate of this bug. *** *** Bug 226148 has been marked as a duplicate of this bug. *** I recently came across this bug and posted report: https://bugs.webkit.org/show_bug.cgi?id=226148 It seems that the prevailing gate keepers attitude is that Safari is an operating system, not a browser that must adhere to consistent behavior and standards. There was another browser like that though I can't seem to remember it's name... The primary point is that a successful product or service does what it's users need. When people in leadership positions fail to comprehend that most fundamental aspect of usability those products and services fail. (In reply to John A. Bilicki III from comment #65) > It seems that the prevailing gate keepers attitude is that Safari is an > operating system What? No. > When people in leadership positions fail to comprehend that most > fundamental aspect of usability those products and services fail. Could you be more specific? I think you are saying that you don’t agree that Safari should match how focus works on Mac and instead needs to match how focus works on Windows? How does that makes Safari an operating system? > When people in leadership positions fail to comprehend that most > fundamental aspect of usability those products and services fail. >Could you be more specific? Safari is not accessible; most designers and developers who don't own one to simply test Safari (I do, though I still don't have text labels on the GUI buttons or even a Reload button that I could at least have to go out of my way to enable for crying out loud so why would I willingly use it). They're wildly expensive considering not only the markup on the hardware though also the inability to customize the GUI or to be more precise without spending even more money. This removes incentives for many designers and developers to buy Apple products. So when those websites break those designers and developers do not care because if they do care about something it's about creating consistent behavior with the hardware and software that they do have access to. And that is for those trying to build websites don't just give up, abandon their customers and go in to something unrelated like selling insurance. That isn't how you create brand loyalty, that is how you create a cult, one that will one day be very easily convertible. > How does that makes Safari an operating system? No, Safari is a browser - the attitude of the gatekeepers here is to treat Safari like the operating system with it's limiting attitudes. In this situation the only proper thing to do is make the browser consistent in behavior, that is the point of cross-browser consistency. The attitudes could be constructively channeled in to creating an opt-in option to make Safari non-consistent with other browsers though consistent with the operating system. Besides, most importantly - what is the benefit of not focusing a button? That is literal anti-accessibility. The point of my bug report was to make my web platform extremely accessible to my users. The example was having 50 out of 100 email messages test messages that I just want to delete and obviously the check-all checkbox isn't a viable option in such a scenario. I wrote a script that when you press the up or down array key after clicking a checkbox would navigate to the next checkbox above or below and change it's checked state to that of the previous checkbox - absolutely genius as it's much faster, accurate and most importantly saves time! Most people don't want to have to battle their computer to do something simple in their minds, they have lives or are at least battling to get their lives on track. There are literally groups of people dedicated towards accessibility and usability literally telling whoever the gatekeepers are here for the past 13+ years at this point that the end user who actually uses products or services is more important than some snob's attitude who presumes that because they wouldn't use it that no one would. If you drive then you know that most other people are idiots. So yes, other people DO things that you wouldn't, though you might be the fool with five lanes though still blocking incoming traffic from on-ramps doing 15 slower than everyone else creating dangerous scenarios all in the name of driving "slow is safe". I've only had my success not by being wrong though by becoming aware of when I'm wrong. When someone wants to do something that I don't understand on my platform I resolve to know if it ultimately serves a use to someone that allows them to accomplish something even if I would never personally find any use for such a scenario. My goal is to make other people's lives better and the idea that I know all or that my personal preferences are somehow the end-all-be-all is not an attitude I tolerate, most especially in myself. So the choice is simple: either do what people need and want or continue to enforce the ivory tower attitude. (In reply to John A. Bilicki III from comment #67) > what is the benefit of not focusing a button? This is the benefit: Mac users expect the focus to remain in the text field if you click on a button. That’s what happens everywhere else on their computer in all the Mac applications. It’s a benefit that buttons work as expected, consistent with other buttons on the Mac, and don't pull the focus away from the text field you are already typing in. I understand that if you’ve never used a Mac you might not be aware that this is a benefit, but I assure you that it is. If I understand your argument correctly, reading through and trying not to be offended by the repeated accusations of bad faith, bad intentions, and insufficient empathy for our fellow human beings, you are saying that this choice makes it impossible to make websites work accessibly, and is simply an expression of arrogance and bad decision making and a lack of care for other people. That’s not our intent. We’d like this to fit in well with other Mac software. > I understand that if you’ve never used a Mac you might not be aware that this is a benefit, but I assure you that it is. Please share an easy to comprehend example of how having the focus remain on a previous element after clicking on another is somehow beneficial, especially when it creates an inconsistent behavior between browsers when the topic if explicitly NOT about operating systems. I have an overpriced two-core 8GB under-powered Mac Mini from 2014 (released after they had already released quad cores as the lowest cost Mac Mini previously) that still did not include an SSD while costing minimally twice the price of better equipped PCs that I can test everything on though can not physically upgrade. Also, please tell me how (if when my mouse stops working and I only have a keyboard at my immediate disposal) that not being able to activate buttons because buttons can't be focused somehow helps me? > That’s not our intent. We’d like this to fit in well with other Mac software. I get wanting to have things fit well as an overall platform - I'm the solo-founder of an entire platform myself. The problem: we're talking about browser consistency, not operating systems. Your platform isn't easily accessible due to it's high cost and low compatibility - I don't have the option to operate a Mac the way *I* need to operate the Mac and therefore at best I simply use it to test Safari. Most people don't start out with a Mac just laying around and these inconsistencies will Microsoft's near-monopolist market share reduce the overall user experience on Macs. I absolutely get the seething hatred towards Microsoft and their ... antics however if you believe in creating a successful product or service that competes with counterparts such as other browsers it needs to have meet standards and have consistent behavior. (In reply to Darin Adler from comment #68) > Mac users expect the focus to remain in the text field if you click on a > button. That’s what happens everywhere else on their computer in all the Mac > applications. It’s a benefit that buttons work as expected, consistent with > other buttons on the Mac, and don't pull the focus away from the text field > you are already typing in. Thank you for explaining this. I had no idea about this. What about button-type input or HTML buttons which are not related to a textfield? Epiphany 3.32.1.2 (which uses WebKitGTK+ 2.30.6) under Linux focuses button-type input: http://www.gtalbot.org/DHTMLSection/AdvancedCSSButtons.html What about radio buttons and check boxes? from #c7: > 1. Radio buttons and check boxes are not focusable by mouse > 2. Radio buttons and check boxes also not focusable through tabbed browsing. from #c24 > generally speaking, clicking on a button on Mac OS X does not focus that button. " The focus event occurs when an element receives focus either via a pointing device or by tabbing navigation. This event is valid for the following elements: LABEL, INPUT, SELECT, TEXTAREA, and BUTTON. " coming from https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents I have tried to see if this is still true in latest www.w3.org/TR/uievents/ and my attempt was inconclusive. Disclaimer: Unfortunately, I do not use MacOS; so, I do not use Safari. I do not have access to a Mac or Safari (like in an Internet Cafe or have a friend living nearby who uses a Mac). I do not want anyone to presume that I imply or infer bad faith or bad intent or lack of empathy toward Safari developers or MacOS engineers. I do not want people to think that my questions are trying to annoy or contradict MacOS or Safari developers. (In reply to Darin Adler from comment #68) > (In reply to John A. Bilicki III from comment #67) > > what is the benefit of not focusing a button? > > This is the benefit: > > Mac users expect the focus to remain in the text field if you click on a > button. That’s what happens everywhere else on their computer in all the Mac > applications. It’s a benefit that buttons work as expected, consistent with > other buttons on the Mac, and don't pull the focus away from the text field > you are already typing in. > > I understand that if you’ve never used a Mac you might not be aware that > this is a benefit, but I assure you that it is. > > If I understand your argument correctly, reading through and trying not to > be offended by the repeated accusations of bad faith, bad intentions, and > insufficient empathy for our fellow human beings, you are saying that this > choice makes it impossible to make websites work accessibly, and is simply > an expression of arrogance and bad decision making and a lack of care for > other people. > > That’s not our intent. We’d like this to fit in well with other Mac software. I fully appreciate that Apple has the best intentions in making buttons in Safari behave the same as buttons in MacOS apps, but web developers require browser consistency in order to deliver applications and features to those users. Without that consistency, developers are relegated to conditional code and terrible work-arounds to accommodate those differences in behavior, or worse, those features don't work properly in Safari (which is the case that prompted my previous reply). If web apps break because of browser inconsistencies, users are certainly worse off. While I am sure Apple has (or at had) some use cases to justify this behavior, as a long-time Mac users I'm not sure what the benefits are, and that ought to make designers think twice. (In reply to Maciej Stachowiak from comment #49) > (...) should be focusable by click if and > only if they are focusable in the tab cycle. And likewise for links. Bug 18425: Link doesn't receive focus when clicked https://bugs.webkit.org/show_bug.cgi?id=18425 (In reply to Dave from comment #71) > web developers require browser consistency in order to deliver applications and features to those users I think this is the crux of the matter. People are strongly encouraging Safari to adopt Windows-style focus on buttons, check boxes, etc., even though this is not natural for most macOS users, because the other browsers, all of which have more users on Windows than Mac, have chosen to make the browser world a world of Windows-style within a window, even on Mac. Perhaps in the end the Safari will be *forced* to do this, because we simply can’t resist the tide of all those website developers who are relying on this aspect of how Windows works, perhaps without even being aware of that, within webpages. The webpages that are theoretically and aspirationally platform-independent, but in the end strongly depend on this specific behavior from Windows. I do see these impassioned arguments, and I really don’t think the Safari team resistance comes from arrogance: We’re looking out for the many Mac users that find the web browser easier to use when it matches the rest of software on the Mac. Some of these arguments start with the bizarre claim that Apple and Mac are intrinsically "elitist". I really don’t know what to do with that claim; I have no intention of debating it. But I do understand the claim that the Safari team must prioritize the ease of making a website work across browsers by people who will never test that website in Safari, and the strong request that we accept the Windows model on Mac to make that easier. And the related claim that some, or even many, Mac users don’t even care about the inconsistency between the browser and the rest of the Mac software, and those people are happy to accept that in Mac Chrome, for example. On Mac, *nothing* except a text field focuses just because you click on it, unless you turn on accessibility options that allow you to use the keyboard to cycle through everything. Pushing a button does not focus the button. Clicking a check box does not focus the check box. On Windows, keyboard focus is a concept that’s on by default, and all of those things *do* happen. This difference has been around as long as Windows has; it’s one of a few key things that Microsoft changed when implementing concepts that were first on Mac. And these accessibility options that change the focus rules need to affect focus even in web browsers. Thus, it is possible, perhaps even likely, websites that depend sensitively on exactly what is focused are effectively choosing to work only for certain people based on their accessibility options! I suppose it may be too late to change the approach of the web platform. I’m a little sad that it seems "you must match Windows; please drop things that are different about the Mac because it is too difficult to accommodate them and keep websites compatible" is the strongly encouraged approach to cross-browser compatibility. (In reply to Darin Adler from comment #73) > Perhaps in the end the Safari will be *forced* to do this, because we simply can’t resist the tide of all those website developers who are relying on this aspect of how Windows works [The HTML spec](https://html.spec.whatwg.org/multipage/interaction.html) actually calls out that: > the user agent might determine that an element is not click focusable even if it is focusable. For example, in some user agents, clicking on a non-editable form control does not focus it, i.e. the user agent has determined that such controls are not click focusable So the behaviour of Safari on Mac in this case is perfectly fine, and standards-compliant. However, the spec also states that: > User agents should consider focusable areas with non-null tabindex values to be click focusable. Which I interpret as if a button has `tabindex="0"` (or a positive integer) then it should always be focused after being clicked. Currently Safari will treat buttons with non-null tabindex values just the same as buttons with null tabindex values, so this is a bug as it's a violation of the HTML spec. IMO making buttons click focusable if they have a non-null tabindex value is an excellent compromise; it allows the user agent to behave in the system-default way for most situations whilst giving authors the ability to explicitly instruct the user agent that they require a particular button to be focused when clicked. "The webpages that are theoretically and aspirationally platform-independent, but in the end strongly depend on this specific behavior from Windows." Two points here: - it's not just Windows. The same also happens on most (all?) Linux distros and their window managers (and then browsers that run on them). - for the web to work as a platform/host environment agnostic platform in its own right, it needs consistent paradigms. otherwise, you end up exactly back where this started with platform-specific quirks/differences in behaviors. " I’m a little sad that it seems "you must match Windows; please drop things that are different about the Mac because it is too difficult to accommodate them and keep websites compatible" is the strongly encouraged approach to cross-browser compatibility." It's sad, yes, but that's the way cross-browser compatibility has worked for a while. Once certain patterns/approaches get entrenched and are widely relied on, other browsers usually have to grudgingly adapt. There have been plenty of cases where browsers have had to adopt things that were Safari/WebKit specific (e.g. all those prefixed CSS properties, that other browsers had to end up aliasing/emulating) in order to make sites work correctly. "making buttons click focusable if they have a non-null tabindex value is an excellent compromise; it allows the user agent to behave in the system-default way for most situations whilst giving authors the ability to explicitly instruct the user agent that they require a particular button to be focused when clicked." not a big fan of requiring authors to once again add extra markup/putting the onus on them to fix sites to accommodate for an idiosyncratic quirk of one particular user agent... > 1. Radio buttons and check boxes are not focusable by mouse > 2. Radio buttons and check boxes also not focusable through tabbed browsing. Does latest Safari passes these 2 :checked pseudo-class tests? http://wpt.live/css/selectors/old-tests/css3-modsel-25.xml http://wpt.live/css/selectors/old-tests/css3-modsel-70.xml Epiphany 3.32.1.2 (which uses WebKitGTK+ 2.32.1) under Linux passes those 2 tests. https://www.w3.org/TR/selectors-3/#checked - - - - > User agents *should consider* focusable areas with non-null tabindex values to be click focusable. (...) > so this is a bug as it's a violation of the HTML spec. Generally speaking, when reading a spec, "SHOULD" means recommended but not required. https://www.ietf.org/rfc/rfc2119.txt Along with "consider" verb, this means very little. So, this is not a violation of the HTML5 spec. Safari could still claim compliance with the HTML5 spec. (In reply to Gérard Talbot from comment #76) > > User agents *should consider* focusable areas with non-null tabindex values to be click focusable. > (...) > > so this is a bug as it's a violation of the HTML spec. > > Generally speaking, when reading a spec, "SHOULD" means recommended but not > required. > https://www.ietf.org/rfc/rfc2119.txt > Along with "consider" verb, this means very little. So, this is not a > violation of the HTML5 spec. Safari could still claim compliance with the > HTML5 spec. Yes, agreed that 'should' is a recommendation rather than a requirement, but nonetheless recommendations should not be so easily dismissed. It's reasonable for content authors to expect user agents to adhering to the non-null tabindex recommendation from the spec, just as it's reasonable for Safari to choose not to focus on click by default. I think you're misunderstanding the meaning of the verb 'consider' in this context. 'Consider X to be Y' means that you should think of X as Y. E.g., 'you should consider the case closed' does not mean you should think about whether or not the case is closed, it means you should think _that_ the case is closed. Therefore this sentence in the spec is not an instruction for UA authors _to think about whether they want to_ make such elements click focusable, it's an instruction for UA authors to _explicitly treat_ such elements as click focusable. This is quite clear when reading the sentence in the context of the whole section of text in which it appears in the spec. (In reply to Patrick H. Lauke from comment #75) > not a big fan of requiring authors to once again add extra markup/putting > the onus on them to fix sites to accommodate for an idiosyncratic quirk of > one particular user agent... Just like any other part of the spec, the onus is absolutely on content authors to understand it and accommodate it. The spec explicitly states that focus-on-click is not a required behaviour for user agents, and content authors should therefore not take it for granted. Equally the onus is on UA authors to adhere to the spec; which is why I think Safari should adopt the behaviour of treating focusable elements with a non-null tabindex as click-focusable, just as the spec says it should. >> the user agent might determine that an element is not click focusable even if it is focusable. For example, in some user agents, clicking on a non-editable form control does not focus it, i.e. the user agent has determined that such controls are not click focusable >So the behavior of Safari on Mac in this case is perfectly fine, and standards-compliant. Those are elements with the disabled attribute or are hidden by elements with greater z-index layers. >not a big fan of requiring authors to once again add extra markup/putting the onus on them to fix sites to accommodate for an idiosyncratic quirk of one particular user agent... The more quirks we have to deal with the less time we get to spend with our families or on non-work related activities. >Generally speaking, when reading a spec, "SHOULD" means recommended but not required. The point of having a specification or standard is to ELIMINATE the quirks between browsers; the word "SHOULD" has ZERO justification to be in any specification or standard. When someone argues "but..." then THEY are required to distinguish scenarios one and two and clarify any other scenarios requiring clarification. I've personally encountered alarming amounts of incompetence in "standards" such as scrollbar-width. The entire Git conversation was monopolized by people arguing over literal absolute ambiguities. The word 'thin' has zero absolute definition, it was useless because obviously what a Linux die-hard think is "thin" will differ from a Windows die-hard's version of "thin". Therefore the "standard" is pseudo (not really) because it "officialized" ambiguity and ruins forward-compatibility. Therefore when work on my own browser engine begins my team will adhere to proper standards and ignore anything ambiguous. Will people be upset? Yes, though they aren't the ones stuck working until 4AM dealing with who have to be awake to help their families at 8AM. I understand why there is a lot of animosity towards behavior associated with Microsoft products however a good idea is a good idea period. If Mao, Hitler or Stalin say 2 + 2 = 4 and then further clarify that they are explicitly using the decimal system (versus 1 + 1 (spoken) = three and not clarifying binary) the fact that those were absolute evil marxist dictators does not change the fact that the sentence they spoke is true. At the end of the day work on browser engines is either done in the context of helping humans or enforcing some arbitrary notion because of some completely unrelated hatred. Competence and good behavior of a rendering engine is in absolute more important in the context of helping your fellow human beings. *** Bug 229245 has been marked as a duplicate of this bug. *** Hi there! Sorry to stir up old discussions, but I think there's got to be some sort of better behavior that safari could do than the status quo. The main issue I have here is with this assertion: > Mac users expect the focus to remain in the text field if you click on a button. That’s what happens everywhere else on their computer in all the Mac applications. It’s a benefit that buttons work as expected, consistent with other buttons on the Mac, and don't pull the focus away from the text field you are already typing in. If this were the standard behavior and that clicking a button didn't pull focus from the item that currently had it - well, I could live with that. But that's not what happens in Safari. Interacting with a button in safari drops focus entirely. It's not left on the previously focused element, it doesn't go to button, nothing gets focus. Focus just ceases to exist. I've made a codepen to hopefully illustrate my point: https://codepen.io/andy-blum/pen/ExXgxWO Clicking into a text input raises the following events: - mousedown - focus - focusin - mouseup - click Then, clicking into a directly adjacent button: - mousedown (button) - blur (input) - focusout (input) - mouseup (button) - click (button) So... where is the focus? The tabbing order is maintained, but the focus leaves both the input and button. The reason I came across this bug recently was an issue for a search component listening for focusout events to close the type-ahead suggestions. Clicking the search button on this form closes the results and interrupts the submission of the form because the entire component loses focus before the button can even be clicked. I understand the arguments of intention presented here, but the implementation in Safari simply does not align with those intentions and breaks intuitive behavior web developers anticipate and experience in other browsers - regardless of OS. Good point about dropping the focus. Not the same as the bug reported here; might be helpful to file a new more specific bug report about that problem. Thanks for the response, Darin. I've opened a new ticket here: https://bugs.webkit.org/show_bug.cgi?id=229895 Thanks for the response, Darin. I've opened a new ticket here: https://bugs.webkit.org/show_bug.cgi?id=229895 (In reply to Andy Blum from comment #84) > Thanks for the response, Darin. I've opened a new ticket here: > https://bugs.webkit.org/show_bug.cgi?id=229895 Yeah, I think this is a good bug to fix assuming that it's web compatible. Are you two serious? Instead of advocating to fix this bug you go out of your way to post another bug report to advocate the devs to dig in their heels?! How about standardizing some devastating needed questions in the technology industry: 1. How does this help productive members of society? 2. Does this serve a useful purpose? 3. Should I be doing this? 4. Have I had a full, non-interrupted, rational conversation with multiple people who disagrees to help determine if I have objectively determined my answers to the first three questions? While working around this non web-standard behavior, I notice that Safari Developer Tools lets you apply focus to a selected element at the top of the styles pane This magically displays what it the element would look like if it could be focused i.e. Developer Tools has already addressed this bug - shame it didn't make it into the main browser window. *** Bug 235471 has been marked as a duplicate of this bug. *** *** Bug 236725 has been marked as a duplicate of this bug. *** *** Bug 28630 has been marked as a duplicate of this bug. *** *** Bug 13724 has been marked as a duplicate of this bug. *** |