Closed
Bug 1477286
Opened 5 years ago
Closed 5 years ago
Fired submit event should not perform form submission
Categories
(Core :: DOM: Core & HTML, defect, P2)
Tracking
()
RESOLVED
DUPLICATE
of bug 1370630
People
(Reporter: scottbedard90, Assigned: edgar)
References
()
Details
(4 keywords)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 Steps to reproduce: 1. Create a form, and register a submit handler that calls preventDefault 2. Manually dispatch a "submit" event on that form Actual results: The event listener is fired, but preventDefault appears to do nothing This reproduction fiddle appears to work in all browsers except Firefox http://jsfiddle.net/nzfq6d5j Expected results: The event should be caught, and preventDefault should prevent the page navigation
Reporter | ||
Comment 1•5 years ago
|
||
The plot thickens, this workaround appears to work in all browsers, including Firefox. http://jsfiddle.net/nzfq6d5j/16 I believe e.preventDefault() should work the same in both situations, as it does in Chrome/Edge/Safari.
Updated•5 years ago
|
Component: Untriaged → DOM: Events
Product: Firefox → Core
Updated•5 years ago
|
Component: DOM: Events → DOM: Core & HTML
Reporter | ||
Comment 2•5 years ago
|
||
Cleaner test case http://jsfiddle.net/nzfq6d5j/28
Updated•5 years ago
|
Comment 3•5 years ago
|
||
I've done some quick investigation here, and I think the problem is actually slightly different. Here's what I would expect to happen based on the standard, and how Chrome behaves: EX.1 - User code calls 'form.dispatchEvent(new Event("submit"))', - A synthesized event is fired on the 'form' element, calling user-created 'submit' event listeners, - No navigation occurs whether or not the event is canceled, as the event was not created as part of the Form Submission Algorithm (https://html.spec.whatwg.org/#form-submission-algorithm). EX.2 - User code calls 'button.click()', - The browser performs button-click behaviour, firing a click event on the 'input' element, - If the event was canceled, the button-click behaviour does the default, which is to submit the form, - The browser runs 'Form Submission Algorithm', which acts as expected. However, Firefox acts differently, we end up performing the navigation after the 'submit' event was fired, whether or not it was fired by content. I imagine this is the root bug here. ni? Olli so he can correct me on this :-)
Flags: needinfo?(bugs)
Priority: -- → P2
Reporter | ||
Comment 4•5 years ago
|
||
(In reply to :Nika Layzell from comment #3) > I've done some quick investigation here, and I think the problem is actually > slightly different. > > Here's what I would expect to happen based on the standard, and how Chrome > behaves: > EX.1 > - User code calls 'form.dispatchEvent(new Event("submit"))', > - A synthesized event is fired on the 'form' element, calling user-created > 'submit' event listeners, > - No navigation occurs whether or not the event is canceled, as the event > was not created as part of the Form Submission Algorithm > (https://html.spec.whatwg.org/#form-submission-algorithm). > > EX.2 > - User code calls 'button.click()', > - The browser performs button-click behaviour, firing a click event on the > 'input' element, > - If the event was canceled, the button-click behaviour does the default, > which is to submit the form, > - The browser runs 'Form Submission Algorithm', which acts as expected. > > However, Firefox acts differently, we end up performing the navigation after > the 'submit' event was fired, whether or not it was fired by content. I > imagine this is the root bug here. > > ni? Olli so he can correct me on this :-) Yup, your assessment looks correct. And with that, we are able to simplify the test case even further. http://jsfiddle.net/nzfq6d5j/42
Comment 5•5 years ago
|
||
edgar, would you have time to look at this. Something around https://searchfox.org/mozilla-central/rev/51268dcbdff0f6f4a5cff7986df0f616efc5bcfd/dom/html/HTMLFormElement.cpp#488-512 I guess
Flags: needinfo?(bugs) → needinfo?(echen)
Assignee | ||
Updated•5 years ago
|
Assignee: nobody → echen
Flags: needinfo?(echen)
Assignee | ||
Updated•5 years ago
|
Summary: Submit events cannot be prevented when fired programatically → Fired submit event should not perform form submission
Assignee | ||
Comment 6•5 years ago
|
||
Currently we reply on sending the submit event to perform form submission (for input and button). This also causes we perform submission event if the submit event is fired by content. And this does not follow the Form Submission Algorithm [1]. [1] https://html.spec.whatwg.org/#form-submission-algorithm
Assignee | ||
Comment 7•5 years ago
|
||
bug 1370630 is a similar bug and it seems jenkins website still reply on sending submit event to perform form submission, unfortunately.
Comment 8•5 years ago
|
||
I think I found a different case when investigating bug 1487705. It would be great to get this fixed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 10•5 years ago
|
||
The bug I have referenced is not about Jenkins but Selenium.
Flags: needinfo?(hskupin)
Assignee | ||
Updated•5 years ago
|
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•