This patch splits FontTableURI and BlobURL in 2 classes:
FontTableURIProtocolHandler and BlobURLProtocolHandler
both under mozilla::dom.
It also removes a memory reporter because that report is already covered by the
BlobURL one.
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
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.)
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.)
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.
