preventDefault() on form.dispatchEvent(new Event('submit'))?

REOPENED
Assigned to
(NeedInfo from)

Status

()

P3
normal
REOPENED
2 years ago
2 months ago

People

(Reporter: janx, Assigned: edgar, NeedInfo)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

unspecified
mozilla56
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox56 fixed)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

2 years ago
When pasting the following address into various browsers, we get different results:

data:text/html,
<form action="https://www.mozilla.org/" id="form">
  <input type="submit" value="Navigate maybe">
</form>
<script>
  var form = document.getElementById("form");
  form.addEventListener("submit", function (event) {
    console.log(event.cancelable);
    event.preventDefault();
  });
  form.dispatchEvent(new Event('submit'));
</script>

- Firefox will navigate away (`event.preventDefault()` won't work)
- Chrome will not navigate away (`event.preventDefault()` will have the last word)

The correct behavior according to specs is to navigate (like Firefox does), because `new Event('submit')` is not cancelable unless you specify `new Event('submit', { cancelable: true })`.

I'm not sure if Chrome's behavior is a bug, or if it's intended to be helpful (my code does look like I'm trying hard not to submit), so I'll file a Chrome bug as well.

See also: https://stackoverflow.com/questions/40916300/how-can-i-preventdefault-on-dispatchevent
Thanks for the bug! It would be useful to know if this breaks sites for us to help us decide what to do here (i.e., implement Chrome's behavior and update the spec, or just close as INVALID).


I added the "hotlist-interop" label to the Chromium bug.
Component: General → DOM: Events
Product: Web Compatibility → Core
Stone may have thoughts here. Otherwise we can wait for Anne to return from PTO.
Flags: needinfo?(sshih)
Flags: needinfo?(annevk)
Like Janx's description, FF follows the spec and Chrome's behavior is helpful to web authors. Considering to be helpful to web authors, maybe we could consider giving the corresponding values of bubbles and cancelable for each kind of event so that users could simply create an event and dispatch it without caring the bubbles and cancelable values. But I don't know if it's worth to do it.
Flags: needinfo?(sshih)
Priority: -- → P3
(Reporter)

Comment 4

2 years ago
FYI, the Chromium bug was closed as WONTFIX:

From https://bugs.chromium.org/p/chromium/issues/detail?id=730108#c4
> This is a bug of Firefox. Dispatching non-trusted 'submit' event should not start form submission.  The specification doesn't define such behavior AFAIK.
(Reporter)

Comment 5

2 years ago
FYI Safari and Edge don't seem to navigate away either (Chrome's behavior).

Firefox seems to be the only browser that navigates away on the example code.
According to [1], untrusted events shouldn't trigger the UA default actions.

[1] https://www.w3.org/TR/uievents/#trusted-events
Assignee: nobody → sshih
Created attachment 8879069 [details] [diff] [review]
Bug 1370630 - Untrusted submit event shouldn't trigger form submission

Comment 8

