Why would they stop working? The queued tasks don't get processed, but they're no-ops anyway, so that's fine. The rest of the algorithm works irrespective of whether the document is active or not, at least as specced in the HTML spec. Is it different in fetch.spec.whatwg.org?

At least step 10 in http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#fetch seems problematic...

Why? It's still associated with a browsing context, no?

It's not clear to me that a document that has been discarded is associated with a browsing context.

Why would it not be? Does anything disassociate it?

Hmmmmm. Maybe not... It seems hard to reason about a document that is no longer in memory.

But at least *this* seems like a problem:

"Cancel any instances of the fetch algorithm in the context of this Document"

http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#abort-a-document

called from

http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#discard-a-document

The spec doesn't say anything about it not being in memory, technically. :-)

But yeah, the cancelation is an issue...

We could make the ping=""s not be associated with a document, or something. Or pass a special argument to "fetch" that makes it safe from "abort". Or use something other than "fetch", somehow. Anne, any preferences?

So Fetch doesn't have that step 10 or knowledge of a Document object. The fetch algorithm defined in Fetch can be cancelled.

So HTML should probably track ongoing fetches and cancel them once a Document is collected. Having that collection is also useful for http://www.w3c-test.org/webperf/specs/ResourceTiming/ and company I guess.

Does that make sense?

Checking that steps like that are not removed is one of the things that I need to do before moving to the fetch spec. :-)

But that seems somewhat orthogonal to this bug. This bug is about how to _not_ cancel specific ongoing fetches in some circumstances.

So the Fetch standard definitely supports that, since there is no intertwingling. I try to write it from the perspective of the whole thing being on a distinct thread and I'd like to not bridge that even for specification convenience as I think it'll make things easier down the road (with service workers and other such features).

Well you presumably have _some_ intertwingling, since you have to push things onto the event loop, right?

Yeah, I do assume an event loop at the moment. I see that mostly as messaging things back out of the thread.

So what Document are you associating those tasks with?

It just puts them on the networking task source. I didn't know you had to explicitly associate with a document. Where is that done?

I see the problem though. Do you have some other way in mind to fix this?

All tasks have a document associated with them, so that the event loop knows whether to run them or not (it skips tasks associated with inactive documents).

This specific bug probably needs a way to invoke fetch that just makes a disassociated fetch that doesn't ever come back to us, and can't be canceled. Which is probably what all fetches are in the Fetch spec currently, but that shouldn't be. If that makes sense.

It makes sense. So maybe you should pass fetch a task source for it to use? What you say does not make sense for workers, or does it?

It wouldn't be a task queue, those are shared between documents (they're a property of the event loop). It'd be a document, as far as I can tell. And presumably these tasks would just explicitly pass null as the document.

Workers as specced are broken as far as this goes currently. Their tasks aren't associated with documents, but they have dedicated event loops so the document-based filtering should just be ignored. Filed bug 24390.

So is the idea that you either pass in a document or a worker to fetch and fetch than creates tasks with them?

Even so, if the document goes away, it seems it would need to cancel fetch explicitly unless it wants the request to continue.

I'm still a bit uneasy about this setup as fetch is in a different thread. And I know we don't have to worry too much about it in English-land, but I feel like not caring might bite us later.

Well at the end of the day, the tasks sent back from fetch for all cases except ping="" (and Beacon, I guess) need to end up on an event loop, and we have to (a) pick the right event loop, and (b) annotate the tasks in the way the event loop needs (which, for browsing context event loops, means knowing what document the task is for). I don't really mind how we do this, whether it's by passing in a lambda, or passing in opaque data, or passing in explicit data, or whatever.

(I'm going to punt on fixing this specific ping="" bug until I integrate with the fetch spec, so that I don't have to worry about fixing my version of fetch="" when I know I'm just going to defer to Anne's eventually anyway.)

So besides caring about the document or worker, don't we also care about which fetch operation the tasks are for? Do you have any suggestions for an interface that works for you?

Well presumably the tasks queued by a particular fetch algorithm instance are for that particular fetch algorithm instance, no? That seems implicit and obvious.

The interface I use in HTML now is sufficient, I think. I just talk about "the tasks queued by the fetch algorithm" or some such.

We should take the discussion of how to edit fetch to another bug, btw. e.g. bug 24080.

See also bug 23878.

Anne, I believe all this works these days, right? Please reopen if not.

Tentatively reopening since I'm pretty sure cancelation and how document lifetimes influence fetch is still very poorly defined.

I think we need to start with defining the lifetimes of groups of browsing contexts, browsing contexts, globals, and documents, and then figure out how those related to fetches. And then at some point what that means for an individual fetch.

https://github.com/whatwg/html/issues/4483