Part of this is a backout of bug 1421054 which is no longer needed now
that we can assume equivalent clip items have identical pointer values.
MozReview-Commit-ID: BhnLVmVr4TX
--HG--
extra : rebase_source : b9bbb733fc69a0f15cd35d0265589aea257a5285
See the documentation in the added function for details.
MozReview-Commit-ID: 4R0WaSy0tm2
--HG--
extra : rebase_source : f6bcdafb708f9527afafab54e3ba7e34040054b0
When a clip is defined in WebRender, any transforms on the containing
stacking contexts are baked into the clip's position. Therefore, trying
to use a clip that was defined inside a transformed stacking context in
other parts of the WR display list doesn't work properly. This was a
latent bug in ScrollingLayersHelper that was previously not exposed
because in these cases Gecko itself creates separate
DisplayItemClipChain items. Now that we are going to deduplicate those
DisplayItemClipChain items, it exposes this latent bug which we need to
fix.
MozReview-Commit-ID: Icd7L1JuY8s
--HG--
extra : rebase_source : 08749125b68b537244a054d00a41f671670d00bb
The system binutils and gcc are built with that option on Debian, but
not on CentOS. That makes no practical difference, except for the fact
that when building GCC, we use our own-built binutils (as per bug
1427316), but use the system GCC. And a GCC built with --with-sysroot=/
doesn't work with a binutils built without. However, a GCC built without
--with-sysroot=/ works fine with a binutils built with it. So this
change is compatible with building our GCC on both CentOS and Debian.
This adds a test where we have a ServiceWorker return 2 different types
of streams that Firefox recognizes as downloads which are handled by
diversion of the channel to the parent. The diverted downloads are
then cancelled and we verify that cancellation actually results in the
underlying connections being closed and/or the ServiceWorker notified.
Our 2 types of streams are:
1. A pass-through stream that is incrementally delivered through use of
an .sjs file that delivers data using setInterval.
2. A SW-authored ReadableStream (which is not enabled by default, so we
set a pref.)
Determining when the .sjs's stream is canceled is accomplished by
opening a second "monitor" connection that only completes when the
streaming connection is closed.
In all cases we differentiate between cancelation and timeouts firing.
--HG--
extra : rebase_source : bee2d8ae5dedfb88c1bb8fa5cf452014d74afaed
Currently, FetchStreamReader never signals to the JS stream code that
the reader has been closed. This means that when a ServiceWorker
passes a ReadableStream to respondWith and the HTTP Channel gets
canceled, the JS code will keep generating the stream without ever
realizing the data's not going anywhere. It's necessary to cancel
the reader. Or do something like that, this seems to work!
--HG--
extra : rebase_source : 559af90ba766ebd4deb5d99b6696cd2207215f9f
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
The SyntheticDiversionListener needs to handle the case where the IPC
connection is gone. This patch avoids calling Send* methods which will
crash the content process if the actor has already been destroyed.
Additionally, OnDataAvailable will return an error in such a case so
that the caller can properly handle the error rather than continuing to
attempt to send data to a listener that doesn't care. This latter
change is an artifact of a previous hack attempt to fix a related
diversion issue that is probably not required for this stack, but makes
sense as a fix, so I've left it in.
--HG--
extra : rebase_source : 824d4ab64e92ebb04d8d1ecd4df6d03a2cb37d2f
The diversion mechanism never expected to be dealing with data sourced
from the content process, but that's exactly what happens with
ServiceWorker-intercepted channels with the current child-intercept
situation (which is being fixed).
In order to allow timely cancellation of diverted intercepted
channels, there needs to be a way to relay to the HttpChannelChild
that it needs to be canceled so that the synthesized pump can be
canceled and diversion can be marked as complete. This patch adds
such a mechanism to ADivertableParentChannel and PHttpChannel for the
exclusive use of InterceptedHttpChannel and then uses it.
--HG--
extra : rebase_source : 59d3aa5e541d2a404c6320ae9fce03e7c9cd8b81
Diversion for intercepted channels with a synthesized response is a
special case. It is not appropriate to send DivertComplete when
mEventQ has been drained, because we are not dealing with the usual
mEventQ-enqueued OnDataAvailable payloads that had been received over
the network and sent down to the child. In this case, all the data
originates in the child and does not go through mEventQ. As such,
the correct place to send DivertComplete is at OnStopComplete for the
synthesized response.
--HG--
extra : rebase_source : 2209c25ad6f2b5655728d8dc07ef7f8b64df6ea6
ffxbld
Brindusan Cristian
Johan Lorenzo
Geoffrey Sneddon
shindli
Emilio Cobos Álvarez
Kartikaya Gupta
jj.evelyn@gmail.com
Prathiksha
Andreea Pavel
Mike Hommey
Andrew Sutherland
Ben Kelly
Sebastian Hengst
Jeff Gilbert
Florian Quèze
Coroiu Cristina