propagate the internal error code from Response to the outer intercepted channel

NEW
Unassigned

Status

()

enhancement
P3
normal
a year ago
a year ago

People

(Reporter: bkelly, Unassigned)

Tracking

(Blocks 2 bugs)

57 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Bug 1416842 adds the ability to track the internal nsresult error code on failed Response objects.  We should consider propagating this error through respondWith() back to the outer intercepted channel.  This would allow the browser to show something like a "could not find the server" error page instead of a corrupted content page when a pass through fetch fails.

We may also want to consider as part of this whether we need to store the error code in Cache API.
Priority: -- → P2
I looked at this briefly today and yesterday.  Unfortunately in the case of a service worker we *must* reject the promise with a TypeError since we can't know if it will be handled by content script or not.  What we could do, though, is add an internal nsresult to the js TypeError object and look for that in RespondWithHandler::RejectedCallback().  If we got an internal error (maybe from a fixed list of allowed values), then we synthesize that on the outer channel.
(Reporter)

Updated

a year ago
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.