Bug 24516

Created attachment 28480 [details] Example of form with onchange event that fires in Fx but not in WebKit

This event does bubble in WebKit, but you need to add a handler with addEventHandler, not with onchange attribute. Note that per DOM 2 Events spec, "This event is valid for INPUT, SELECT, and TEXTAREA. element.<...> Bubbles: Yes" My interpretation of this is that WebKit behavior fully matches the standard. Per <http://www.johnvey.com/blog/2007/07/ie-does-not-bubble-form-select-element-onchange-events>, this event doesn't bubble in Internet Explorer, so not matching Firefox is unlikely to be a compatibility issue for WebKit. Please feel free to re-open the bug if you disagree.

Shouldn't the onchange attribute also work?

HTML5 says that all HTML elements should support an onchange attribute, but it also says that the change event that is dispatched when an input element changes shouldn't bubble. So, the onchange attribute (content or DOM) is apparently only good for handling custom events named "change", not the ones dispatched automatically. This doesn't make a lot of sense to me.

I was asked for an opinion. If the change event bubbles in other browsers (and it does look like it does) HTML5 should probably be updated to reflect that (and WebKit would need to be fixed, too).

(In reply to comment #4) > HTML5 says that all HTML elements should support an onchange attribute, but it > also says that the change event that is dispatched when an input element > changes shouldn't bubble. So, the onchange attribute (content or DOM) is > apparently only good for handling custom events named "change", not the ones > dispatched automatically. This doesn't make a lot of sense to me. Why does it bubbling have any effect on whether the event handler is useful...?

(In reply to comment #6) > Why does it bubbling have any effect on whether the event handler is useful...? I wasn't clear enough - what I wanted to say was that an onchange attribute on elements that don't generate the event is not useful if the event doesn't bubble. Obviously, it's just fine when set on the input itself.

Oh, right. Yeah, many of the event handlers in HTML only make sense on some elements. HTML5 simplifies things a bit by just making all the elements have all the event handlers, so that it can just be implemented as a common infrastructure.

Hello http://dev.w3.org/html5/spec/the-select-element.html is quite clear here, the event does bubble "... and then queue a task to fire a simple event that bubbles named change at the select element ..."

*** Bug 81318 has been marked as a duplicate of this bug. ***

Per comments in test attached to bug 81318, this works in IE, despite what was mentioned in comment 2. Did IE behavior change? Or is the test subtly different?

(In reply to comment #11) > Per comments in test attached to bug 81318, this works in IE, despite what was mentioned in comment 2. Did IE behavior change? Or is the test subtly different? That comment is quite old, change does bubble in IE9 and IE10 according to specification.

(In reply to comment #12) > (In reply to comment #11) > > Per comments in test attached to bug 81318, this works in IE, despite what was mentioned in comment 2. Did IE behavior change? Or is the test subtly different? > > That comment is quite old, change does bubble in IE9 and IE10 according to specification. and BTW. both Firefox 14 Nightly and Opera 12 Next also bubble so at this point WebKit is the only major engine not to bubble...

Created attachment 132352 [details] testcase

Chrome 17: only change bubles Safari 5.1: only change bubles Opera 11.6: onchange & change buble Firefox 11: onchange & change buble IE 9: onchange & change buble Konqueror 4.7: onchange & change buble Webkit bubles only change from addEventListener Webkit does not buble onchange - please fix it.

This script from the spec doesn't work in webkit. http://www.whatwg.org/specs/web-apps/current-work/#the-script-element <script> function calculate(form) { var price = 52000; if (form.elements.brakes.checked) price += 1000; if (form.elements.radio.checked) price += 2500; if (form.elements.turbo.checked) price += 5000; if (form.elements.sticker.checked) price += 250; form.elements.result.value = price; } </script> <form name="pricecalc" onsubmit="return false" onchange="calculate(this)"> <fieldset> <legend>Work out the price of your car</legend> <p>Base cost: £52000.</p> <p>Select additional options:</p> <ul> <li><label><input type=checkbox name=brakes> Ceramic brakes (£1000)</label></li> <li><label><input type=checkbox name=radio> Satellite radio (£2500)</label></li> <li><label><input type=checkbox name=turbo> Turbo charger (£5000)</label></li> <li><label><input type=checkbox name=sticker> "XZ" sticker (£250)</label></li> </ul> <p>Total: £<output name=result></output></p> </fieldset> <script> calculate(document.forms.pricecalc); </script> </form>

Created attachment 140870 [details] Patch

Attachment 140870 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/fast..." exit_code: 1 Source/WebCore/html/HTMLSelectElement.cpp:300: One line control clauses should not use braces. [whitespace/braces] [4] Total errors found: 1 in 10 files If any of these errors are false positives, please file a bug against check-webkit-style.

Comment on attachment 140870 [details] Patch Attachment 140870 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12650543 New failing tests: transitions/transition-end-event-attributes.html

Created attachment 140876 [details] Archive of layout-test-results from ec2-cr-linux-04 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-04 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

Comment on attachment 140870 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=140870&action=review > Source/WebCore/ChangeLog:3 > + All the event handler attributes should be definable on HTMLElement. Why is this different from the actual bug title? > Source/WebCore/ChangeLog:7 > + Please explain what caused the bug and how you're fixing it. r- due to the lack of a change log entry. > Source/WebCore/html/HTMLElement.cpp:250 > - } > -// standard events > - else if (attr->name() == onclickAttr) { > + // HTML5 event attributes > + // Not yet implemented: oncancel, onclose, oncuechange, onshow > + } else if (attr->name() == onabortAttr) { > + setAttributeEventListener(eventNames().abortEvent, createAttributeEventListener(this, attr)); > + } else if (attr->name() == onblurAttr) { > + setAttributeEventListener(eventNames().blurEvent, createAttributeEventListener(this, attr)); > + } else if (attr->name() == oncanplayAttr) { > + setAttributeEventListener(eventNames().canplayEvent, createAttributeEventListener(this, attr)); > + } else if (attr->name() == oncanplaythroughAttr) { > + setAttributeEventListener(eventNames().canplaythroughEvent, createAttributeEventListener(this, attr)); > + } else if (attr->name() == onchangeAttr) { > + setAttributeEventListener(eventNames().changeEvent, createAttributeEventListener(this, attr)); > + } else if (attr->name() == onclickAttr) { Why are you adding all these code? Are you sorting them? If so, that should be done in a separate patch. If not, then each one of these changes should be tested.

any news here?

I am unable to reproduce this bug in Safari 15.5 and Safari behaves similar to Firefox and Chrome here. On testing Safari 15.5 using test case attached (named - testcase), the following dialogs popped-up: oninput, input , onchange, change Same was the case when I used Chrome Canary 104 and Firefox Nightly 102. I think this should be marked as "Resolved Fixed" or "Resolved Invalid". If there is any error in testing or expected results. Please test it and respond accordingly here. Thanks!

Thank you for checking!