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
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.
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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).
(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?
(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.
(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)
Attachment #500377 - Flags: review?(enndeakin) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.