This removes the most verbose fetch related warnings. Cumulatively these
account for about 11,000 warnings during testing.
--HG--
extra : rebase_source : ee930dec1e18b9a7f34d5c66944dc015be10be69
In the scenario where a ServiceWorker returns a pass-through fetch via
`evt.respondWith(fetch("underlying"))`, in order for the "underlying"
HTTP channel to be canceled when the outer HTTP channel is canceled,
FetchDriver's OnDataAvailable method needs to return an error when
the output pipe experiences an error.
Unfortunately, the contract for ReadSegments is effectively that it
returns NS_OK regardless of what the rv of the write handler returned,
so relying on the returned rv is insufficient. And because various
Write*() methods will all fast-path to returning NS_OK if a count of 0
is passed, it's necessary to infer a closed/broken pipe by noticing
that we tried to write more than 0 bytes of data but 0 bytes were
written. (This is safe because the pipe we write into was created
by FetchDriver::OnStartRequest which explicitly creates an infinite
pipe, so it's not possible for the write to fail due to lack of space
in the pipe.)
--HG--
extra : rebase_source : 0a1f9f7a4c244934ff255a07e78608c8ea6fef0e
extra : source : 8e4fd74e7f5e69df7363bdb560f79dde347ce082
In the scenario where a ServiceWorker returns a pass-through fetch via
`evt.respondWith(fetch("underlying"))`, in order for the "underlying"
HTTP channel to be canceled when the outer HTTP channel is canceled,
FetchDriver's OnDataAvailable method needs to return an error when
the output pipe experiences an error.
Unfortunately, the contract for ReadSegments is effectively that it
returns NS_OK regardless of what the rv of the write handler returned,
so relying on the returned rv is insufficient. And because various
Write*() methods will all fast-path to returning NS_OK if a count of 0
is passed, it's necessary to infer a closed/broken pipe by noticing
that we tried to write more than 0 bytes of data but 0 bytes were
written. (This is safe because the pipe we write into was created
by FetchDriver::OnStartRequest which explicitly creates an infinite
pipe, so it's not possible for the write to fail due to lack of space
in the pipe.)
--HG--
extra : rebase_source : 788dab679298841fc03bb054458b6f8cc4a0a8d9
Using nsMainThreadPtrHandle to hold the nsICacheInfoChannel in the
InternalResponse.
--HG--
extra : histedit_source : 125f31c63fce1cbd9995d29688e7795efad3a417
Setting the InternalResponse's mCacheInfoChannel while needed, to avoid
keeping unnecessary nsICacheInfoChannel alive.
--HG--
extra : histedit_source : 39f9339b69db52b0278495d5247bc99ffd1d8f79
Create a new class AlternativeDataStreamListener for alternative data and
main data overlap loading.
AlternativeDataStreamListener coorperates with FetchDriver to handle
following situations
1. There is no preferred alternative data type in InternalRequest
Directly using FetchDriver to listen on the opened channel
2. If preferred alternative data type exists in InternalRequest, but no
saved data in cache.
AlternativeDataStreamListener is constructed to listen on the channel,
but its status would be set as FALLBACK and redirect callbacks to
FetchDriver.
3. If preferred alternative data type exists in InternalRequest, and the
data also exists in the cache.
AlternativeDataStreamListener is constructed to listen on the channel
for loading the alternative data. And also open a channel listened by
FetchDriver for loading the main data when AlternativeDataStreamListener::
OnStartRequest is called.
If the cacheEntryId is different between main data channel and
alternative data channel, we will cancel the alternative data loading.
The included test crashes without the included fix if run with --disable-e10s.
e10s doesn't crash because HttpChannelChild examines the return value of the
call to the listener's OnStartRequest method and invokes Cancel() if it
NS_FAILED. This is a divergence between e10s and non-e10s. See the bug for
more details and discussion.
--HG--
extra : rebase_source : 9da386b0f1c0b349728170b301f62b0175c2c571
If the Fetch request is created by a tracking script, we want to lower the priority of the http channel.
--HG--
extra : rebase_source : fc258770a2f58a503777dec8a05fd2aeab2ff889
Raise the urgent-start flag in the ClassOfService when the Fetch and XHR are
triggered by user input events. The urgent-start classification will tell the
network requests scheduler to perform it with the highest priority and also
ignoring any parallelism or overall connection limits.
MozReview-Commit-ID: 2YavWbuFaln
--HG--
extra : rebase_source : 40f41d1a4b9e323c0cf5710c6d5f2a1e45e93076
