Open
Bug 1418457
Opened 7 years ago
Updated 2 years ago
propagate the internal error code from Response to the outer intercepted channel
Categories
(Core :: DOM: Service Workers, enhancement, P3)
Tracking
()
NEW
People
(Reporter: bkelly, Unassigned)
References
(Blocks 2 open bugs)
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.
Updated•7 years ago
|
Priority: -- → P2
Reporter | ||
Comment 1•7 years ago
|
||
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•7 years ago
|
Priority: P2 → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•