I realize this was a purposeful change made in bug 564277, but the new behavior seems really wrong to me, especially given that I have "All controls" selected as the tab behavior in my OS preferences. STEPS TO REPRODUCE: 1) Load https://bugzilla.mozilla.org/attachment.cgi?bugid=564277&action=enter 2) Click the "Browse" button. 3) Select a file in the filepicker 4) Click "Open" in the filepicker 5) Hit tab EXPECTED RESULTS: Description field is focused, so I can type the attachment description. ACTUAL RESULTS: The very first link on the page is focused, so my typing doesn't do what I expect. Curses follow. ADDITIONAL INFORMATION: 1) If I happen to click on the file input _textfield_ instead, then not only does it get tab focus, but hitting tab while it's focused focuses that very "Browse" button that didn't take focus when I clicked on it; hitting tab again advances to the textfield I actually want. 2) The same issue comes up with checkboxes as well, of course. I think that given my OS preferences we should have different focus behavior here. Failing that, it seems to me that this should be a pref with different default values on different platforms, not a hardcoded thing for mac. Requesting blocking, because this is seriously interfering with my Bugzilla workflow, and I doubt I'm the only user who will be thus impacted.
Alex, any thoughts on this? What's being asked for is that when a mouse click occurs on an element (such as a button), it is focused, which isn't the behaviour that Mac uses. As an aside Safari implements the same behaviour Firefox currently does.
> As an aside Safari implements the same behaviour Firefox currently does. Yes. It also doesn't focus links while tabbing (in spite of the OS preference being set in comment 0), and generally has keyboard navigation that is broken beyond belief... Note that I'm not necessarily asking for the _default_ behavior to change (though I think when the "all controls" option is selected that would make sense), but I'd like to be able to configure the behavior.
>What's being asked for ... isn't the behaviour that Mac uses. >Safari implements the same behaviour Firefox currently does. both a strong points for ux-consistency >I'm not necessarily asking for the _default_ behavior to change >(though I think when the "all controls" option is selected that would make >sense), but I'd like to be able to configure the behavior. I'm fine with an about:config pref for ux-control bonus points, but overall we need to maintain OS X style tab behavior as the default.
My point is that in the web context that behavior is broken to the point of unusability (as in, I've had to stop using current trunk builds due to this change). Web pages are not the same thing as UI dialogs, and I'll note you're not advocating we skip links in the tab order like Safari does. Why not?
And more importantly, why can I tab _to_ a checkbox or button, but not tab _from_ a checkbox that I clicked on, while text controls act totally differently? The inconsistency is completely wacky, and seems like just an incomplete implementation of the "All controls" tabbing behavior (that is, a bug), not a conscious UI decision.
>why can I tab _to_ a checkbox or button, but not tab >_from_ a checkbox that I clicked on, while text controls act totally >differently? On OS X some controls don't receive focus on mouse interactions (like buttons and check boxes). The behavior is somewhat expected in that when you click on a button or check box on OS X it doesn't pick up the visual style of being focused, but is simply interacted with. I can't really defend this design, other than it seems that OS X users seem to intuitively expect otherwise quirky focus behaviors. cc'ing Limi for his views on OS X focus.
Specifically, clicking on a textbox or list focuses it. Clicking on any other UI element does not focus it. The 'All Controls' preference has no effect on this behaviour (it only affects keyboard interaction). But I'm ok if we had a preference to control this behaviour. Pressing tab will switch to the next element in focus order, or from the beginning if nothing is focused. The 'All Controls' preference determines which elements are in the tab sequence.
> On OS X some controls don't receive focus on mouse interactions (like buttons > and check boxes). They also do not receive focus on tabbing, by default. Unless the OS preference to change that is set. So the inconsistency seems to largely arise as the result of a buggy implementation of that preference, as I said in comment 5.... or Neil in comment 7. In any case, our current behavior is neither compatible with Firefox 3.6, Safari, the OS UI, or anything else... I think we definitely need user control to get at least the Firefox 3.6 behavior; it's up to you whether we need the Safari behavior (which I think happens to be insane).
(In reply to comment #8) > > On OS X some controls don't receive focus on mouse interactions (like buttons > > and check boxes). > > They also do not receive focus on tabbing, by default. Unless the OS > preference to change that is set. So the inconsistency seems to largely arise > as the result of a buggy implementation of that preference, as I said in > comment 5.... or Neil in comment 7. I'm unclear what you think is a bug. The only deviation from Mac UI is that all html form controls are tabbable when the system setting is 'Text boxes and lists only'. This was intentionally made in bug 437296. Or is this what you are referring to?
> I'm unclear what you think is a bug. The fact that the "All controls" system setting doesn't change the mouse behavior. Said bug is a bug in the Mac UI, in my opinion. But honestly, I don't understand why we think it's ok to allow tabbing to other controls no matter what the OS setting (which I happen to think is the right decision, by the way!) but think we need to follow the "text boxes and lists only" click behavior even if the OS setting is "all controls". We seem to be catering to keyboard-only or mouse-only users at the expense of those of us who happen to use both...
>Said bug is a bug in the Mac UI, in my opinion. Yeah, I agree, the only question is if it is a bug that users have habituated to such that we would violate their expectations if we used the more logical focus behavior. Neil: if we wanted to try a beta with the behavior that bz is suggesting to see what happens, how easy is it to make this change?
I agree the user habituation issue is a problem. On the other hand, we also have habituation of our existing users to our existing behavior.... I'm definitely not sure where that tradeoff should lie, but I still think it should be pref-controlled, not hard-ifdef controlled, so that our existing users can at least keep existing behavior if they want to.
>On the other hand, we also >have habituation of our existing users to our existing behavior. Wasn't the existing behavior what we currently do, plus the complete inability to tab to certain controls (like combo boxes). It's entirely possible that I am very confused.
No, the existing behavior before bug 564277 was that clicking on a form control would focus it.
Ok, in that case I think we'll probably do more harm than good by not allowing certain items to get focus, since users will have built up an expectation of how Firefox behaves. We should however continue to have the same visual styling for mouse interactions, and only show focus rings on certain controls after the user hits the tab key to focus them with the keyboard (for instance when we drew the focus ring on buttons and checkboxes on OS X after a mouse interaction, that looked broken since those controls are normally never given focus rings).
Sounds like there's agreement that we need to sort this out for Firefox 4. Marking blocking betaN+, and this sounds like something for Neil, so reassigning to him. Neil, feel free to pass this along if someone else is better suited for this bug.
Assignee: nobody → enndeakin
blocking2.0: ? → betaN+
Created attachment 462832 [details] [diff] [review] fix using a preference This patch adds a preference 'accessibility.mouse_focuses_formcontrol' to allow form controls to be focusable with the mouse.
Attachment #462832 - Flags: review?(Olli.Pettay)
So the patch keeps the current behavior (unless user changes the pref using about:config or something)? Based on comment 15, is that what we really want?
>Based on comment 15, is that what we really want? This can be a bit confusing, but here is what I think we want: -We continues to only display the focused visual style on certain elements during mouse interactions (text field, text area, etc.) -We in the background focus any element that the user interacts with, so that if the user hits the tab key they will move forward from the last element they interacted with -We draw the focus style on every focused element during keyboard interactions
The issue here is that there's an assumption that the normal Mac UI focus behaviour is somehow incorrect and that the Windows and Linux focus behaviour is correct. I do not agree with that assessment. I believe that both models are valid and that neither is more correct or less correct than the other. After spending quite a bit of time trying to implement the actual OS behaviour I don't intend to spend time implementing an alternative. If a clear description of changes is provided, and importantly, if it is clear that the author of that description understands the changes as well, I may be willing to do so. I believe this bug to be invalid, but have provided a patch that enables the behaviour with a preference. The only actual more obvious bug from OS behaviour is that clicking another element should not remove the focus from a focused textbox.
>After spending quite a bit of time trying to implement the actual OS behaviour >I don't intend to spend time implementing an alternative. Ok, it was my impression that the previous work primarily had to do with tracking keyboard versus mouse interactions, and that this was just flipping a pref. >The issue here is that there's an assumption that the normal Mac UI focus >behaviour is somehow incorrect and that the Windows and Linux focus behaviour >is correct. I think that position is also being compounded by the fact that this is the first time we've introduced normal Mac UI focus behavior to users on OS X. I previously assumed that these users would be very happy to have Firefox finally match native platform behavior.
The issue, really, is that while the Mac UI behavior is sort of OK for things like UI dialogs (typically few controls, etc) it's really painful for the sort of forms you get on the web (the Bugzilla UI in particular, but many others too)...
Neil, thank you for adding the preference. I really appreciate it!
Comment on attachment 462832 [details] [diff] [review] fix using a preference Well, ok, this is what is at least need to do.
Attachment #462832 - Flags: review?(Olli.Pettay) → review+
(In reply to comment #2) > > As an aside Safari implements the same behaviour Firefox currently does. > > Yes. It also doesn't focus links while tabbing (in spite of the OS preference > being set in comment 0) FWIW, just for completeness, links aren't "controls" (the OS pref is about controls), and Safari does have a pref to add links to tab chain, but it is off by default. That having been said, I do think it's useful to make a distinction between chrome and content and to consider content to be a special case, as historically in Mac browsers content been out of sync with chrome since at least early Netscapes. It's for reasons like this that I supported bug 437296 and why Camino has always tabbed to all controls in content regardless of the Full Keyboard Access pref ("people expect this to work", to quote pink). It's useful in some of these out-of-sync places to have both the OS consistency option and the historical behavior option, and this seems like one of those places.
We'll use this bug for the adding the preference which is done.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Summary: Clicking file input or checkbox no longer affects tabbing behavior on Mac → Clicking file input or checkbox no longer affects tabbing behavior on Mac, add preference to enable click to focus
Thanks! Works like a charm.
Status: RESOLVED → VERIFIED
As this might be of interest to people following this bug, I created Bug 623291 which is related to the issue being discussed here. The problem there is not that when you click on a button, that button doesn't get the focus. (Let's accept that OS X "weird" UX behavior.) The problem is that if before clicking on the button, an input had the focus, when the button is clicked, the input doesn't get blur/change events and doesn't loose the focus, as it does in Safari 5.
You need to log in before you can comment on or make changes to this bug.