Created attachment 372766 [details] Patch

Created attachment 372854 [details] Patch

Created attachment 372908 [details] Patch

Comment on attachment 372908 [details] Patch Attachment 372908 [details] did not pass mac-ews (mac): Output: https://webkit-queues.webkit.org/results/12578887 New failing tests: http/wpt/prefetch/navigate-reuse-prefetch.html

Created attachment 372909 [details] Archive of layout-test-results from ews101 for mac-highsierra The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews101 Port: mac-highsierra Platform: Mac OS X 10.13.6

Comment on attachment 372908 [details] Patch Attachment 372908 [details] did not pass mac-debug-ews (mac): Output: https://webkit-queues.webkit.org/results/12578911 New failing tests: http/wpt/prefetch/navigate-reuse-prefetch.html

Created attachment 372910 [details] Archive of layout-test-results from ews112 for mac-highsierra The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews112 Port: mac-highsierra Platform: Mac OS X 10.13.6

Comment on attachment 372908 [details] Patch Attachment 372908 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/12578978 New failing tests: http/wpt/prefetch/navigate-reuse-prefetch.html

Created attachment 372911 [details] Archive of layout-test-results from ews212 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews212 Port: win-future Platform: CYGWIN_NT-10.0-17763-3.0.5-338.x86_64-x86_64-64bit

Created attachment 372936 [details] Patch

