WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 26856
92029
Radio buttons don't receive focus event
https://bugs.webkit.org/show_bug.cgi?id=92029
Summary
Radio buttons don't receive focus event
Nicholas C. Zakas
Reported
2012-07-23 14:23:58 PDT
When a radio button is clicked on or tabbed to, Internet Explorer and Firefox fire the focus event. In WebKit, this event is not fired. You can see this behavior very easily via: <input type="radio" onfocus="alert('focus')"> This behavior is exhibited in the latest versions of both Safari and Chrome.
Attachments
Add attachment
proposed patch, testcase, etc.
Kyle Simpson
Comment 1
2012-07-23 14:47:07 PDT
Just a few notes from a spec perspective, not to disclaim the validity of this bug: Note that current spec can be a bit confusing on whether `focus` should be fired on the `input[type=radio]` element.
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#common-event-behaviors
Defines only 2 "common events" across the form types, and `focus` is not one of them.
http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#radio-button-state-%28type=radio%29
Defines some exception events that do NOT apply to the `input[type=radio]` button, but `focus` is not listed as being excluded.
http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#focus
And subsequent sections only talk about the `Focus` APIs on elements, and seem mum on the `focus` event itself. But:
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#handler-onfocus
Lists `focus` as one of the events that should be on all HTML elements, other than `body`. So, it would appear (unless I missed something else) that finding no exclusion in the other sections, `focus` should indeed be fired.
Nicholas C. Zakas
Comment 2
2012-07-23 14:53:40 PDT
Potentially platform-specific. Updating to reflect that I'm on Windows 7.
Nicholas C. Zakas
Comment 3
2012-07-23 15:05:13 PDT
More info: When I try to click on the radio button, I don't get the alert. When I tab to the radio button initially, I get the alert but I don't get it any time thereafter.
Kyle Simpson
Comment 4
2012-07-23 15:07:24 PDT
Nicholas: can you post a test page so others can check on other platforms, etc?
Jonathan Sampson
Comment 5
2012-07-23 15:09:20 PDT
(In reply to
comment #4
)
> Nicholas: can you post a test page so others can check on other platforms, etc?
Test available at
http://jsfiddle.net/DM3h5/1/
I on Windows 7 and 8, with Chrome 20, I get consistent results with tabbing. The focus event is raised, and the alert is visible. This is not the case with clicking on the input element. I never get the focus event that way.
Kyle Simpson
Comment 6
2012-07-23 15:19:05 PDT
I get the same behavior that Jonathan describes, on both Chrome 22 and Firefox 15 on Mac. However, Saf 5.1 never fires the event at all, although curiously, it doesn't appear that the radio button is even "focusable" (let alone not firing the event) via keyboard nav in Saf 5.1 on this Mac. I even tried modifying to set a `tabindex` and other such things, couldn't get Saf to give focus at all to the radio button. So perhaps in webkit, that's the deeper issue, that the element is simply not focusable. Although, I would concur that it's strange that on the other browsers, keyboard focusing fires the event but mouse focusing does not. While that's bizarre, at least it seems a bit more consistent (this Saf unfocusable issue not-withstanding).
Alexey Proskuryakov
Comment 7
2012-07-24 09:46:39 PDT
I think that it's closely related like
bug 22261
and its dupes. There is no focus given to the radio button when clicking, so there is no focus event dispatched.
> I even tried modifying to set a `tabindex` and other such things, couldn't get Saf to give focus at all to the radio button.
I can focus it via Option-clicking on Mac, and we probably dispatch the focus event in this case.
Kyle Simpson
Comment 8
2012-07-24 10:27:06 PDT
(in reply to
Comment #7
) Option clicking for me on Mac (in Saf) doesn't do anything different than normal clicking. It selects the radio button, but the radio-button doesn't retain the focus (even if you take out the `this.blur()` in the test URL provided). My primary evidence for suggesting the radio button never gets/keeps the focus is that after clicking (or option-clicking) the radio button (when it gets set to `checked`), you can't tab to other elements on the page, either before or after it, in a logical order. For instance, this variation on the previous test:
http://jsfiddle.net/DM3h5/4/
If the radio button indeed can get the focus, then shift+tab should go to the text box before it, and tab should go to the text box after it. However, neither of those behaviors happen as expected in Saf (but they do in Chrome and Firefox). Moreover, the focus event is indeed NOT fired, even if you option-click, even though the radio button receives the click enough to set the `checked` state.
Alexey Proskuryakov
Comment 9
2012-07-24 10:48:38 PDT
Apologies, I mistyped. It's not option-clicking, but option-tabbing.
Kyle Simpson
Comment 10
2012-07-24 10:55:59 PDT
(in reply to
Comment #9
) I can confirm as well that option-tab is able to get the radio button to get focus (and fire the event) in Mac Saf 5.1. Regular tab does not, nor does mouse clicking. Those seem like the bugs. Moreover, it's clear that mouse-click also doesn't give focus in the other major browsers either, so this is a more widespread problem than just Safari Webkit.
Kyle Simpson
Comment 11
2012-07-24 11:00:16 PDT
FYI: here's a more well-behaving test for testing the option-click...
http://jsfiddle.net/DM3h5/6/
(note: must open web inspector to see console.log's, not using alert)
Sam Sneddon [:gsnedders]
Comment 12
2021-05-17 02:58:54 PDT
*** This bug has been marked as a duplicate of
bug 26856
***
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug