The whole function doesn't have much sense.
I killed its only DOM use in bug 1427511.
Now it only has two callers in nsCSSFrameConstructor, which basically only want
to know whether the children of the same node can have different flattened tree
parents.
So let's check that directly instead (checking whether the element has a binding
or a shadow root), and simplify a bit other surrounding code while at it.
Leave the XUL popup / menubar code doing the broken thing they were doing
beforehand, because it doesn't look to me like it's trivial to fix... They're
effectively assuming that the children of the menupopup end up in a single
insertion point, which is true, but doesn't need to be.
Maybe they should walk the DOM tree? Don't want to dig into that right now,
since XUL insertion points can be reordered and all that... Not fun.
MozReview-Commit-ID: L4lspkxKENr
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
/builds/worker/workspace/build/src/layout/xul/nsMenuFrame.cpp r=backout a=backout on a CLOSED TREE
--HG--
extra : amend_source : e09bf154093728898ad2c27dd185108f9ff3b009
Prathiksha
Oriol Brufau
Scott Wu
abhinav
Emilio Cobos Álvarez
Andreea Pavel
Mike Hommey
Andrew Sutherland
Ben Kelly
Sebastian Hengst
Jeff Gilbert
Florian Quèze
Coroiu Cristina
arthur.iakab
ffxbld
Ryan VanderMeulen
Johan Lorenzo
Jorg K
Tiberius Oros
Myk Melez