1902212 - Refine destination-based fetchpriority mapping of FetchDriver::HttpFetch

Status: NEW

(Core :: Networking, enhancement, P3)

Description

[Frédéric Wang (:fredw)]

This is a follow-up of bug 1881040. I don't plan to work on this on the short term but there are a couple of things that could be improved:

1. Add tests for more destination in fetchpriority-urgency-destination.https.h2.html. /fetch/api/request/destination provides more example, I only included those that currently have an effect (see bug 1855388) but for example I was not able to make tests work for xslt, workers or track destinations.

2. More specialization for mapping from destinations to adjustment preferences. Currently, it is based on CSP directives "font-src", "script-src", "style-src", "img-src" and "media-src" at https://fetch.spec.whatwg.org/#destination-table ; maybe we want to make it more specific (for example https://web.dev/articles/fetch-priority mentions mentions Xslt explicitly for some reason)

  Font => link_preload_font
  Style => link_preload_style
  Script, Audioworklet, Paintworklet, Sharedworker, Worker, Xslt => link_preload_script
  Image => images,
  Audio, Track, Video => media
  other => global_fetch_api

3. Currently, what we are doing is just to apply extra FETCH_PRIORITY_ADJUSTMENT_FOR on top of the intercepted requests which had their own calculated priority. This means the node's priority and the global fetch's priority can be accumulated as shown by the patch below. Is it what we want?

diff --git a/testing/web-platform/mozilla/tests/fetch/fetchpriority/fetchpriority-urgency-destination.https.h2.html b/testing/web-platform/mozilla/tests/fetch/fetchpriority/fetchpriority-urgency-destination.https.h2.html
index 933eba26ca9a8..37e22bc2986ba 100644
--- a/testing/web-platform/mozilla/tests/fetch/fetchpriority/fetchpriority-urgency-destination.https.h2.html
+++ b/testing/web-platform/mozilla/tests/fetch/fetchpriority/fetchpriority-urgency-destination.https.h2.html
@@ -45,6 +45,7 @@
       async function getUrgencyForImage(fetchpriority) {
           let rect = await new Promise((resolve, reject) => {
               let node = frame.contentWindow.document.createElement("img");
+             node.fetchPriority = "high";
               frame.contentWindow.document.body.appendChild(node);
               node.onload = () => {
                   resolve(node.getBoundingClientRect());
@@ -72,6 +73,7 @@
           return await new Promise((resolve, reject) => {
               const resource_id = `script_${fetchpriority}`;
               let node = frame.contentWindow.document.createElement("script");
+             node.fetchPriority = "low";
               node.onload = () => {
                   resolve(frame.contentWindow.scriptUrgency[resource_id]);
               };
@@ -101,6 +103,7 @@
               let div = frame.contentWindow.document.createElement("div");
               div.id = `urgency_square_${resource_id}`;
               node.rel = "stylesheet";
+             node.fetchPriority = "high";
               node.onload = () => {
                   resolve(div.getBoundingClientRect());
               };

4. Currently, a destination can correspond to multiple FETCH_PRIORITY_ADJUSTMENT_FOR. For example scripts have multiple preferences (link_preload_script, module-script, async-or-defer-script, script-in-head, other-script) to decide the priority of the intercepted request, which then has RequestDestination::Script destination and is always adjusted again using the link_preload_script preference. This means that for link preload scripts, a) the default priority ends up being the same as initial request and b) passing a fetchpriority on the global fetch would have the same effect as if the fetchpriority had been set on the <link>. However, it is less clear whether that makes sense for scripts using a preference other than link_preload_script.