606011 - onfocus event not fired on click for elements made specially focusable via tabindex

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Ryan Grove]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101020 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101020 Firefox/4.0b8pre

Firefox 4 doesn't fire an onfocus event when a specially focusable element (for example, a <div> with tabindex="1") is clicked. This appears to be a regression since FF3, which worked fine.

Reproducible: Always

Steps to Reproduce:
1. Create an HTML document containing the following markup:

<div tabindex="1" onfocus="this.innerHTML='focused'">click me</div>

2. Load the document in FF4 and click the div.
Actual Results:  
Nothing happens.

Expected Results:  
The div's onfocus subscriber should be called, and its innerHTML should be set to 'focused'.

The focus event still fires on tab-initiated focus; only clicks seem to be ignored.

Comment 1

[Mike Shaver (:shaver emeritus)]

Ryan: do you have any idea of when it first broke?  Attaching a test case would help a bit, if you could.

Comment 2

[Ryan Grove]

Attachment: simple test case

Comment 3

[Ryan Grove]

Sorry, I'm not sure when exactly it broke. I first noticed it in 4.0b6.

There's a test case at http://fiddle.jshell.net/rgrove/2RkmE/14/show/light/ (I've attached one as well in case that URL disappears).

Comment 4

[Mike Shaver (:shaver emeritus)]

Looks Mac-only, since I don't see it on today's nightly.  (You're using a rather old nightly from the look of it, though -- could you update to today's and confirm?)

Thanks for the report, and the test case.

Comment 5

[Ryan Grove]

Still reproducible in Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101103 Firefox/4.0b8pre, so if you're not seeing it in the Windows nightly, definitely sounds like it's Mac-only.

Comment 6

[Boris Zbarsky [:bzbarsky]]

This was purposeful, as far as I can tell.  Things that can be tabbed to focus don't necessarily take focus on click on Mac in general (e.g. in native UI widgets).  See bug 564277.

Comment 7

[Boris Zbarsky [:bzbarsky]]

In particular, it's not just random @tabindex divs, but also buttons, checkboxes, radios, etc that can't take focus on mac.  At least modulo the preference added in bug 577316.

Comment 8

[Ryan Grove]

Unfortunately, even if a preference is available, having focus behave differently by default on Mac OS X (and also differently from all other Mac browsers) results in a compatibility and accessibility problem.

I think the wording of the HTML5 "Focus management" section is important here: "An element is focusable if the user agent's default behavior allows it to be focusable or if the element is specially focusable..." (http://www.w3.org/TR/html5/editing.html#focus-management)

In this case, I have explicitly designated an element as specially focusable, which (as I understand it) means that the default behavior should be overridden. This is how it worked in Firefox 3 on Mac OS X, in all versions of Firefox on Windows, and in all other browsers on Mac OS X and Windows.

This change is unfortunate for JavaScript developers who need to make an element specially focusable in order to make a widget accessible, or in order to faithfully emulate the behavior of an OS control. If specially focusable elements don't actually receive focus on mouse activation, widgets that need this functionality will have to branch specifically for Mac Firefox 4.

Comment 9

[Benjamin Smedberg]

Good point, I think we at least need to make an explicit decision here. Assigning to smaug for now.

Comment 10

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

I need to look at this next week, since I don't have macbook with me atm.

Enn, if you get to this, feel free to take it.
I would guess we should make elements focusable when they have tabIndex and aren't
disabled.

Comment 11

[Neil Deakin]

Note that comment 8 is making a false assumption. On Mac, the mouse does not focus elements, even if they are focusable. Using tabindex on an element makes the element focusable, and we currently follow the spec correctly.

That said, Safari does allow click-to-focus on <div> elements as well as other non-form controls when a tabindex is used. Safari does not allow click-to-focus on form controls (except textboxes and lists).

Comment 12

[Ryan Grove]

(In reply to comment #11)
> Note that comment 8 is making a false assumption. On Mac, the mouse does not
> focus elements, even if they are focusable. Using tabindex on an element makes
> the element focusable, and we currently follow the spec correctly.

Admittedly, I'm a web developer and not a native Mac app developer, but the distinction between "focusable" and "focusable by mouse click" is strange to me. Especially since, in this case, I explicitly want to make something focusable that otherwise would not be, and I can't, even though the HTML5 spec seems to say I should be able to.

If I wanted to distinguish between input methods, I would use specific keyboard or mouse events. I'm using the focus event because I don't want to distinguish between input methods.

From my perspective, I want my web UI to behave in a certain way. I don't care whether the user is on a Mac, a PC, a cell phone, or a digital watch, and I don't care whether they're using a mouse, a keyboard, a touchscreen, or a voice-controlled UI. The idea that "focusable" might mean different things in each of those places is disconcerting. I see focus as an indication of user intent to interact with a focusable element. By explicitly making an element focusable, I'm saying "you may interact with this". I'm not saying "you may interact with this, but if you're on a Mac, you may only interact with this via the keyboard".

Is there a standard definition somewhere of what "focusable" actually means that would help to clarify this? If not, shouldn't there be?

Comment 13

[Neil Deakin]

(In reply to comment #12)
> From my perspective, I want my web UI to behave in a certain way.

Users, especially on Mac, want their UI to behave like the native UI.


> Is there a standard definition somewhere of what "focusable" actually means
> that would help to clarify this? If not, shouldn't there be?

Focusable means 'I intend to interact with the element with the keyboard.' This definition is used on all platforms. Being focusable has no effect on whether you can interact with it using the mouse on any platform.

On the Mac only elements in which you must interact with them using the keyboard (such as textboxes) are focusable by clicking on them. Other elements such as buttons and checkboxes are almost never interacted with using the keyboard by a mouse user, and are thus not focused when interacting with them using the mouse.

Comment 14

[Ryan Grove]

(In reply to comment #13)
> Users, especially on Mac, want their UI to behave like the native UI.

Ironically, that's exactly what I'm trying to achieve here. I'm emulating a Cocoa NSTokenField by having a specially focusable div transfer focus to a child text input element when the div is clicked. The div behaves like a text input element, but actually contains both "tokens" (span elements) and other text input elements as children. I can't rely on the child text input element alone for the focus event since it doesn't cover the full width of the control. There are other ways to implement this, but a single listener on the focus event seems to be the most elegant.

> Focusable means 'I intend to interact with the element with the keyboard.' This
> definition is used on all platforms. Being focusable has no effect on whether
> you can interact with it using the mouse on any platform.

I'll concede the point, since you seem to know more than I do.

Nevertheless, even if we agree that "focusable" refers to keyboard interaction, clicks on some elements do cause focus. In other browsers on Mac OS X, making a div specially focusable by giving it a tabindex causes the focus event to fire when that div is clicked. Firefox 4 is the only browser I've tested where this is not the case, so I still think it makes sense to change this.

Comment 15

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

Attachment: patch

Comment 16

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

http://hg.mozilla.org/mozilla-central/rev/f30f14f26ab7