Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Synthetic submit event should probably trigger form submission #4438

Open
upsuper opened this issue Mar 20, 2019 · 6 comments
Open

Synthetic submit event should probably trigger form submission #4438

upsuper opened this issue Mar 20, 2019 · 6 comments
Labels
compat Standard is not web compatible or proprietary feature needs standardizing interop Implementations are not interoperable with each other topic: events topic: forms

Comments

@upsuper
Copy link
Member

upsuper commented Mar 20, 2019

It seems to me that currently dispatching a synthetic submit event to a form doesn't trigger submission of the form per spec, and dispatching submit event itself is a step in the form submit algorithm.

Gecko did submit when a synthetic submit event is dispatched to the form. When we tried to fix this difference in Gecko bug 1535988, we hit a compat issue that YUI 2 bases its behavior on browser detection. The condition is like

if ((UA.ie || UA.webkit) && bSubmitForm) {
  oForm.submit();
}

This basically means any browser which intends to conform to the spec but not pretends themselves as either IE or WebKit would hit this problem.

I suggest that we make synthetic submit event trigger form submission (when the event is not defaultPrevented), and block double submission of the same form (so that the extra submit() call wouldn't affect WebKit-based browsers).

What do you think?

@domenic domenic added compat Standard is not web compatible or proprietary feature needs standardizing topic: forms interop Implementations are not interoperable with each other topic: events labels Mar 20, 2019
@annevk
Copy link
Member

annevk commented Mar 21, 2019

It seems rather risky to make a decision like that based on this one data point. There might be other cases where it would hurt to do this, no?

Also, this would mean adding another special case to https://dom.spec.whatwg.org/#concept-event-dispatch.

@annevk
Copy link
Member

annevk commented Mar 21, 2019

#3599 is somewhat related.

@domenic
Copy link
Member

domenic commented Mar 21, 2019

Another option is to extend the spec's Gecko compatibility mode.

@rniwa
Copy link

rniwa commented Mar 30, 2019

This seems like a pretty risky change to make based on one version of YUI as @annevk says. Maybe Gecko can add a site specific quirk for this versions of YUI? Or do you have other examples of websites that rely on this behavior?

@upsuper
Copy link
Member Author

upsuper commented Mar 30, 2019

How can you add site specific quirk for such a widely used library?

@rniwa
Copy link

rniwa commented Mar 30, 2019

How can you add site specific quirk for such a widely used library?

By "site specific quirk", I don't mean to base quirk based on an URL but rather the pattern of usage that indicates that particular version of YUI. For example, WebKit used to have a quirk which got enabled based on file name from which CSS selector came from, etc... to detect some versions of media wiki for which a quirk was needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compat Standard is not web compatible or proprietary feature needs standardizing interop Implementations are not interoperable with each other topic: events topic: forms
Development

No branches or pull requests

4 participants