[Bug 12230] From this algorithm it does not seem to follow that dispatching a synthetic non-canceled submit event at a form causes it to be submitted. Yet that is what browsers implement. So that forms have a default handler for submit events should probably be split

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12230

--- Comment #6 from Boris Zbarsky <bzbarsky@mit.edu> 2011-03-05 15:20:53 UTC ---
In Gecko, I think the submission is the default action of the submit event,
because that makes it easy to handle onsubmit: you fire the "submit" event, the
handlers run, then if the event's default is not prevented you submit the form.
 You use your normal event handling codepaths, with no special magic needed.

This code predates the existence of trusted event flags in Gecko, and since we
added them largely for security reasons there was no reason to check them here:
the page can already submit the form programmatically whenever it wants by
calling submit().  So preventing it from doing the same by dispatching a
"submit" event really gains you nothing security-wise.

I doubt that web sites depend on this stuff, except insofar as the actual form
submission should _look_ like the default action of the "submit" event in terms
of how it's affected by preventDefault and in terms of when it happens.

-- 
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 Saturday, 5 March 2011 15:20:55 UTC