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.

Sign up for GitHub

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

Jump to bottom

Specify that some synthetic events cause actions #1394

Closed
nox opened this issue Jun 6, 2016 · 8 comments
Closed

Specify that some synthetic events cause actions #1394

nox opened this issue Jun 6, 2016 · 8 comments
Assignees
@annevk
Labels
topic: events

Comments

@nox
Copy link
Member

nox commented Jun 6, 2016

Refiling https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230 in hope it revives the discussion.

Some synthetic events (e.g. a synthetic click on a checkbox) cause actions (e.g. toggling the state of said checkbox).
@domenic
Copy link
Member

domenic commented Jun 6, 2016

See also #805. I'm not sure what the plan is here---do we need to formalize the "default action" concept perhaps, and call it "legacy default action", so that all the existing places the spec talks about "default action" are no longer undefined references?

It looks like @RByers and @dtapuska are involved in trying to make Chrome match... some spec, not sure which, but at least the general agreement to try to remove as many synthetic click activations as possible.

@dmethvin dmethvin mentioned this issue Jun 9, 2016
Closed
@annevk
Copy link
Member

annevk commented Oct 11, 2016

whatwg/dom#325 has a plan now by the way. Planning on getting things sorted. Shall we close the bug in favor of this issue?

@annevk annevk self-assigned this Oct 11, 2016
@RByers
Copy link

RByers commented Oct 11, 2016

SGTM. It's now only click that is special in blink.

@dtapuska
Copy link
Contributor

Note that it is only "MouseEvents" with type "click". We ran into a number of properties that created an "Event" with type "click" that failed in both FireFox and Chrome. But at least we are consistent now.

@annevk
Copy link
Member

annevk commented Oct 11, 2016

Yeah, the PR for DOM only considers MouseEvent/click. If that PR works I need to create a corresponding change to HTML to revamp some of its current language.

@annevk
Copy link
Member

annevk commented Oct 12, 2016

Just to be clear, whatwg/dom#325 has the plan and refactoring discussion for the dispatch algorithm. whatwg/dom#342 has the patch (review welcome, but will need a couple further tweaks).

In HTML we need to make these changes:

  • Most of the section "6.3 Activation" can be removed as all the special handling around the click event moves to DOM's dispatch algorithm.
  • Some cleanup is required around elements that define activation behavior. Since activation behavior will now be tied to an object (EventTarget), we cannot define it based on the presence of some attribute. This impacts the input element the most.
  • "pre-click activation steps" would be renamed to "legacy pre-click-dispatch steps"
  • "canceled activation steps" would be renamed to "legacy post-canceled-click-dispatch steps"
  • "activation behavior" we'd keep as-is, though we will start passing it the event as argument (for usage by label elements and <input type=image>). I don't really see a good strategy to move away from "activation behavior" for any new elements we might define, other than what would amount to added complexity. Best to just embrace it.

Please let me know if you have any concerns with this plan of action.

annevk added a commit to whatwg/dom that referenced this issue Oct 13, 2016
@annevk
Define special dispatch behavior for click events
b18e9a2 
User agents have always had special behavior for synthetic click
events. This is discussed to great extent in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230.

This change introduces the hooks to no longer make that magical, but an
understood and integral part of the processing model, ugly as it is.

This changes requires corresponding changes and cleanup in HTML. See
whatwg/html#1394 for that discussion.

Fixes #325.
@annevk annevk mentioned this issue Oct 14, 2016
Merged
@foolip
Copy link
Member

foolip commented Oct 14, 2016

Plan SGTM, although I take it "activation behavior" would no longer have a <dfn> in HTML, rather it all links to the DOM concept?

@annevk
Copy link
Member

annevk commented Oct 14, 2016

Yeah, same for "* activation steps" (and a whole lot of <dfn>s in "Activation" would simply disappear due to being obsolete).

annevk added a commit to whatwg/dom that referenced this issue Oct 17, 2016
@annevk
Define special dispatch behavior for click events
cb12fd4 
User agents have always had special behavior for synthetic click
events. This is discussed to great extent in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230.

This change introduces the hooks to no longer make that magical, but an
understood and integral part of the processing model, ugly as it is.

This changes requires corresponding changes and cleanup in HTML. See
whatwg/html#1394 for that discussion.

Fixes #325.
@annevk annevk mentioned this issue Oct 18, 2016
Merged
annevk added a commit that referenced this issue Oct 18, 2016
@annevk
Align activation behavior with the DOM Standard
38b2c31 
The biggest normative change here is that now any click event can cause
activation behavior to run. No exceptions.

It should be purely editorial otherwise.