Comment on attachment 372936 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=372936&action=review > Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:421 > + if (auto session = networkProcess().networkSession(loadParameters.sessionID)) { auto* > Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:422 > + auto url = loadParameters.request.url(); const auto& > Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:423 > + if (session->waitingForPendingPrefetch(url)) { I would rename waitingForPendingPrefetch to hasOngoingPrefetch. > Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:936 > +void NetworkConnectionToWebProcess::prefetchFinished(const PAL::SessionID& sessionID, const URL& url, WebCore::ResourceResponse&& response, RefPtr<WebCore::SharedBuffer>&& buffer) We are not consistent in const PAL::SessionID& vs. PAL::SessionID. I slightly prefer PAL::SessionID. > Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:942 > + m_networkResourceLoaders.add(crossOriginPrefetch->identifier(), crossOriginPrefetch.releaseNonNull()); I am not clear why we need this. If the crossOriginPrefetch is finished, why are we keeping the NetworkResourceLoader in the map? Is it for being able to clear it shortly after? If session->hasPendingNavigation(url) is true, session->takeCrossOriginPrefetchLoad(url) should be true as well in most cases but maybe not all? > Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:943 > + auto loadParameters = session->takePendingNavigation(url); We are doing two HashMap queries hasPendingNavigation and takePendingNavigation. With find, we could do just one. > Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:946 > + loader->start(); Could be rewritten as something like m_networkResourceLoaders.add(loadParameters.identifier, WTFMove(loader)).iterator->value->start(); > Source/WebKit/NetworkProcess/NetworkSession.cpp:237 > + if (auto ret = m_pendingCrossOriginPrefetchLoads.take(url)) s/ret/result > LayoutTests/http/wpt/prefetch/resources/navigate-redirect.html:9 > + document.body.appendChild(link); You can probably use .sub.html to write it directly as <link rel="prefetch" href=""http://{{host[alt][]}}:{{ports[http][0]}}/WebKit/prefetch/resources/prefetched-main-resource-redirect.py"

Created attachment 373213 [details] Patch

Created attachment 373229 [details] Patch

Comment on attachment 372936 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=372936&action=review >> Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:421 >> + if (auto session = networkProcess().networkSession(loadParameters.sessionID)) { > > auto* Done. >> Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:422 >> + auto url = loadParameters.request.url(); > > const auto& Done. >> Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:423 >> + if (session->waitingForPendingPrefetch(url)) { > > I would rename waitingForPendingPrefetch to hasOngoingPrefetch. Done. >> Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:936 >> +void NetworkConnectionToWebProcess::prefetchFinished(const PAL::SessionID& sessionID, const URL& url, WebCore::ResourceResponse&& response, RefPtr<WebCore::SharedBuffer>&& buffer) > > We are not consistent in const PAL::SessionID& vs. PAL::SessionID. > I slightly prefer PAL::SessionID. Done. >> Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:942 >> + m_networkResourceLoaders.add(crossOriginPrefetch->identifier(), crossOriginPrefetch.releaseNonNull()); > > I am not clear why we need this. > If the crossOriginPrefetch is finished, why are we keeping the NetworkResourceLoader in the map? Is it for being able to clear it shortly after? > > If session->hasPendingNavigation(url) is true, session->takeCrossOriginPrefetchLoad(url) should be true as well in most cases but maybe not all? Yes, we need it because it will be cleared in NetworkConnectionToWebProcess::didCleanupResourceLoader. I did not like that code though, so I solved it differently, a lot like keep alive code. >> Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:943 >> + auto loadParameters = session->takePendingNavigation(url); > > We are doing two HashMap queries hasPendingNavigation and takePendingNavigation. With find, we could do just one. Done. >> Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:946 >> + loader->start(); > > Could be rewritten as something like m_networkResourceLoaders.add(loadParameters.identifier, WTFMove(loader)).iterator->value->start(); Done. >> Source/WebKit/NetworkProcess/NetworkSession.cpp:237 >> + if (auto ret = m_pendingCrossOriginPrefetchLoads.take(url)) > > s/ret/result Done. >> LayoutTests/http/wpt/prefetch/resources/navigate-redirect.html:9 >> + document.body.appendChild(link); > > You can probably use .sub.html to write it directly as > <link rel="prefetch" href=""http://{{host[alt][]}}:{{ports[http][0]}}/WebKit/prefetch/resources/prefetched-main-resource-redirect.py" Done.

Comment on attachment 373229 [details] Patch Note that I think we could/should make this work for same-origin prefetches as well, but it seems non trivial, so I am hoping this can go in first.

Comment on attachment 373229 [details] Patch This feature seems problematic from fingerprinting standpoint. Wouldn't this feature allow domain A.com to prefetch tracker.com and then the user visits B.com, it can cycle through tracker.com to detect whether the user had visited A.com or not by detecting whether the page load had hit the prefetch cache or not?

+John, Maciej for assessing the fingerprinting issue I mention above.

> Wouldn't this feature allow domain A.com to prefetch tracker.com and then > the user visits B.com, it can cycle through tracker.com to detect whether > the user had visited A.com or not by detecting whether the page load had hit > the prefetch cache or not? Only the main frame is allowed to use the prefetch cache. A.com can prefetch tracker.com so that A.com -> tracker.com -> B.com will be faster than it is now.

Comment on attachment 373229 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=373229&action=review > Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:430 > + session->addPendingNavigation(url, WTFMove(loadParameters)); It seems that load will hang in case the prefetch loading fails? We should probably trigger the load with the load path. > Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:946 > + if (Optional<NetworkResourceLoadParameters> loadParameters = session->takePendingNavigation(url)) { auto > Source/WebKit/NetworkProcess/NetworkSession.cpp:250 > + return m_pendingNavigations.take(url); This does two search on the map, we should be able with find/remove to make just one.

Created attachment 373384 [details] Patch

(In reply to youenn fablet from comment #18) > > Wouldn't this feature allow domain A.com to prefetch tracker.com and then > > the user visits B.com, it can cycle through tracker.com to detect whether > > the user had visited A.com or not by detecting whether the page load had hit > > the prefetch cache or not? > > Only the main frame is allowed to use the prefetch cache. > A.com can prefetch tracker.com so that A.com -> tracker.com -> B.com will be > faster than it is now. Yeah, so this will create a new tracking mechanism because you can detect that it was fast (and therefore prefetch'ed). Basically, A.com can contain a tracking script which inserts <link rel=prefetch href=tracker.com?url=a.com> to the main page. When B.com is loaded, it can immediately navigate to tracker.com?url=a.com to detect that the user had visited A.com based on how fast tracker.com loads. I'm pretty certain there is a clever trick to make this tracking mechanism more powerful. In general, this feature seems to circumvent the whole partitioning of our disk cache based on top-level domain so there could be other privacy holes.

Created attachment 373388 [details] Patch

Is a page limited in how many pages it can prefetch? Does <link rel=prefetch> have any signal for whether the prefetch succeeded or how long it took, such as load or error events?

Also, just to confirm, is `<link rel=prefetch>` supposed to bypass cache partitioning, and is it supposed to use the first party cookies for the prefetched resource?

Hmmm, if `<link rel=prefetch>` is allowed to load with first party cookies and gets Referer, then it could be used a tracking pixel that bypasses ITP, even without redirect tricks. BTW, we know motivated trackers *will* use redirect tricks to get a user ID that then gets boosted into first party storage if they are able to. They did it with HSTS. I'd rather not see this land until there is a clear privacy story (unless there's a WebKit port that really wants to ship prefetch regardless of the privacy problems).

(In reply to Maciej Stachowiak from comment #23) > Is a page limited in how many pages it can prefetch? Does <link > rel=prefetch> have any signal for whether the prefetch succeeded or how long > it took, such as load or error events? Currently, there is no such limitation in the implementation. This seems reasonable to me as well as the possibility to scope which pages can get access to which prefetches. As for load/error events, this is under discussion on GitHub. (In reply to Maciej Stachowiak from comment #24) > Also, just to confirm, is `<link rel=prefetch>` supposed to bypass cache > partitioning, and is it supposed to use the first party cookies for the > prefetched resource? The idea is that it is supposed to bypass cache partitioning in a specific way, no data persistency, short lifetime and restricted access to specific loads. The prefetch load is no credentials and manual redirect mode.

GitHub links: https://github.com/whatwg/fetch/pull/881 and https://github.com/whatwg/html/pull/4115

The Resource Hints spec that is linked by the HTML spec currently does not say anything about loads being without credentials, and even seems to allow CORS to read back the contents of a load with-credentials. And it also doesn't say to suppress load and error events, which happen for other link types that load a resource. Is that Resource Hints spec obsolete and planned to be replaced with material inline in Fetch and HTML? https://w3c.github.io/resource-hints/

The prefetch part is being specced as PRs that are not merged right now. These PRs require the notion of partitioning, a new kind of load maybe so they are not straightforward. Yoav knows more about the current state of the PRs. For instance, I think the fetch PR states that credentials more is same origin.

If prefetching is without credentials, does that mean it can not safely be used for main resources in general? Only for sub resources known not to depend on cookies?

BTW doing a privacy review of something only described by PRs to multiple specs is pretty hard. it would be nice to have an explainer of how the whole thing is supposed to work.

Comment on attachment 373229 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=373229&action=review >> Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:430 >> + session->addPendingNavigation(url, WTFMove(loadParameters)); > > It seems that load will hang in case the prefetch loading fails? > We should probably trigger the load with the load path. I think it depends on the load fail. It seems 4xx and 5xx responses go through NetworkResourceLoader::didFinishLoading so they are on the right track. I found out however that the code to re-use the prefetch in NetworkResourceLoader::retrieveCacheEntry does not work for non-cacheable responses. To try to fix this I created https://bugs.webkit.org/show_bug.cgi?id=199499. The rest of the failures I expect to go through NetworkResourceLoader::didFailLoading, where we could add a hook similar to NetworkConnectionToWebProcess::prefetchFinished, but for load failures (authentication, bad port etc.). I would be curious to know if there are more failure code paths though. >> Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:946 >> + if (Optional<NetworkResourceLoadParameters> loadParameters = session->takePendingNavigation(url)) { > > auto Done. >> Source/WebKit/NetworkProcess/NetworkSession.cpp:250 >> + return m_pendingNavigations.take(url); > > This does two search on the map, we should be able with find/remove to make just one. Done.

(In reply to youenn fablet from comment #29) > The prefetch part is being specced as PRs that are not merged right now. > These PRs require the notion of partitioning, a new kind of load maybe so > they are not straightforward. > Yoav knows more about the current state of the PRs. The intent is indeed to integrate Prefetch's processing model into HTML and obsolete the parts of the Resource Hints spec which refer to it. > > For instance, I think the fetch PR states that credentials more is same > origin.

Created attachment 375031 [details] Patch

Just an update to this thread: Chromium is interested in implementing the changes to prefetch requests proposed by Youenn in [1]. I've filed a request for a TAG review [2] as a part of our Intent to Implement, but ultimately having an explainer for these changes and their suspected effects would be ideal, as Maciej mentioned. [1]: https://github.com/w3c/resource-hints/issues/82 [2]: https://github.com/w3ctag/design-reviews/issues/398

Created attachment 377007 [details] Patch

Created attachment 377008 [details] Patch

Created attachment 377011 [details] Patch

Created attachment 377106 [details] Patch

Comment on attachment 377106 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=377106&action=review > Source/WebCore/platform/network/ResourceRequestBase.cpp:275 > + return httpHeaderField(HTTPHeaderName::Purpose) == "prefetch"; Is this case sensitive, or should be it equalLettersIgnoringASCIICase?

Created attachment 377150 [details] Patch

(In reply to Darin Adler from comment #40) > Comment on attachment 377106 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=377106&action=review > > > Source/WebCore/platform/network/ResourceRequestBase.cpp:275 > > + return httpHeaderField(HTTPHeaderName::Purpose) == "prefetch"; > > Is this case sensitive, or should be it equalLettersIgnoringASCIICase? Unfortunately AFAIK it is not specified (yet), but I am fine with case insensitive, so I updated the patch.

(In reply to Rob Buis from comment #42) > Unfortunately AFAIK it is not specified (yet), but I am fine with case > insensitive, so I updated the patch. Do you know if there is any plan to specify it? I think this should be reported to the spec authors and we should have tests for it.

It is specified. This isn't a prefetch-specific thing; HTML Standard notes that link types are specified by link "keywords", and all keywords are ASCII case-insensitive [1]. [1]: https://html.spec.whatwg.org/multipage/links.html#linkTypes

Created attachment 380610 [details] Patch

Created attachment 380617 [details] Patch

Comment on attachment 380617 [details] Patch Attachment 380617 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/13116694 New failing tests: http/tests/preload/picture-type.html

Created attachment 380711 [details] Archive of layout-test-results from ews210 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews210 Port: win-future Platform: CYGWIN_NT-10.0-17763-3.0.5-338.x86_64-x86_64-64bit

Created attachment 391646 [details] Patch

Comment on attachment 391646 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=391646&action=review > Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:452 > + if (session->hasOngoingCrossOriginPrefetch(url)) { What if navigation is POST form? > Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:1126 > + m_networkResourceLoaders.add(identifier, WTFMove(loader)).iterator->value->start(); I do not think we want to wait for prefetchFinished since we want to parse data as fast as possible. Ideally we would just migrate the loader. Maybe we could wait for the response though?

Created attachment 408325 [details] Patch

How is the matching between cross-origin prefetch and navigation done? Does this prevent us from stopping link decoration tracking down the road? Would we have to apply any link decoration prevention to these prefetch requests “just in case?”

(In reply to John Wilander from comment #52) > How is the matching between cross-origin prefetch and navigation done? Does > this prevent us from stopping link decoration tracking down the road? Would > we have to apply any link decoration prevention to these prefetch requests > “just in case?” If the caching is done with top origin as a key then no link decoration prevention or similar tactics are needed.

(In reply to Dima Voytenko from comment #53) > (In reply to John Wilander from comment #52) > > How is the matching between cross-origin prefetch and navigation done? Does > > this prevent us from stopping link decoration tracking down the road? Would > > we have to apply any link decoration prevention to these prefetch requests > > “just in case?” > > If the caching is done with top origin as a key then no link decoration > prevention or similar tactics are needed. Is the cache partitioned in that fashion? That would mean that the prefetch doesn't apply to cross-origin navigations, right?

(In reply to John Wilander from comment #54) > (In reply to Dima Voytenko from comment #53) > > (In reply to John Wilander from comment #52) > > > How is the matching between cross-origin prefetch and navigation done? Does > > > this prevent us from stopping link decoration tracking down the road? Would > > > we have to apply any link decoration prevention to these prefetch requests > > > “just in case?” > > > > If the caching is done with top origin as a key then no link decoration > > prevention or similar tactics are needed. > > Is the cache partitioned in that fashion? That would mean that the prefetch > doesn't apply to cross-origin navigations, right? What I'm talking about here is this scenario: 1. The user is on social.example 2. social.example prefetches news.example/article?trackingID=abcd1234 3. The user clicks to navigate to what looks like news.example/article 4. social.example actually navigates to news.example/article?trackingID=abcd1234 in an attempt to track the user cross-site 5. Tracking prevention has code to detect link decoration tracking and remove it but no network request is made since there's a cache hit and the user is navigated to news.example/article?trackingID=abcd1234 and tracked

(In reply to John Wilander from comment #55) > (In reply to John Wilander from comment #54) > > (In reply to Dima Voytenko from comment #53) > > > (In reply to John Wilander from comment #52) > > > > How is the matching between cross-origin prefetch and navigation done? Does > > > > this prevent us from stopping link decoration tracking down the road? Would > > > > we have to apply any link decoration prevention to these prefetch requests > > > > “just in case?” > > > > > > If the caching is done with top origin as a key then no link decoration > > > prevention or similar tactics are needed. > > > > Is the cache partitioned in that fashion? That would mean that the prefetch > > doesn't apply to cross-origin navigations, right? > > What I'm talking about here is this scenario: > > 1. The user is on social.example > 2. social.example prefetches news.example/article?trackingID=abcd1234 > 3. The user clicks to navigate to what looks like news.example/article > 4. social.example actually navigates to > news.example/article?trackingID=abcd1234 in an attempt to track the user > cross-site > 5. Tracking prevention has code to detect link decoration tracking and > remove it but no network request is made since there's a cache hit and the > user is navigated to news.example/article?trackingID=abcd1234 and tracked Got it. I misunderstood this issue as having to do with the prefetch of the cross-origin resources (such as hero image) on a same-origin page. E.g. a scenario where my.example/one.html uses this prefetch: ``` <link rel="prefetch" href="//cdn.example/images/big.jpeg"> ``` in hope to use this resource soon and reduce its perceived network time. This kind of scenario is described in https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ. This kind of prefetch has to be done in the context of the "my.example" origin's cache, otherwise it'd be a cache miss later. Right? If so, I don't think `<link rel="prefetch" href="//news.example/article?trackingID=abcd">` will make any sense. If follow the rule above, this prefetch happens in the context of "my.example" origin, then the top-level navigation to this URL would be always a cache miss.

(In reply to Dima Voytenko from comment #56) > (In reply to John Wilander from comment #55) > > (In reply to John Wilander from comment #54) > > > (In reply to Dima Voytenko from comment #53) > > > > (In reply to John Wilander from comment #52) > > > > > How is the matching between cross-origin prefetch and navigation done? Does > > > > > this prevent us from stopping link decoration tracking down the road? Would > > > > > we have to apply any link decoration prevention to these prefetch requests > > > > > “just in case?” > > > > > > > > If the caching is done with top origin as a key then no link decoration > > > > prevention or similar tactics are needed. > > > > > > Is the cache partitioned in that fashion? That would mean that the prefetch > > > doesn't apply to cross-origin navigations, right? > > > > What I'm talking about here is this scenario: > > > > 1. The user is on social.example > > 2. social.example prefetches news.example/article?trackingID=abcd1234 > > 3. The user clicks to navigate to what looks like news.example/article > > 4. social.example actually navigates to > > news.example/article?trackingID=abcd1234 in an attempt to track the user > > cross-site > > 5. Tracking prevention has code to detect link decoration tracking and > > remove it but no network request is made since there's a cache hit and the > > user is navigated to news.example/article?trackingID=abcd1234 and tracked > > Got it. I misunderstood this issue as having to do with the prefetch of the > cross-origin resources (such as hero image) on a same-origin page. E.g. a > scenario where my.example/one.html uses this prefetch: > > ``` > <link rel="prefetch" href="//cdn.example/images/big.jpeg"> > ``` > > in hope to use this resource soon and reduce its perceived network time. > This kind of scenario is described in > https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ. > > This kind of prefetch has to be done in the context of the "my.example" > origin's cache, otherwise it'd be a cache miss later. Right? > > If so, I don't think `<link rel="prefetch" > href="//news.example/article?trackingID=abcd">` will make any sense. If > follow the rule above, this prefetch happens in the context of "my.example" > origin, then the top-level navigation to this URL would be always a cache > miss. Then I'm confused by the title of this bug: "Cross-origin ongoing prefetches should be reused for top-level navigations"

(In reply to John Wilander from comment #57) > > Got it. I misunderstood this issue as having to do with the prefetch of the > > cross-origin resources (such as hero image) on a same-origin page. E.g. a > > scenario where my.example/one.html uses this prefetch: > > > > ``` > > <link rel="prefetch" href="//cdn.example/images/big.jpeg"> > > ``` > > > > in hope to use this resource soon and reduce its perceived network time. > > This kind of scenario is described in > > https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ. > > > > This kind of prefetch has to be done in the context of the "my.example" > > origin's cache, otherwise it'd be a cache miss later. Right? > > > > If so, I don't think `<link rel="prefetch" > > href="//news.example/article?trackingID=abcd">` will make any sense. If > > follow the rule above, this prefetch happens in the context of "my.example" > > origin, then the top-level navigation to this URL would be always a cache > > miss. > > Then I'm confused by the title of this bug: "Cross-origin ongoing prefetches > should be reused for top-level navigations" This bug was a way to address a question Youenn posted in an internal discussion: - If the navigation load kicks in before the prefetch is finished, the prefetch will not be used. Can we improve this? So really this bug is to optimise above scenario. Since my work was related to the cross origin prefetch cache, it seems to me the title is accurate given the context?

(In reply to Rob Buis from comment #58) > (In reply to John Wilander from comment #57) > > > Got it. I misunderstood this issue as having to do with the prefetch of the > > > cross-origin resources (such as hero image) on a same-origin page. E.g. a > > > scenario where my.example/one.html uses this prefetch: > > > > > > ``` > > > <link rel="prefetch" href="//cdn.example/images/big.jpeg"> > > > ``` > > > > > > in hope to use this resource soon and reduce its perceived network time. > > > This kind of scenario is described in > > > https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ. > > > > > > This kind of prefetch has to be done in the context of the "my.example" > > > origin's cache, otherwise it'd be a cache miss later. Right? > > > > > > If so, I don't think `<link rel="prefetch" > > > href="//news.example/article?trackingID=abcd">` will make any sense. If > > > follow the rule above, this prefetch happens in the context of "my.example" > > > origin, then the top-level navigation to this URL would be always a cache > > > miss. > > > > Then I'm confused by the title of this bug: "Cross-origin ongoing prefetches > > should be reused for top-level navigations" > > This bug was a way to address a question Youenn posted in an internal > discussion: > - If the navigation load kicks in before the prefetch is finished, the > prefetch will not be used. Can we improve this? > > So really this bug is to optimise above scenario. > Since my work was related to the cross origin prefetch cache, it seems to me > the title is accurate given the context? With the proposed change, can SiteA prefetch anything from SiteB that will be used in a navigation to SiteB? The title "Cross-origin ongoing prefetches should be reused for top-level navigations" reads to me as "If SiteA has started to pre-fetch a URL from SiteB, and the user navigates to that SiteB URL, use the pre-fetch instead of starting a new network load." If my understanding is correct, then there are implications for link decoration tracking.

(In reply to John Wilander from comment #59) > (In reply to Rob Buis from comment #58) > > (In reply to John Wilander from comment #57) > > > Then I'm confused by the title of this bug: "Cross-origin ongoing prefetches > > > should be reused for top-level navigations" > > > > This bug was a way to address a question Youenn posted in an internal > > discussion: > > - If the navigation load kicks in before the prefetch is finished, the > > prefetch will not be used. Can we improve this? > > > > So really this bug is to optimise above scenario. > > Since my work was related to the cross origin prefetch cache, it seems to me > > the title is accurate given the context? > > With the proposed change, can SiteA prefetch anything from SiteB that will > be used in a navigation to SiteB? > > The title "Cross-origin ongoing prefetches should be reused for top-level > navigations" reads to me as "If SiteA has started to pre-fetch a URL from > SiteB, and the user navigates to that SiteB URL, use the pre-fetch instead > of starting a new network load." > > If my understanding is correct, then there are implications for link > decoration tracking. From my side I'm pointing out that there might be a spec problem. I don't quite see how we could support `<link rel="prefetch" href="resource-in-next-page">` and `<link rel="prefetch" href="document-for-top-nav">` using the same format for the cross-origin case. Is it possible to confirm this with the spec owners?