577316 - Clicking file input or checkbox no longer affects tabbing behavior on Mac, add preference to enable click to focus

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Boris Zbarsky [:bzbarsky]]

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.

Comment 1

[Neil Deakin]

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.

Comment 2

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

>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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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?

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[Alex Faaborg [:faaborg] (Firefox UX)]

>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.

Comment 7

[Neil Deakin]

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.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> 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).

Comment 9

[Neil Deakin]

(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?

Comment 10

[Boris Zbarsky [:bzbarsky]]

> 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...

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

>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?

Comment 12

[Boris Zbarsky [:bzbarsky]]

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.

Comment 13

[Alex Faaborg [:faaborg] (Firefox UX)]

>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.

Comment 14

[Boris Zbarsky [:bzbarsky]]

No, the existing behavior before bug 564277 was that clicking on a form control would focus it.

Comment 15

[Alex Faaborg [:faaborg] (Firefox UX)]

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).

Comment 16

[Johnny Stenback (:jst)]

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.

Comment 17

[Neil Deakin]

Attachment: fix using a preference

This patch adds a preference 'accessibility.mouse_focuses_formcontrol' to allow form controls to be focusable with the mouse.

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

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?

Comment 19

[Alex Faaborg [:faaborg] (Firefox UX)]

>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

Comment 20

[Neil Deakin]

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.

Comment 21

[Alex Faaborg [:faaborg] (Firefox UX)]

>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.

Comment 22

[Boris Zbarsky [:bzbarsky]]

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)...

Comment 23

[Boris Zbarsky [:bzbarsky]]

Neil, thank you for adding the preference.  I really appreciate it!

Comment 24

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 462832 [details] [diff] [review]
fix using a preference

Well, ok, this is what is at least need to do.

Comment 25

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(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.

Comment 26

[Neil Deakin]

http://hg.mozilla.org/mozilla-central/rev/10e893c36559

Comment 27

[Neil Deakin]

We'll use this bug for the adding the preference which is done.

Comment 28

[Boris Zbarsky [:bzbarsky]]

Thanks!  Works like a charm.

Comment 30

[Alessandro Vernet]

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.