Bug 24516 - onchange event on form doesn't fire (or bubble up)
Summary: onchange event on form doesn't fire (or bubble up)
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 525.x (Safari 3.2)
Hardware: Mac OS X 10.5
: P2 Normal
Assignee: Keishi Hattori
URL:
Keywords:
: 81318 (view as bug list)
Depends on: 86363
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-11 08:14 PDT by Teun
Modified: 2016-05-30 11:35 PDT (History)
10 users (show)

See Also:


Attachments
Example of form with onchange event that fires in Fx but not in WebKit (419 bytes, text/html)
2009-03-11 08:15 PDT, Teun
no flags Details
testcase (959 bytes, text/html)
2012-03-16 12:37 PDT, bugzilla33
no flags Details
Patch (29.81 KB, patch)
2012-05-09 00:14 PDT, Keishi Hattori
rniwa: review-
webkit.review.bot: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from ec2-cr-linux-04 (6.18 MB, application/zip)
2012-05-09 00:48 PDT, WebKit Review Bot
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Teun 2009-03-11 08:14:56 PDT
If you use <form onchange="alert(1);">...</form>, the alert is never shown if form elements inside the form are changed.
Comment 1 Teun 2009-03-11 08:15:46 PDT
Created attachment 28480 [details]
Example of form with onchange event that fires in Fx but not in WebKit
Comment 2 Alexey Proskuryakov 2009-03-12 01:38:29 PDT
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.
Comment 3 Teun 2009-03-12 06:39:55 PDT
Shouldn't the onchange attribute also work?
Comment 4 Alexey Proskuryakov 2009-03-12 06:58:14 PDT
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.
Comment 5 Anne van Kesteren 2009-03-12 10:50:00 PDT
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).
Comment 6 Ian 'Hixie' Hickson 2009-03-12 20:16:04 PDT
(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...?
Comment 7 Alexey Proskuryakov 2009-03-13 00:58:24 PDT
(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.
Comment 8 Ian 'Hixie' Hickson 2009-03-13 22:23:54 PDT
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.
Comment 9 Bronislav Klucka 2012-03-14 16:01:35 PDT
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 ..."
Comment 10 Alexey Proskuryakov 2012-03-16 11:30:08 PDT
*** Bug 81318 has been marked as a duplicate of this bug. ***
Comment 11 Alexey Proskuryakov 2012-03-16 11:33:31 PDT
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?
Comment 12 Bronislav Klucka 2012-03-16 12:14:27 PDT
(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.
Comment 13 Bronislav Klucka 2012-03-16 12:22:38 PDT
(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...
Comment 14 bugzilla33 2012-03-16 12:37:45 PDT
Created attachment 132352 [details]
testcase
Comment 15 bugzilla33 2012-03-16 12:41:07 PDT
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.
Comment 16 Keishi Hattori 2012-05-08 23:56:49 PDT
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>
Comment 17 Keishi Hattori 2012-05-09 00:14:34 PDT
Created attachment 140870 [details]
Patch
Comment 18 WebKit Review Bot 2012-05-09 00:17:42 PDT
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 19 WebKit Review Bot 2012-05-09 00:47:57 PDT
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
Comment 20 WebKit Review Bot 2012-05-09 00:48:16 PDT
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 21 Ryosuke Niwa 2012-05-10 00:52:47 PDT
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.
Comment 22 Bronislav Klucka 2012-07-13 09:02:54 PDT
any news here?