Open Bug 751457 Opened 12 years ago Updated 2 years ago

Slow script dialog from a worker event handler behavior could use improvement

Categories

(Core :: DOM: Workers, defect, P5)

Product:
Core
Component:
DOM: Workers
Platform:
x86
macOS
Type:
defect

Tracking

()

People

(Reporter: bzbarsky, Unassigned)

References

Details

Right now, if a worker event handler puts up a slow script dialog (or really, any other modal dialog), we keep processing events, including worker events.

It might be good, at least for the slow script dialog, to pause the worker.

Furthemore, if the slow script dialog comes up for a worker event and the user chooses "stop script", we should consider killing the worker.
(In reply to Boris Zbarsky (:bz) from comment #0)
> It might be good, at least for the slow script dialog, to pause the worker.

This is very easy to do, though all that code is currently written under the assumption that Suspend must be followed by Resume or Cancel (normal bfcache scenario), so we'd need to tweak it to hold some kind of suspend counter.

> Furthemore, if the slow script dialog comes up for a worker event and the
> user chooses "stop script", we should consider killing the worker.

I don't have a simple way currently to kill a specific worker from a page, just *all* workers from a page. We'd need to add this, but it should be very simple.

However, it may not make sense to do this... It is a main thread script that is hanging, after all (the worker script may be behaving appropriately).
Yes, but if the worker is firing events to the main thread and each of those events runs for a long time and the user selects "stop script", seems like the expectation would be to stop _something_.  Either the worker or the event delivery.
Right... it's just, what if that slow script was only in response to a particularly heavyweight (and rare?) event? And the rest are simple status updates or something? It's ridiculous to speculate, really. But when people click the stop button on main thread we don't blacklist that page from future code running. In my own experience things continue to work most of the time, even. Killing a worker is a bit different.
Fair.  In any case, just figured I'd get this filed.
I think we should definitely pause the worker while the slow script dialog is up, though.

That will actually queue up any events that have already been posted to the main thread as well, so we won't get some kind of recursive slow script behavior.
Oh, the slow script dialog knows about preventing self-recursion.  ;)
Kyle, Andrea, are either of you interested in taking this bug?
See Also: → 941297
Priority: -- → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.