Treat "fire an event" and script execution blocks as "tasks" if outside document-associated task#37
Treat "fire an event" and script execution blocks as "tasks" if outside document-associated task#37
Conversation
…ocument-associated task Some operations, like UI events, are not defined in terms of tasks. When those operations invoke a script or fire an event, treat the script or event firing timeframe as a "task" for the purposes of LoAF reporting. Closes #36
yoavweiss
left a comment
yoavweiss
left a comment
There was a problem hiding this comment.
A few questions/comments. Also the title is slightly botched and has a double negative that makes it confusing..
|
One more high-level question - why not rely on the implied document? |
noamr
changed the title
That concept is deprecated and hopefully will be removed from the standard at some point. |
noamr
changed the title
Fixed the issues and the title. |
noamr
changed the title
| [=list/append=] |scriptTimingInfo| to |frameTimingInfo|'s [=frame timing info/scripts=]. | ||
| 1. If |frameTimingInfo| is [=frame timing info/script initiated=], then [=record task end time=] given |endTime| and |document|. | ||
|
|
||
| Note: For event listeners, the task ends at the end of the [=fire an event=] algorithm rather than at the end of a single listener's execution. |
There was a problem hiding this comment.
It's not immediately obvious to me how this is set for event listeners. Can you point at the relevant algorithm?
There was a problem hiding this comment.
It's the [=fire an event=] algorithm I'm already pointing to :)
There was a problem hiding this comment.
Reworded a bit, is this better?
| <div algorithm="Record if needed"> | ||
| To <dfn export>start recording task time if needed</dfn> given an [=environment settings object=] |settingsObject|: | ||
|
|
||
| Note: this is called from the [=fire an event=] algorithm and the [=create script entry point=] algorithm. |
There was a problem hiding this comment.
IIUC, "fire an event" doesn't directly call this, but indirectly calls "create script entry point", which calls this. It might be good to rephrase
There was a problem hiding this comment.
Ah I see the confusion. This needs a corresponding DOM PR. I'll post one and link them.
Together with w3c/long-animation-frames#37 This allows clustering a "fire an event" timeframe in terms of frame timing monitoring, as opposed to relying on an "implicit document", which is a deprecated and non-interoperable term. The implication of this is that if this event firing schedules a render that ends up as a long animation frame, the whole event firing duration would be counted towards this performance entry, regardless of "tasks". See w3c/long-animation-frames#36
SHA: 088c2e1 Reason: push, by noamr Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
2 participants
Some operations, like UI events, are not defined in terms of tasks. When those operations invoke a script or fire an event, treat the script or event firing timeframe as a "task" for the purposes of LoAF reporting.
Currently, those should have a document associated to them with the "implied document" concept, however that is not interoperable and deprecated.
Together with whatwg/dom#1462
Closes #36
Preview | Diff