Should we check abortedDuringDownload in fireProgressEvent?

[nathanmemmott]

As the spec is written, could we have one or more progressEvents fired after abortedDuringDownload is set to true? The parallel steps could potentially queue several fireProgressEvents while the event loop is occupied. Also not sure what's expected when synchronizing abortedDuringDownload's state between event loop and the parallel steps.

[domenic]

Also not sure what's expected when synchronizing abortedDuringDownload's state between event loop and the parallel steps.

In general it's tricky to balance spec-writing between giving the full implementation details of an IPC system, versus being too vague to be useful. My current attempt of having a shared-across-threads/processes abortedDuringDownload variable was inspired by some things other specs (like Fetch) do, and I think it's a reasonable point on that continuum. But we could go deeper, by always queuing tasks (for the main thread) or using a parallel queue (for the background threads/processes).

But for now I'd prefer to focus on observable effects, which is where I think the first part of your issue comes in.

As the spec is written, could we have one or more progressEvents fired after abortedDuringDownload is set to true? The parallel steps could potentially queue several fireProgressEvents while the event loop is occupied.

I think this is right. We should prevent this possibility by re-checking abortedDuringDownload before firing the event, back on the main thread. I will post a PR to do this, and ask for your review.

I'll note that I seem to have anticipated this possibility already for other abort signal uses, e.g. here.

[nathanmemmott]

Ok makes sense, thanks for explaining.