This patch removes the static pointer to nsIIOService in nsContentUtils,
replacing it to calls to mozilla::components::IO::Service.
It also makes nsScriptSecurityManager::sIOService a StaticRefPtr.
Differential Revision: https://phabricator.services.mozilla.com/D188714
This makes it cheaper to copy the nsAttrValue, which improves innerHTML times on Speedometer
because it reduces the time spent creating and destroying valueForAfterSetAttr.
It will also make it possible to reuse eAtomArray values across elements.
This patch adds a copying operation in AllocClassMatchingInfo which is needed
now that the MiscContainer's mValue.mAtomArray is immutable. This is a bit
unfortunate: In the past, this was doing one atom array allocation, and now
it's doing two; one during parsing and one during the copy. However, I would
expect that most calls to getElementsByClassName only supply a single class
name and not a set of space-separated class names, but I haven't measured it.
If this copy turns out to make things slower, we can probably avoid it by
adding a way to parse a string into an AtomArray directly without going
through nsAttrValue.
Before: https://share.firefox.dev/3DAhLzm
After: https://share.firefox.dev/456TMTM
Differential Revision: https://phabricator.services.mozilla.com/D183810
This considerably improves the testcase in bug 1834003, because it
reduces the amount of memory we need to look at when checking the
listeners at the nsWindowRoot. At the moment, nsWindowRoot has 156
listeners for 94 different event types, all from JSWindowActor event
listeners.
Having a separate array per event type also matches what Blink and Webkit do.
Differential Revision: https://phabricator.services.mozilla.com/D183431
This considerably improves the testcase in bug 1834003, because it
reduces the amount of memory we need to look at when checking the
listeners at the nsWindowRoot. At the moment, nsWindowRoot has 156
listeners for 94 different event types, all from JSWindowActor event
listeners.
Having a separate array per event type also matches what Blink and Webkit do.
Differential Revision: https://phabricator.services.mozilla.com/D183431
This considerably improves the testcase in bug 1834003, because it
reduces the amount of memory we need to look at when checking the
listeners at the nsWindowRoot. At the moment, nsWindowRoot has 156
listeners for 94 different event types, all from JSWindowActor event
listeners.
Having a separate array per event type also matches what Blink and Webkit do.
Differential Revision: https://phabricator.services.mozilla.com/D183431
Before this patch, we would have called listeners added with both
addEventListener("end", ...) and addEventListener("endEvent", ...).
Now we will just call listeners added with the latter and ignore the
former.
This change only affects listeners added with addEventListener.
For attribute handlers and IDL property listeners, we still use
onbegin/onrepeat/onend as before.
The new behavior matches Blink, simplifies the code, and will let us
improve performance by storing event listeners in a map keyed by event
type atom (bug 1834370).
Differential Revision: https://phabricator.services.mozilla.com/D184532
Before this patch, we would have called listeners added with both
addEventListener("end", ...) and addEventListener("endEvent", ...).
Now we will just call listeners added with the latter and ignore the
former.
This change only affects listeners added with addEventListener.
For attribute handlers and IDL property listeners, we still use
onbegin/onrepeat/onend as before.
The new behavior matches Blink, simplifies the code, and will let us
improve performance by storing event listeners in a map keyed by event
type atom (bug 1834370).
Differential Revision: https://phabricator.services.mozilla.com/D184532
In the blocked bug, this function shows up. Avoid copying the full URI
spec most cases by doing a faster scheme check first.
Differential Revision: https://phabricator.services.mozilla.com/D184269
This code path is in the uncommon case, mostly
applicable to service workers I think. Test Coverage
shows it's not hit in our current suite.
Differential Revision: https://phabricator.services.mozilla.com/D183195
This code path is in the uncommon case, mostly
applicable to service workers I think. Test Coverage
shows it's not hit in our current suite.
Differential Revision: https://phabricator.services.mozilla.com/D183195
The Range header was added as a safe-listed header as long as the value
is in a particular format. Update IsCORSSafelistedRequestHeader
implementations to account for this.
Differential Revision: https://phabricator.services.mozilla.com/D182861
The Range header was added as a safe-listed header as long as the value
is in a particular format. Update IsCORSSafelistedRequestHeader
implementations to account for this.
Differential Revision: https://phabricator.services.mozilla.com/D182861
The Range header was added as a safe-listed header as long as the value
is in a particular format. Update IsCORSSafelistedRequestHeader
implementations to account for this.
Differential Revision: https://phabricator.services.mozilla.com/D182861
The existing function doesn't not work for cases like when mousedown
and mouseup were happened in the same hierarchy but the mousedown target
was a different interactive element than the mouseup target. This
could be easily accomplished by setting `pointer-events: none` or
`display: none` to the `active` pseudo-class of the mousedown target.
This patch fixes this by when the logic tries to find the event target
tree of the mousedown target, it continues building up (by recursively looking
up the parents) the tree instead of stopping at the first interactive element.
Differential Revision: https://phabricator.services.mozilla.com/D178844
I have done my best to figure out what these specific call-sites
actually want to be using, however I do not understand the AntiTracking
implementation. Please look over these callers somewhat carefully to
make sure this is actually the desired behaviour.
It seems like the majority of these cases are in places where
`OriginNoSuffix` has been mixed up with
`GetWebExposedOriginSerialization`. This makes sense, as these will be
identical strings for the majority of web-exposed URLs. The big
differences between the two are with other URL types, like null
principals.
The logic seems somewhat inconsistent about its handling of origin
attributes, which was also confusing when reading through it. I've tried
to align with the existing code when possible.
Differential Revision: https://phabricator.services.mozilla.com/D182226
The existing function doesn't not work for cases like when mousedown
and mouseup were happened in the same hierarchy but the mousedown target
was a different interactive element than the mouseup target. This
could be easily accomplished by setting `pointer-events: none` or
`display: none` to the `active` pseudo-class of the mousedown target.
This patch fixes this by when the logic tries to find the event target
tree of the mousedown target, it continues building up (by recursively looking
up the parents) the tree instead of stopping at the first interactive element.
Differential Revision: https://phabricator.services.mozilla.com/D178844
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
