Long running scripts

[annevk]

1. Don't put normative statements in notes.
2. Don't make https://drafts.css-houdini.org/css-paint-api/ put up slow script dialogs. Make it result in an invalid image or some such...

@bzbarsky

[bzbarsky]

In particular, painting proceeds while a slow script thing is up. So using a slow script thing for something that blocks painting is broken by design.

[bfgeek]

We've discussed this previously at a F2F... there is a bit of context here / reasons for this.

(1) A long running paint worklet script (on the main thread), isn't different to a long running script in the main js environment. Hence should put up a slow script dialog thing.

(fundementally people can still do while(1); on the main thread, doesn't matter if this is inside worklet of main js environment).

(2) We don't want to force implementors to explicitly run the paint worklet on a separate thread, just so that they can kill it if there is a while(1); loop. We want to have the option to say "bad script" or whatever.

(3) There is debate as to whether we want paint to explicitly block the frame, and I think the rough consensus at the moment is that we do; but to add an option later to skip a paint function if it is running too long. E.g.

registerPaint('foo', class {
  static get mayBeAsync() { return true; }  // Implies can skip this if not enough time in a frame.
});

We haven't placed this in yet, as we want to see how authors actually use this initially before speccing something like this.

There is some debate as to whether the UA can "intervene" and place known bad painters on a background thread and be async (i think this might be a good compromise), but again need more real world experience here.

[bzbarsky]

A long running paint worklet is different from a main JS script in one simple way: putting up a slow script thing does NOT require reentry into main JS script (and in fact, not reentering it is preferable). But you do want to keep painting the page instead of having stuff freeze up, for better UX.

And that's what all this is about, really: this spec is trying to dictate UX, which is not really what it should be doing.

We don't want to force implementors to explicitly run the paint worklet on a separate thread, just so that they can kill it if there is a while(1); loop.

Why would that require having it on a separate thread? It totally doesn't, at least in the implemetations I'm familiar with. For example, the Firefox slow script dialog has a "kill script" option right there, which does just that. For a slow paint function we would just do that without bothering to ask the user and treat it just like we would treat the paint function throwing an exception. Which would produce an invalid image, per text already in the spec.

[bfgeek]

Why would that require having it on a separate thread?

Oh, just if you mandate it should produce an invalid image. In that case you imply that the pipeline can keep running and you need to place everything off in a separate thread, just in case you need to kill it.

Anyway... so what we should actually be saying is something along the lines of:

"""
The user-agent may decide themselves what to do in the case of a long running paint function. As an example the user-agent might choose to produce an invalid-image or to display a "long running script" dialog.
"""

[bzbarsky]

I'm still a bit confused by the "place everything off in a separate thread" bits and why that would be needed, but your proposed phrasing sounds fine as long as we make it clear that the UA is free to terminate the script and produce an invalid-image, not just leave the script running and produce an invalid-image.

[bfgeek]

Sounds good.