This is unused in mozilla-central but still used by comm-central.
The only consumer of this API really just wants the URL strings, so
we return a sequence<DOMString> instead of an array of nsIURI objects.
MozReview-Commit-ID: ITcEe42shHw
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 : 255ea1b97d632363d7465d6d116a8c37dcca85c3
extra : source : 840a6e04bcea7d87e362adf14a37b7c17e20f043
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 : 88952a917c48b9fa7e421f640b7fb57b15cf7d4d
extra : source : 994dc643a2ab62f03fef780a58971b476a4b6f4a
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
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 : 44ee7941be7619a8532c5194eca88fb0ca6323f7
extra : source : 5453b8a58f0c2c28dc7c407c531c266972bff423
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 : db71e927bd1837c6a67f6d56df52cfbb7294df73
extra : source : d156f6b687e1cd8717bf813ab1b944e87b67ed5d
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 : a4e1593d38629173b829014a3c316ad156094580
extra : source : 714d3942fb10a96e60e14c475e24e640b9ddd8cc
One of the last remaining differences when building Firefox on Debian
with all the changes we've done so far is that linking against the
system libc statically links some CRT objects. This causes massive
differences in the resulting binaries because of slight differences
in those objects (because they weren't compiled with the same compiler
and because they're not for the exact same glibc version)
In practice, their content difference don't cause any problem. If they
did, we wouldn't be able to run our builds on newer systems than those
we build them on. The only hypothetical risk would be to run on systems
with a glibc older than Debian 7's, but those already can't run Firefox
anyways (those systems don't have Gtk+3, which is a system requirement).
AFAICT, this is only an hypothetical problem anyways, even such systems
with Gtk+3 should be able to run those builds. Plus, this is a change
that will happen anyways when switching to Debian-based build images,
since they would be using the CRT objects from there. We're merely
making it happen earlier so that the differences from switching to
Debian-based build images are more tractable.
Note we only do this when building GCC on Debian, allowing to roll back
to CentOS-based toolchains by just switching back the toolchain jobs to
use the desktop-build docker image again.
When building on Debian (which we now are), this means we enable
.init_array/.fini_array.
When building on CentOS, this means no change. Which implies we could
roll back to CentOS-based toolchains by just switching back the
toolchain jobs to use the desktop-build docker image again.
This change causes massive differences in the resulting binaries because
of the offset differences, but practically speaking, there is no
difference. .init_array/.fini_array have been supported in glibc for 18
years.
... except libdmg-hfsplus. RedHat decided to patch libbz2 to have a
different soname, so a binary built on Debian can't run on
RedHat/CentOS. Ironically, a binary built on RedHat/CentOS can run
on Debian. While we could use some tricks to make libdmg-hfsplus built
on Debian work, at this point, it's not worth the effort. We can live
with libdmg-hfsplus being built on CentOS until the builds that use it
switch to Debian, which is imminent.
... and except mingw32-nsis. Sourceforce renewed their certificate last
week and somehow the corresponding CA is not yet recognized by the
ca-certificates in Debian wheezy (an update is underway but see below)
... and except wine, because it requires more 32-bits packages than can
be installed on the toolchain-build docker image. But all things
considered, the mingw32 builds don't need to be using the same docker
images as the linux builds, and they could be, like the android builds,
be based on a more recent build image. So the corresponding toolchains
can be built on a more recent version of Debian too.
Consequently, we keep all the mingw32 related toolchains on the
desktop-build image for now.
This moves the Safe Browsing notification banner into its own object, makes it aware of the current base domain,
and adds a function that's called when the location changes to determine if it should dismiss or not.
MozReview-Commit-ID: 31JQ4dUyFb4
--HG--
extra : rebase_source : e6d6589b0eef2d132fa355d4a6b36d2c429004af
extra : histedit_source : e385d8d7b609985ff29d8c9ff2d9ed55fc58bb85%2Ce8fb5de30938510a2b5d6a709b051e754a9ebc54
