24137 2013-12-19 12:17:07 +0000 I think the fetching stops working per spec after the document has unloaded, since the document isn't fully active at that point (or maybe the document even gets discarded before all ping URLs have started fetching) 2019-03-29 21:24:45 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other All RESOLVED MOVED http://www.whatwg.org/specs/web-apps/current-work/#hyperlink-auditing blocked on dependencies P3 normal Unsorted 24080 1 contributor annevk annevk d ian mike zcorpan contributor oldest_to_newest 97804 0 contributor 2013-12-19 12:17:07 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html Multipage: http://www.whatwg.org/C#hyperlink-auditing Complete: http://www.whatwg.org/c#hyperlink-auditing Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html Comment: I think the fetching stops working per spec after the document has unloaded, since the document isn't fully active at that point (or maybe the document even gets discarded before all ping URLs have started fetching) Posted from: 90.230.218.37 by simonp@opera.com User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.19 Safari/537.36 OPR/19.0.1326.9 (Edition Next) 97981 1 ian 2014-01-03 22:08:00 +0000 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? 98073 2 zcorpan 2014-01-07 13:52:52 +0000 At least step 10 in http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#fetch seems problematic... 98146 3 ian 2014-01-08 19:25:52 +0000 Why? It's still associated with a browsing context, no? 98151 4 zcorpan 2014-01-08 20:06:53 +0000 It's not clear to me that a document that has been discarded is associated with a browsing context. 98214 5 ian 2014-01-09 18:57:17 +0000 Why would it not be? Does anything disassociate it? 98230 6 zcorpan 2014-01-09 21:34:45 +0000 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 98384 7 ian 2014-01-14 00:07:18 +0000 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? 98406 8 annevk 2014-01-14 10:29:10 +0000 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? 98447 9 ian 2014-01-14 19:14:04 +0000 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. 98481 10 annevk 2014-01-15 09:33:47 +0000 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). 98528 11 ian 2014-01-15 22:23:24 +0000 Well you presumably have _some_ intertwingling, since you have to push things onto the event loop, right? 98563 12 annevk 2014-01-16 10:50:32 +0000 Yeah, I do assume an event loop at the moment. I see that mostly as messaging things back out of the thread. 98632 13 ian 2014-01-16 17:17:22 +0000 So what Document are you associating those tasks with? 98692 14 annevk 2014-01-17 11:11:52 +0000 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? 98722 15 ian 2014-01-17 21:39:39 +0000 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. 98957 16 annevk 2014-01-23 20:07:05 +0000 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? 99048 17 ian 2014-01-24 23:43:46 +0000 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. 99054 18 annevk 2014-01-24 23:50:48 +0000 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. 99190 19 ian 2014-01-27 20:07:14 +0000 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. 99368 20 ian 2014-01-28 23:30:49 +0000 (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.) 99446 21 annevk 2014-01-30 00:22:45 +0000 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? 100045 22 ian 2014-02-07 18:22:54 +0000 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. 100074 23 ian 2014-02-07 23:47:20 +0000 We should take the discussion of how to edit fetch to another bug, btw. e.g. bug 24080. 114231 24 annevk 2014-10-30 11:34:32 +0000 See also bug 23878. 128316 25 d 2016-12-13 14:15:37 +0000 Anne, I believe all this works these days, right? Please reopen if not. 128318 26 annevk 2016-12-13 18:10:42 +0000 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. 129698 27 d 2019-03-29 21:24:45 +0000 https://github.com/whatwg/html/issues/4483