Fixes #1394.
@annevk annevk mentioned this issue Oct 18, 2016
Merged
domenic pushed a commit that referenced this issue Oct 18, 2016
@annevk @domenic
Editorial: major cleanup around firing and dispatching events
8ffbd14 
This aligns firing and dispatching of events with updated terminology in
the DOM Standard. Among the changes:

* A lot less usage of "default action" which isn't really a thing.
  Instead we make use of the return value of the fire and dispatch
  algorithms.
* Instead of saying things bubble or are cancelable we initialize the
  attributes as such.
* We no longer re-state defaults for isTrusted, bubbles, and cancelable,
  as that only leads to confusion when they are *not* re-stated.
* We now use the legacy target override flag rather than supplying a
  named argument.

This fixes #1713, but plenty of follow up issues remain:

* #805 for the remainder of "default action" usage
* #1394 for updating synthetic click events
* #1887 for removing "fire a simple event" usage
* #1893 for updating when checkboxes get checked
* #1900 for figuring out if event dispatch requires more hooks
* #1912 for revisiting isTrusted usage
* #1913 for updating synthetic mouse events
* #1922 for making more events composed
domenic pushed a commit that referenced this issue Oct 18, 2016
@annevk @domenic
Align activation behavior with the DOM Standard
0937939 
The biggest normative change here is that now any click event can cause
activation behavior to run. No exceptions.

It should be purely editorial otherwise.

Fixes #1394.
@annevk annevk mentioned this issue Oct 19, 2016
Closed
annevk added a commit that referenced this issue Oct 20, 2016
@annevk
Align activation behavior with changes to DOM Standard
7beb920 
There are two major changes here:

* Any click event can cause activation behavior to run. No exceptions.
* The "click in progress flag" is now restricted to the click() method, as it already is in Firefox.

The other changes are editorial:

* "Activation behavior" is now associated with an object at all times (and cannot be conditionally associated)
* "Legacy-pre-activation behavior" and "legacy-canceled-activation behavior" are now more clearly only relevant for input elements in either the Checkbox or Radio Button state.
* Various concepts such as "run synthetic click activation steps" and "nearest activatable element" are gone as they are obsoleted by the DOM Standard or the aforementioned normative changes.

Tests related to this change:

* web-platform-tests/wpt#3974
* web-platform-tests/wpt#4034

Changes to the DOM Standard that were necessary for this change:

* whatwg/dom#342
* whatwg/dom#346

Fixes #1394.
alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
@annevk
Editorial: major cleanup around firing and dispatching events
36f4331 
This aligns firing and dispatching of events with updated terminology in
the DOM Standard. Among the changes:

* A lot less usage of "default action" which isn't really a thing.
  Instead we make use of the return value of the fire and dispatch
  algorithms.
* Instead of saying things bubble or are cancelable we initialize the
  attributes as such.
* We no longer re-state defaults for isTrusted, bubbles, and cancelable,
  as that only leads to confusion when they are *not* re-stated.
* We now use the legacy target override flag rather than supplying a
  named argument.

This fixes whatwg#1713, but plenty of follow up issues remain:

* whatwg#805 for the remainder of "default action" usage
* whatwg#1394 for updating synthetic click events
* whatwg#1887 for removing "fire a simple event" usage
* whatwg#1893 for updating when checkboxes get checked
* whatwg#1900 for figuring out if event dispatch requires more hooks
* whatwg#1912 for revisiting isTrusted usage
* whatwg#1913 for updating synthetic mouse events
* whatwg#1922 for making more events composed
alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
@annevk
Align activation behavior with changes to DOM Standard
3d020ea 
There are two major changes here:

* Any click event can cause activation behavior to run. No exceptions.
* The "click in progress flag" is now restricted to the click() method, as it already is in Firefox.

The other changes are editorial:

* "Activation behavior" is now associated with an object at all times (and cannot be conditionally associated)
* "Legacy-pre-activation behavior" and "legacy-canceled-activation behavior" are now more clearly only relevant for input elements in either the Checkbox or Radio Button state.
* Various concepts such as "run synthetic click activation steps" and "nearest activatable element" are gone as they are obsoleted by the DOM Standard or the aforementioned normative changes.

Tests related to this change:

* web-platform-tests/wpt#3974
* web-platform-tests/wpt#4034

Changes to the DOM Standard that were necessary for this change:

* whatwg/dom#342
* whatwg/dom#346

Fixes whatwg#1394.
@domenic domenic mentioned this issue Feb 25, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@annevk annevk

Labels
topic: events
Milestone
No milestone
Development

No branches or pull requests
6 participants
@nox @foolip @domenic @RByers @annevk @dtapuska