Provide sync measurement methods within a special requestMeasurementFrame callback

[jacob314]

Within this callback, any calls mutating the DOM should trigger an assert in dev mode.

[vsmenon]

Removed Area-UI label.
Added Area-DOM label.

[vsmenon]

Jacob: is this still an open?

---

Added this to the M1 milestone.
Added NeedsInfo label.

[jmesserly]

Yes. Though I think we were considering removal/redesign of async measurement?

[iposva-google]

Removed Area-DOM label.
Added Area-HTML label.

[vsmenon]

Removed the owner.
Added Triaged label.

[vsmenon]

Removed this from the M1 milestone.
Added this to the M2 milestone.

[jmesserly]

I don't know if we have this tracked in another bug or not, but having a nice "microtask" API to queue something that will happen before paint would be really useful as a general feature.

[DartBot]

This comment was originally written by [email protected]

---

I am definitely interested in a "sync" version. I have implemented some code that is definitely overly-complex due to how the async version makes my application-execution-path utterly nonsensical without an equally strange workaround that requires me to put a callback into the future-based-async routine (current version) that, only on the first completion, actually launches my application through my desired-execution-path via what is essentially a new "main()" entry point provided in the callback. ughhh.

[blois]

For a microtask API- you should be able to use window.requestLayoutFrame for this purpose.

I do find it a bit odd though that layout effectively runs at a higher priority than animation though, so we may want to consider some name changes here.

[blois]

The synchronous measurement APIs have been unhidden, no need to use requestMeasurementFrame.

---

Added Fixed label.