filter.error is "Invalid request ID" instead of "Channel redirected" for redirected document requests
Categories
(WebExtensions :: Request Handling, defect, P3)
Tracking
(Not tracked)
People
(Reporter: robwu, Unassigned)
References
Details
As a design decision, we decided at some point that StreamFilters (from the webRequest.filterResponseData extension API) should be closed upon redirects.
That usually goes through https://searchfox.org/mozilla-central/rev/8698fade12984b9a6a43a85a287a5f17e8fd4ddf/toolkit/components/extensions/webrequest/StreamFilterParent.cpp#488,493-502
In bug 1683189, I showed that redirects (and cancellations) of document requests were handled differently: requests to attach a StreamFilter are deferred until nsHttpChannel::CallOnStartRequest (which is not reached in several cases, including redirects and cancellations). I fixed that bug by explicitly rejecting the promise from nsHttpChannel::ReleaseListeners. In any case, StreamFilterParent::OnStartRequest is not called and the cancellation-by-redirect is not detected.
We need to ensure that if the request is cancelled via nsHttpChannel::ReleaseListeners, that the error message becomes something more sensible. Either "Channel redirected" if possible, or something like "Channel closed before response has been received". Invalid request ID is not an accurate description of the error condition here.
The patch from bug 1683189 has unit tests with a TODO referencing this bug.
| Reporter | ||
Updated•5 years ago
|
Description
•