2 years ago
To close my needinfo: Ming-Chou is correct (although note that there's an exception for the click event, as defined by https://dom.spec.whatwg.org/ in the Events section).
Flags: needinfo?(annevk)
Attachment #8879069 - Flags: review?(bugs)
Comment on attachment 8879069 [details] [diff] [review]
Bug 1370630 - Untrusted submit event shouldn't trigger form submission

Need to change also HTMLFormElement::GetEventTargetParent and maybe also HTMLFormElement::WillHandleEvent
Attachment #8879069 - Flags: review?(bugs) → review-
Created attachment 8883489 [details] [diff] [review]
Bug 1370630 - Untrusted submit event shouldn't trigger form submission
Attachment #8879069 - Attachment is obsolete: true
(In reply to Olli Pettay [:smaug] from comment #9)
> Comment on attachment 8879069 [details] [diff] [review]
> Bug 1370630 - Untrusted submit event shouldn't trigger form submission
> 
> Need to change also HTMLFormElement::GetEventTargetParent and maybe also
> HTMLFormElement::WillHandleEvent
I didn't change WillHandleEvent because it's related to the event propagation of nested form elements and I don't see a reason to have different behaviors of trusted or untrusted events.
Attachment #8883489 - Flags: review?(bugs)
Attachment #8883489 - Flags: review?(bugs) → review+

Comment 13

2 years ago
Pushed by sshih@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/367b6f947f87
Untrusted submit event shouldn't trigger form submission. r=smaug.

Comment 14

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/367b6f947f87
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox56: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
So, I have a mozilla-internal jenkins site (that uses YUI), that has been broken by this. I used mozregression to bisect the site problem back to exactly this change. 

Unfortunately, that site is not available to mozilla employees in general, so not sure how to give you something you can debug. Although, perhaps since this change might have impact on sites, this may be just an example of one (Jenkins).
reopened & marked as regression to catch folks eyes sooner.
Status: RESOLVED → REOPENED
Has Regression Range: --- → yes
Keywords: regression
Resolution: FIXED → ---
Note: the site does work Chrome Version 59.0.3071.115 on macOS 10.12.5
This one is fixed. Please file a followup bug or ask this one to be backed out (and once backed out, reopen).
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → FIXED
John, do you know why the site works on Chrome? I assume Jenkins uses some Gecko specific code it shoudn't use.
Flags: needinfo?(jrgm)
Mozregression shows this bug breaks https://webcompat.com/issues/8128 or any jenkins login, any idea?

Comment 21

2 years ago
Backout by sshih@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c7c8b33ba324
Backed out changeset 367b6f947f87 for breaking mozilla-internal jenkins site. r=backout.

Comment 22

2 years ago
Added an URL of a public Jenkins server
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 23

2 years ago
backoutbugherder
https://hg.mozilla.org/mozilla-central/rev/c7c8b33ba324
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → FIXED
reopen again
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Change Chrome's user agent to be the same as Firefox, Chrome doesn't work anymore. Apply my patch and change the user agent to be the same as Chrome, button submission works.
(In reply to Ming-Chou Shih [:stone] from comment #25)
> Change Chrome's user agent to be the same as Firefox, Chrome doesn't work
> anymore. Apply my patch and change the user agent to be the same as Chrome,
> button submission works.

Hi Eric,
According to the testing results, it's because the website behaves differently for different user agents and I have no idea how to proceed. Any suggestions about it?
Flags: needinfo?(etsai)
hi :stone, could you help to update some more detail about different behavior from which website? the public Jenkins server or mine private one?
Flags: needinfo?(etsai)
I verified on http://jenkins2.legacyserver.in/

I can verify it on the public server later.
(In reply to Ming-Chou Shih [:stone] from comment #28)
> I verified on http://jenkins2.legacyserver.in/
> 
> I can verify it on the public server later.
Oops. I don't have an account nor find a link to sign up.
(In reply to Ming-Chou Shih [:stone] from comment #29)
> (In reply to Ming-Chou Shih [:stone] from comment #28)
> > I verified on http://jenkins2.legacyserver.in/
> > 
> > I can verify it on the public server later.
> Oops. I don't have an account nor find a link to sign up.

Hi Eric,
I only can confirm that the problem on [1] is caused by the user agent. I don't have access to the public jenkins website [2]. Any suggestions?

[1] http://jenkins2.legacyserver.in/
[2] https://jenkins.qa.ubuntu.com/login?from=%2F
Flags: needinfo?(etsai)
Per-talk with :stone, I think if it's solved in an internal jenkins server, we should land first to make sure the behavior is correct.
If there is any UA detection makes this not work, please file another bug in webcompat general or Tech_Evangelism to outreach.
Flags: needinfo?(etsai)
See Also: → bug 1399783
See Also: → bug 1477286
Depends on: 1399783
Keywords: regression
See Also: bug 1399783

Comment 32

4 months ago
https://github.com/jenkinsci/jenkins/pull/3689 is a PR to make Jenkins work again as soon the fix has landed in FF, however that means the server needs to use the newest version of jenkins or patch their version of hudson-behavior.js as demonstrated in the pr.
Duplicate of this bug: 1477286
Blocks: 1487705
Assignee: stone123456 → echen
You need to log in before you can comment on or make changes to this bug.