Intent to Ship: Fire toggle events using microtasks

[Joey Arhar]

Contact emails

jar...@chromium.org

Explainer

https://github.com/whatwg/html/issues/9046

Specification

https://github.com/whatwg/html/pull/9775

Summary

The toggle events for the popover attribute and the details element, as well as the close event for dialog elements, currently post a task to the DOM manipulation task source to fire these events asynchronously. This means that the event could fire before or after the next render, which could lead to flaky rendering for one frame. By using microtasks instead, the event will always fire before the next render. This was suggested in this HTML spec issue: https://github.com/whatwg/html/issues/9046

Blink component

Blink>DOM

TAG review

This is a very small change so I'm not making a TAG review.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

If websites are relying on the slower event timing somehow, then we could run into problems.

Gecko: Positive? https://github.com/whatwg/html/issues/9046#issuecomment-1724509340

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

I am not interested in any metrics changes for this feature, it should just make the behavior more consistent for web developers. Should it prove to have issues, I can disable it with a finch killswitch.

Requires code in //chrome?

False

Adoption expectation

If we ship this without breaking websites, then I think the other browsers will feel interested in implementing this as well.

Adoption plan

This change modifies several WPTs which the other browsers are likely watching, which will help encourage them to implement this as well.

Estimated milestones

No milestones specified

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5123249231101952

This intent message was generated by Chrome Platform Status.

[Philip Jägenstedt]

It sounds like the idea is to prove this web compatible by shipping it, before updating the spec. On the level of interest, there was no reaction on https://github.com/whatwg/html/issues/9046 after you asked. Is there other communication that makes you relatively sure the interest is there?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwJKWcg_ZCnSAs%3DML37a0Ov80V-gxcscbRwtCou15LE66w%40mail.gmail.com.

[Joey Arhar]

> On the level of interest, there was no reaction on https://github.com/whatwg/html/issues/9046 after you asked. Is there other communication that makes you relatively sure the interest is there?

I should have filed standards positions first. I have done so now:

- https://github.com/WebKit/standards-positions/issues/263

- https://github.com/mozilla/standards-positions/issues/901

> It sounds like the idea is to prove this web compatible by shipping it, before updating the spec

I intend to get positive signals from Gecko and WebKit first before actually shipping this.

I already have an HTML spec PR open, so the spec could be updated at any time.

There is a risk for web compatibility, although I was convinced that this should just improve the consistency of the event timing.

If there is significant breakage, I will disable this change via finch and revert the spec changes.

[Philip Jägenstedt]

Hi again Joey,

Can you bump this thread when you'd like to ship it?

Best regards,

Philip

[Joey Arhar]

> Can you bump this thread when you'd like to ship it?

Sure thing. It looks like more discussion about the behavior has started in the whatwg issue, so I'll wait for everything to be fully settled.

This feature is not a high priority for me at the moment.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYde%2BRE1TdkpjihAz_UXJjxJPaqzy4BKqhqygdNzM%2BMk8g%40mail.gmail.com.