- From: <bugzilla@jessica.w3.org>
- Date: Mon, 07 Mar 2011 19:02:37 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12230 --- Comment #10 from Jacob Rossi [MSFT] <jrossi@microsoft.com> 2011-03-07 19:02:36 UTC --- In general, yes, code that dispatches an event should also be the performer of the default actions. This is true for submit: * If the browser is preparing to perform form submission, it dispatches a submit event with the default action of submitting the form. If preventDefault() is not called, then it completes the form submission. * If script synthesizes a submit event dispatch, then it's up to the script to perform the default action. This can be acheived as you described: if(myform.dispatchEvent(ev)) myform.submit(); //HTML5 form submit alg says this doesn't cause another submit event This is how D3E defines it and how Webkit/IE9 behave. A recurssive submit event doesn't occur b/c of the scripted-submit flag. So I don't see the issue with having the submit event as a step in the form submission algorithm since it accounts for scripted submits. This is true for most events. However, click is an exception. Ideally, it wouldn't be, but changing it may have a compat impact. Hence why I say it's for historical reasons. The only confusing point I see here is that D3E says "untrusted events must behave as if the Event.preventDefault() method had been called on that event." This should not be interpreted that the return value of dispatchEvent() should always be false. Rather, it just means the UA doesn't invoke its default actions--that is left for the scripted dispatcher to implement for untrusted events. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 7 March 2011 19:02:39 UTC