Highly compressed brotli files contain meta blocks that don't produce
output from the first 512 Bytes. That is because the meta block header
might be longer than 512 Bytes.[1] NBLTYPESL, NBLTYPESI, NBLTYPESD,
NTREESL, NTREESD all can blow up the header size. Each at least by
2*256 bits.
With this solution the Content-Type would be always detected as
`octet-stream`. That might not be the correct one. If a different
Content-Type is required, the server can still specify it with the
`Content-Type`-Header.[2]
This solution looks directly at the error code to determine invalid
encoding instead of relying on number of output bytes.
This also doesn't throw an error anymore for truncated brotli documents
that don't produce any output. But since we generally allow truncated
formats[3], it makes the implementation a bit more consistent.
[1]: https://www.rfc-editor.org/rfc/rfc7932#section-9.2
[2]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1242904#c4
Differential Revision: https://phabricator.services.mozilla.com/D175460
Now that we've simplified the startup process somewhat, it is easier to clean
up IPC channel creation for NodeChannel connections. This stops having
GeckoChildProcessHost inherit from IPC::Channel::Listener, as it would never
receive most of the relevant callbacks, and instead implements the one callback
it would receive directly as a method on that type.
Differential Revision: https://phabricator.services.mozilla.com/D181282
This patch has three parts to it:
1) Use NS_IsContentAccessibleAboutURI to ensure that only safe
about: documents get exempted.
With this change, we will no longer allow about:blank or
about:srcdoc to be exempted base on URI. If they are to be
exempted, it will need to be base on other information.
2) In Document::RecomputeResistFingerprinting we previously
deferred to a Parent Document if we had one, and either the
principals matched or we were a null principal.
We will do the same thing, except we will also defer to our
opener as well as the parent document. Now about:blank
documents can be exempted.
However, this deferral only works if the opener is
same-process. For cross-process openers, we make the decision
ourselves.
We can make the wrong decision though. CookieJarSettings is
inherited through iframes but it is _not_ inherited through popups.
(Yet. There's some discussion there, but it's not implemented.)
Conceptually; however, we do want CJS to inherit, and we do want
RFP to inherit as well. Because a popup can collude with its
opener to bypass RFP and Storage restrictions, we should propagate
the CJS information.
This does lead to an unusual situation: if you have exempted
b.com, and a.com (which is not exempted) creates a popup for b.com
then that popup will not be exempted. But an open tab for b.com
would be. And it might be hard to tell those two apart, or why
they behave differently.
The third part of the patch:
3) In LoadInfo we want to populate information down from the
opener to the popup. This is needed because otherwise a
cross-origin popup will not defer to its opener (because in
Fission they're in different processes) and will decide if
it should be exempted itself. It's the CookieJarSettings
object that prevents the cross-origin document from thinking
it should be exempted - CJS tells it 'No, you're a child
(either a subdocument or a popup) and if I say you don't get
an exemption, you don't.'
Finally, there is one more caveat: we can only defer to a parent
document or opener if it still exists. A popup may outlive its
opener. If that happens, and something induces a call to
RecomputeResistFingerprinting, then (e.g.) an about:blank popup
may lose an RFP exemption that it had received from its parent.
This isn't expected to happen in practice -
RecomputeResistFingerprinting is only called on document creation
and pref changes I believe.
It is not possible for a popup to _gain_ an exemption though,
because even if the parent document is gone, the CJS lives on and
restricts it.
Differential Revision: https://phabricator.services.mozilla.com/D178866
gMock objects cannot be reused after they receive calls to the mocked functions. This patch changes the test to establish all of the mock expectations upfront for each network-change notification before running it. It uses gMock Sequence objects and a checkpoint to maintain (partial) temporal order.
Differential Revision: https://phabricator.services.mozilla.com/D180622
This patch has three parts to it:
1) Use NS_IsContentAccessibleAboutURI to ensure that only safe
about: documents get exempted.
With this change, we will no longer allow about:blank or
about:srcdoc to be exempted base on URI. If they are to be
exempted, it will need to be base on other information.
2) In Document::RecomputeResistFingerprinting we previously
deferred to a Parent Document if we had one, and either the
principals matched or we were a null principal.
We will do the same thing, except we will also defer to our
opener as well as the parent document. Now about:blank
documents can be exempted.
However, this deferral only works if the opener is
same-process. For cross-process openers, we make the decision
ourselves.
We can make the wrong decision though. CookieJarSettings is
inherited through iframes but it is _not_ inherited through popups.
(Yet. There's some discussion there, but it's not implemented.)
Conceptually; however, we do want CJS to inherit, and we do want
RFP to inherit as well. Because a popup can collude with its
opener to bypass RFP and Storage restrictions, we should propagate
the CJS information.
This does lead to an unusual situation: if you have exempted
b.com, and a.com (which is not exempted) creates a popup for b.com
then that popup will not be exempted. But an open tab for b.com
would be. And it might be hard to tell those two apart, or why
they behave differently.
The third part of the patch:
3) In LoadInfo we want to populate information down from the
opener to the popup. This is needed because otherwise a
cross-origin popup will not defer to its opener (because in
Fission they're in different processes) and will decide if
it should be exempted itself. It's the CookieJarSettings
object that prevents the cross-origin document from thinking
it should be exempted - CJS tells it 'No, you're a child
(either a subdocument or a popup) and if I say you don't get
an exemption, you don't.'
Finally, there is one more caveat: we can only defer to a parent
document or opener if it still exists. A popup may outlive its
opener. If that happens, and something induces a call to
RecomputeResistFingerprinting, then (e.g.) an about:blank popup
may lose an RFP exemption that it had received from its parent.
This isn't expected to happen in practice -
RecomputeResistFingerprinting is only called on document creation
and pref changes I believe.
It is not possible for a popup to _gain_ an exemption though,
because even if the parent document is gone, the CJS lives on and
restricts it.
Differential Revision: https://phabricator.services.mozilla.com/D178866
The aEarlyHintPreloaderId parameter for StartLoad/StartLoadInternal is changed
to be a member variable of ScriptLoadRequest instead so that an initiator type
of early hints can be set for module requests. Before, ModuleLoader would always
pass in a zero value for the id since ModuleLoaderBase has no concept of early
hints when it calls StartFetch.
As a prerequisite for early hints support, this commit also implements
modulepreload in link headers (Bug 1773056).
Differential Revision: https://phabricator.services.mozilla.com/D180020
There is no implicit conversion for scoped enums, so using them without
an explicit conversion in varargs functions is undefined behavior. GCC
has had a warning about this for a long while, but clang only gained
this a few days ago on trunk.
Differential Revision: https://phabricator.services.mozilla.com/D181723
First, instead of using a path, use a version, which is more convenient
(via a patch in the top-level Cargo.toml).
Second, we make the build system itself enforce its presence for any
crate that is hooked to the build system as a program or library.
Finally, for each crate depending on the workspace hack, we add a
feature named after it, and make the build system enforce that the
feature is set. For now, this remains unused, but the end goal is to
have each of those features enable the dependencies each of these
crates need, so that if crate A and B need dependency D, but crate C
doesn't, building crate C doesn't build D.
Differential Revision: https://phabricator.services.mozilla.com/D180910
This patch has three parts to it:
1) Use NS_IsContentAccessibleAboutURI to ensure that only safe
about: documents get exempted.
With this change, we will no longer allow about:blank or
about:srcdoc to be exempted base on URI. If they are to be
exempted, it will need to be base on other information.
2) In Document::RecomputeResistFingerprinting we previously
deferred to a Parent Document if we had one, and either the
principals matched or we were a null principal.
We will do the same thing, except we will also defer to our
opener as well as the parent document. Now about:blank
documents can be exempted.
However, this deferral only works if the opener is
same-process. For cross-process openers, we make the decision
ourselves.
We can make the wrong decision though. CookieJarSettings is
inherited through iframes but it is _not_ inherited through popups.
(Yet. There's some discussion there, but it's not implemented.)
Conceptually; however, we do want CJS to inherit, and we do want
RFP to inherit as well. Because a popup can collude with its
opener to bypass RFP and Storage restrictions, we should propagate
the CJS information.
This does lead to an unusual situation: if you have exempted
b.com, and a.com (which is not exempted) creates a popup for b.com
then that popup will not be exempted. But an open tab for b.com
would be. And it might be hard to tell those two apart, or why
they behave differently.
The third part of the patch:
3) In LoadInfo we want to populate information down from the
opener to the popup. This is needed because otherwise a
cross-origin popup will not defer to its opener (because in
Fission they're in different processes) and will decide if
it should be exempted itself. It's the CookieJarSettings
object that prevents the cross-origin document from thinking
it should be exempted - CJS tells it 'No, you're a child
(either a subdocument or a popup) and if I say you don't get
an exemption, you don't.'
Finally, there is one more caveat: we can only defer to a parent
document or opener if it still exists. A popup may outlive its
opener. If that happens, and something induces a call to
RecomputeResistFingerprinting, then (e.g.) an about:blank popup
may lose an RFP exemption that it had received from its parent.
This isn't expected to happen in practice -
RecomputeResistFingerprinting is only called on document creation
and pref changes I believe.
It is not possible for a popup to _gain_ an exemption though,
because even if the parent document is gone, the CJS lives on and
restricts it.
Differential Revision: https://phabricator.services.mozilla.com/D178866