Closed Bug 1618543 Opened 8 months ago Closed 5 months ago

[rel=preload] Let `fetch()` use "fetch" preloads

Categories

(Core :: DOM: Networking, enhancement, P1)

enhancement

Tracking

()

RESOLVED FIXED
mozilla78
Tracking Status
firefox78 --- fixed

People

(Reporter: mayhemer, Assigned: mayhemer)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

Part of Design documentation for rel=preload

There are two main points to fulfill:

  1. At the place fetch opens its HTTP channel, look for an existing preload in Document.PreloadService using the key as defined in the design doc above. The "as" part of the key shall be "fetch". The exact content for the attributes part of the key is yet to be determined for fetch. If a prelaod is found in the PreloadService, then instead of opening a new channel, use the AsyncConsume method of the preload to get the data. If not, or if AsyncConsume fails, open a new HTTP channel as we do now.
  2. FetchDriver has to implement PreloaderBase and after it opens its HTTP channel, register itself in Document.PreloadService so that later added <link preload> tags get the onload/onerror notifications and don't open a second channel.
    This goes against the finding on how Chrome behaves. A used fetch preload is removed from the preload hash table, following preloads create a new network request.
Component: DOM: Core & HTML → DOM: Networking
Priority: -- → P2
Whiteboard: [necko-triaged]
Assignee: nobody → honzab.moz
Status: NEW → ASSIGNED
Priority: P2 → P1
Blocks: 1637666
Blocks: 1638814
Pushed by honzab.moz@firemni.cz:
https://hg.mozilla.org/integration/autoland/rev/4068b1f7a903
Let `fetch()` use "fetch" preloads, r=baku
Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
You need to log in before you can comment on or make changes to this bug.