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

RESOLVED FIXED

Status

()

Core
DOM
RESOLVED FIXED
7 years ago
2 years ago

People

(Reporter: Ryan Grove, Assigned: smaug)

Tracking

({regression})

Trunk
x86
Mac OS X
regression
Points:
---

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: softblocker, URL)

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
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.
Ryan: do you have any idea of when it first broke?  Attaching a test case would help a bit, if you could.
blocking2.0: --- → ?
Keywords: regression, regressionwindow-wanted
(Reporter)

Comment 2

7 years ago
Created attachment 488121 [details]
simple test case
(Reporter)

Comment 3

7 years ago
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).
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.
(Reporter)

Comment 5

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

Updated

7 years ago
Component: General → General
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
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.
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.
(Reporter)

Comment 8

7 years ago
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.
Blocks: 564277
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 9

7 years ago
Good point, I think we at least need to make an explicit decision here. Assigning to smaug for now.
blocking2.0: ? → betaN+
Component: General → DOM
QA Contact: general → general
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

7 years ago
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).
(Reporter)

Comment 12

7 years ago
(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

7 years ago
(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.
(Reporter)

Comment 14

7 years ago
(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.
Assignee: nobody → Olli.Pettay
Created attachment 500377 [details] [diff] [review]
patch
Attachment #500377 - Flags: review?(enndeakin)
Status: NEW → ASSIGNED

Updated

7 years ago
Attachment #500377 - Flags: review?(enndeakin) → review+

Updated

7 years ago
Whiteboard: softblocker
http://hg.mozilla.org/mozilla-central/rev/f30f14f26ab7
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Keywords: regressionwindow-wanted
You need to log in before you can comment on or make changes to this bug.