Summary: | radiogroup: onchange not detected when triggered by keyboard | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | arno. <a.renevier> | ||||||||||
Component: | Forms | Assignee: | Erik Arvidsson <arv> | ||||||||||
Status: | RESOLVED FIXED | ||||||||||||
Severity: | Normal | CC: | abarth, amb26webkit, ap, arv, commit-queue, eric, webkit.review.bot | ||||||||||
Priority: | P2 | ||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||
Hardware: | All | ||||||||||||
OS: | All | ||||||||||||
Attachments: |
|
*** Bug 33328 has been marked as a duplicate of this bug. *** Confirmed with a local ToT build. Created attachment 92648 [details]
Patch
Comment on attachment 92648 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=92648&action=review This is an awesome fix! I think that tests need some improvement though. > LayoutTests/fast/forms/radio-group-keyboard-change-event.html:8 > +if (window.layoutTestController) > + layoutTestController.dumpAsText(); Bad indentation. > LayoutTests/fast/forms/radio-group-keyboard-change-event.html:10 > +var expexted = 'bc'; Typo: expected. > LayoutTests/fast/forms/radio-group-keyboard-change-event.html:20 > +if (window.eventSender) { The test should have an explanation of what to do to verify its behavior manually, or at the very least, an explanation that it doesn't work in a browser. We strongly prefer tests that can be run in a browser, so that anyone could easily compare the behavior to other browsers. > LayoutTests/fast/forms/radio-group-keyboard-change-event.html:29 > +else > + result = 'FAIL: Expected "' + expexted + '" but got "' + actual + '"'; Bad indentation. > Source/WebCore/ChangeLog:13 > + (WebCore::RadioInputType::handleKeydownEvent): Ensure that we do not check the radio input before we simulate the click > + event. The simulated click event will check it for us but more importantly it will fire the "change" event as > + expected. I think that a change like that should have a test verifying that event.preventDefault() in click event handler didn't prevent setting the value before the fix, but does now. The test should pass in Firefox and IE. Thanks for the feedback. Those are all very valuable comments. Created attachment 92830 [details]
Patch
(In reply to comment #4) > > Source/WebCore/ChangeLog:13 > > + (WebCore::RadioInputType::handleKeydownEvent): Ensure that we do not check the radio input before we simulate the click > > + event. The simulated click event will check it for us but more importantly it will fire the "change" event as > > + expected. > > I think that a change like that should have a test verifying that event.preventDefault() in click event handler didn't prevent setting the value before the fix, but does now. The test should pass in Firefox and IE. Now we match other browsers and that is that calling preventDefault in the click event DOES prevent the checked radio button in the group from being changed. There are still browser differences when a change event is triggered. I'll start a discusion on whatwg to try to resolve this. We currently match IE here and that is that we fire change and then revert the value back in case of a call to preventDefault. Created attachment 92833 [details]
Fix typo
Comment on attachment 92833 [details] Fix typo Clearing flags on attachment: 92833 Committed r86088: <http://trac.webkit.org/changeset/86088> All reviewed patches have been landed. Closing bug. http://trac.webkit.org/changeset/86088 might have broken SnowLeopard Intel Release (WebKit2 Tests) The following tests are not passing: fast/forms/radio-group-keyboard-change-event.html fast/frames/flattening/frameset-flattening-subframesets.html |
Created attachment 44061 [details] testcase Hi, I've a radiogroup with onchange handlers. Those handlers are triggered correctly when radiogroup selection is changed with mouse. But they are not when selection is changed with keyboard. same behaviour with webkit-gtk and google chrome, so I assume it's a webkit bug.