Closed Bug 1477286 Opened 6 years ago Closed 5 years ago

Fired submit event should not perform form submission

Categories

(Core :: DOM: Core & HTML, defect, P2)

61 Branch
defect

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
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.
Component: Untriaged → DOM: Events
Product: Firefox → Core
Component: DOM: Events → DOM: Core & HTML
Cleaner test case
http://jsfiddle.net/nzfq6d5j/28
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
(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
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: nobody → echen
Flags: needinfo?(echen)
Summary: Submit events cannot be prevented when fired programatically → Fired submit event should not perform form submission
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
bug 1370630 is a similar bug and it seems jenkins website still reply on sending submit event to perform form submission, unfortunately.
See Also: → 1399783
See Also: → 1370630
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
See comment 7 here.
Flags: needinfo?(hskupin)
The bug I have referenced is not about Jenkins but Selenium.
Flags: needinfo?(hskupin)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
No longer blocks: 1487705
You need to log in before you can comment on or make changes to this bug.