While trying to repro bug 1484293 I noticed that this assertion failed:
https://searchfox.org/mozilla-central/rev/ef8b3886cb173d5534b954b6fb7eb2d94a9473d0/dom/base/ShadowRoot.cpp#160
(during unlink, while unbinding the kids)
We rely on GetComposedDoc returning the right thing during unbind to cleanup
some stuff (see bug 1473637 for example), so it should probably be correct all
the time, regardless of whether something is unlinked or not.
Also this makes GetComposedDoc() much faster, which is nice too, since we call
it somewhat often.
I removed NodeHasRelevantHoverRules, since it's unused (was used by the old
style system).
I moved the SetIsConnected(false) call for the shadow root to before unbinding
the kids for consistency with what Element does with the uncomposed doc flag,
now that the children's connectedness doesn't depend on the shadow root's.
Differential Revision: https://phabricator.services.mozilla.com/D3715
--HG--
extra : moz-landing-system : lando
This is slow to do when the element isn't visible, and we know it
won't have a XBL binding anyway, since it's a Custom Element.
Differential Revision: https://phabricator.services.mozilla.com/D3539
--HG--
extra : moz-landing-system : lando
This change also renames several related functions, as well as fields,
and the header is moved into EXPORTS.mozilla given it is defined under
mozilla namespace.
MozReview-Commit-ID: LqCdcW8fmUN
--HG--
rename : layout/base/ScrollbarStyles.cpp => layout/base/ScrollStyles.cpp
rename : layout/base/ScrollbarStyles.h => layout/base/ScrollStyles.h
extra : rebase_source : 8933f3bca88d5db4b9508e3947f695ecf7511b3e
Mostly automatic via sed. Only parts which I touched manually (apart from a
couple ones where I fixed indentation or which had mispelled arguments) are the
callers. I may have removed a couple redundant `virtual` keywords as well when
I started to do it manually, I can revert those if wanted.
Most of them are just removing the argument, but in Element.cpp I also added an
assertion for GetBindingParent when binding the ShadowRoot's kids (the binding
parent is set from the ShadowRoot constructor, and I don't think we bind a
shadow tree during unlink or what not which could cause a behavior difference).
Differential Revision: https://phabricator.services.mozilla.com/D2574
MozReview-Commit-ID: 2oIgatty2HU
Only remove from the table when we're actually disconnecting the
element from the shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D2092
MozReview-Commit-ID: 1Ubdz57PNc0
Summary:
document.addEventListener("shadowrootattached", e => {
// Do stuff with composedTarget.
});
I didn't bother to add tests for the event itself since this is going to get
tested in bug 1449333, but I can look into writing a chrome mochitest if you
want.
Test Plan: See above.
Reviewers: smaug
Bug #: 1470545
Differential Revision: https://phabricator.services.mozilla.com/D1777
MozReview-Commit-ID: 55cVMSsznMS
The idea with this patch is that style code will first call
InlineStyleDeclarationWillChange before style declaration has changed, and SetInlineStyleDeclaration once it has changed.
In order to be able to report old attribute value, InlineStyleDeclarationWillChange reads the value and also calls AttributeWillChange (so that DOMMutationObserser can grab the old value). Later SetInlineStyleDeclaration passes the old value to
SetAttrAndNotify so that mutation events and attributeChanged callbacks are handled correctly.
Because of performance, declaration can't be cloned for reading the old value. And that is why the recently-added callback is used to detect when declaration is about to change (bug 1466963 and followup bug 1468665).
To keep the expected existing behavior, even if declaration isn't changed, but just a new declaration was created (since there wasn't any), we need to still run all these
willchange/set calls. That is when the code has 'if (created)' checks.
Since there are several declaration implementation and only nsDOMCSSAttributeDeclaration needs the about-to-change callback, GetPropertyChangeClosure is the one to initialize the callback closure, and the struct which is then passes as data to the closure.
Apparently we lost mutation event testing on style attribute when the pref was added, so test_style_attr_listener.html is modified to test both pref values.
--HG--
extra : rebase_source : 9e605d43f22e650ac3912fbfb41abb8d5a2a0c8f
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
This patch puts the transformed pretty print DOM into a Shadow DOM.
The stylesheet is loaded with an @import in a <style> block, so the
monospace stylesheet had to be left out.
The XBL binding is kept, pending removal when Shadow DOM ships.
It's still needed to handle the case when Shadow DOM is pref'd off too.
MozReview-Commit-ID: DQRsXB8tumF
--HG--
extra : rebase_source : 6edc3d82392af4d98de454a5228328379a0fb7ee
We relied already in DestroyContent not fiddling with child lists, so added
assertions to that effect.
The GetChildCount comment in UnbindSubtree looks outdated (there's no
GetChildCount impl which does anything like creating children).
MozReview-Commit-ID: 6UXVbT6Urgt
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
The last remaining user is already turned off and being removed
in bug 1444395 so that we can finally remove this unsafe code and
sleep a little better knowing that XSS through markup injections
will be impossible in chrome contexts.
MozReview-Commit-ID: KcZq8fRPiD4
--HG--
extra : rebase_source : 5def3abb50ed8f1b43e17072088e38a44394488b
Currently, NAC always inherits from the closest non-NAC ancestor element,
regardless of whether it is for an element-backed pseudo or not.
This patch changes the inheritance so that for element-backed pseudos, we
inherit from the closest native anonymous root's parent, and for other NAC we
inherit from the parent.
This prevents the following two issues and allows us to remove the
NODE_IS_NATIVE_ANONYMOUS flag:
* Avoiding inheriting from the non-NAC ancestor in XBL bindings bound to NAC.
- This is no longer a problem since we apply the rule only if we're a
pseudo-element, and all pseudo-elements are in native anonymous subtrees.
- This also allows to remove the hack that propagates the
NODE_IS_NATIVE_ANONYMOUS flag from the ::cue pseudo-element from
BindToTree.
* Inheriting from the wrong thing if we're a nested NAC subtree.
- We no longer look past our NAC subtree, with the exception of
::-moz-number-text's pseudo-elements, for which we do want to propagate
::placeholder to.
A few rules from forms.css have been modified because they're useless or needed
to propagate stuff to the anonymous form control in input[type="number"] which
previously inherited from the input itself.
MozReview-Commit-ID: IDKYt3EJtSH
Consider the test-case where we have:
<div>
<span id=a />
<span id=b />
</div>
We try to set one bit on "a", and a different one on "b".
Ideally we'll end up with <div> as the root with both bits. But with the current
code we'd go all the way to the document unnecessarily. This fixes it by
checking the bits we've propagated up to the top instead of existingBits.
MozReview-Commit-ID: GfwjwCBpkuy
This patch enables us to specify a custom element type with |is| attribute
or property when creating a XUL element. Because non-dashed names are valid
custom element names in XUL (bug 1446247), other checks has to modified
accordingly.
The checks I am settling with are
1) Forbids the custom built-in element names to be a non-dashed name.
2) Forbids the custom built-in element to extend a dashed built-in element name.
This also ensures the custom built-in element types don't take on the same
name as the element name it extends.
MozReview-Commit-ID: GCQ9RnfvvrC
--HG--
extra : rebase_source : 2fa13742525d2107580d50872ff5b0fc42539498
extra : source : 2dc5513660d78a4de4801109140743ffc9297f71
By doing this we will have all the KeyframeEffect* related code in
KeyframeEffectReadOnly.{h,cpp} so we can rename them to KeyframeEffect.{h,cpp}
in the next patch and make it easier to examine the history for the bulk of this
code.
The added [HeaderFile] annotation will be removed in a subsequent patch in this
series.
MozReview-Commit-ID: Fxk6fPukgAS
--HG--
extra : rebase_source : 0bb0f846aba69e2b79724adb3148948317667eae
This will make it possible to migrate existing bindings without also needing to
mass-rewrite frontend code at the same time.
MozReview-Commit-ID: IBBqC4eeDDX
--HG--
extra : rebase_source : e901ac665208b3a683668c1bb33a26dcf479580c
This is mostly code removal, changing GetDisplayContentsStyle(..) checks by an
FFI call to Servo.
The tricky parts are:
* MaybeCreateLazily, which I fixed to avoid setting bits under display: none
stuff. This was a pre-existing problem, which was wallpapered by the
sc->IsInDisplayNoneSubtree() check, which effectively made the whole
assertion useless (see bug 1381017 for the only crashtest that hit this
though).
* ContentRemoved, where we can no longer know for sure whether the element is
actually display: contents if we're removing it as a response to a style
change. See the comment there. That kinda sucks, but that case is relatively
weird, and it's better than adding tons of complexity to handle that.
* GetParentComputedStyle, which also has a comment there. Also, this function
has only one caller now, so we should maybe try to remove it.
The different assertions after DestroyFramesForAndRestyle are changed for a
single assertion in the function itself, and the node bit used as an
optimization to avoid hashtable lookups is taken back.
MozReview-Commit-ID: AZm822QnhF9
And then fix up everything else that needs to change as well.
MozReview-Commit-ID: GDMfERqdQAc
--HG--
extra : rebase_source : 01fe06c3182245a409099a53383d92bf4fa0155c
This will make it possible to migrate existing bindings without also needing to
mass-rewrite frontend code at the same time.
MozReview-Commit-ID: IBBqC4eeDDX
--HG--
extra : rebase_source : e901ac665208b3a683668c1bb33a26dcf479580c
I moved the IgnoreErrors decl so it would come after the OOMReporter decl and I
could add the new conversion operator.
MozReview-Commit-ID: B1S6DXmZfvE
This allows custom elements to work in any document in the parent process that
allows XUL and XBL. The test takes the easy option of moving the existing XUL
custom element test to a run with the custom element pref disabled.
MozReview-Commit-ID: CMiLzmp60jA
--HG--
extra : rebase_source : 735688061116c633b816f4f9d488712408df11a5
extra : source : 794ee6857d83dfe0b18629c12e96a622fc899586
This allows custom elements to work in any document in the parent process that
allows XUL and XBL. The test takes the easy option of moving the existing XUL
custom element test to a run with the custom element pref disabled.
MozReview-Commit-ID: CMiLzmp60jA
--HG--
extra : rebase_source : b9632de82cf79c1df15be09fadf1d25817c8a894
extra : amend_source : 235a76453d1d6782903d5051ee8e234b965dcc36
Summary: It uses two node bits that can be better suited for something else.
Reviewers: xidorn, smaug
Bug #: 1444905
Differential Revision: https://phabricator.services.mozilla.com/D709
MozReview-Commit-ID: HIPDtHm6xpM
If the element has throttled animations that will be affected by pending style
changes, the throttled animations will be updated though sequential tasks after
normal styling process. E.g. UpdateEffectProperties, UpdateCascadeResults etc.
So we don't need to flush them in advance of the sequential tasks.
The first test case in this patch fails without this fix.
MozReview-Commit-ID: GystAqK2bQE
--HG--
extra : rebase_source : c01160e14bb5a2984dcc4d63ec44d4d465b829a2
Unfortunately this means that we need to export a couple more headers, but that
should be ok.
In particular, we have to export some headers that are #included by
nsCSSFrameConstructor.h, because nsCSSFrameConstructor.h itself will now be
included in more places outside of layout/, by .cpp files that don't necessarily
have the ability to indirectly #include its other headers, unless we export
them.
MozReview-Commit-ID: 2n9KHW6Yjrd
More improvements to come. In particular, this still iterates through Shadow DOM
in each_xbl_cascade_data, but that should be changed later. That allows to
cleanup a bunch of stuff and finally fix Shadow DOM cascade order.
We still rely on the binding parent to be setup properly in the shadow tree, but
that requirement can go away later (we can walk the containing shadow chain
instead).
This mostly focuses on removing the XBL binding from the Shadow host.
It'd be nice to do EnumerateShadowRoots faster. I think that should also be a
followup, if needed.
MozReview-Commit-ID: Jf2iGvLC5de
If a single element is inserted in the document, from the lazy frame
construction path we mark it as the restyle root.
It has no restyle data, and we weren't calling ClearServoData when its parent
was being removed from ClearServoDataFromSubtree, thus leaving the stale restyle
root.
MozReview-Commit-ID: GY812b8tDk0
--HG--
extra : rebase_source : e6d1035e7d3a72b931aa53ac8dcbf7db58982479
We used to do it this way effectively until I fixed it in bug 1400936.
Per the list of fuzz bugs that bug has in the "Depends on" field, some of those
without a super-clear fix, and others that aren't listed in there, and all the
complexity we had to deal with while receiving restyle requests mid-unbind, etc,
I think this is the right call.
This clears data on RestyleManager::ContentRemoved for non-anonymous nodes, and
on UnbindFromTree for subtrees rooted at anonymous nodes.
This will hopefully yield enforceable invariants.
MozReview-Commit-ID: IMwX5Uh1apv
--HG--
extra : rebase_source : 6cafc4499c9b80cbc96f1c4d1496e524f59e3c4d
Everyone calls them with the shell of the current composed document, and this
allows the multi-presShell stuff to just be in UpdateCurrentStyleSources /
DoGetStyleContextNoFlush.
The only reason we need to use OwnerDoc()->GetShell() instead of the composed
doc in GetStyleContext / GetStyleContextNoFlush is Element::GetBindingURL, which
does expect to get the binding URL for stuff outside of the composed doc (and
changing that gave me a useless browser).
That's technically a behavior change on the cases that used to pass nullptr, but
I think all callers are fine with that. I could also just add a special function
for that particular case, it may be worth it.
MozReview-Commit-ID: 2XlnkgdgDCK
This was used to attach a binding to a cloned node before it got inserted
into the doc. This is no longer used in the browser chrome, so this patch
removes the feature to prevent future usage and simplify dom code.
MozReview-Commit-ID: KnkHWJ8oQig
--HG--
extra : rebase_source : 52c175afbbfc0cf5cd33c39b6f0577452a90f1a0
It would be convenient to get nsPresContext from nsIDocument.
MozReview-Commit-ID: Ei6V3UE8XGr
--HG--
extra : rebase_source : 8d2a917eb62cf341e4e1810451fd01c01dbc3bad
We used to do it this way effectively until I fixed it in bug 1400936.
Per the list of fuzz bugs that bug has in the "Depends on" field, some of those
without a super-clear fix, and others that aren't listed in there, and all the
complexity we had to deal with while receiving restyle requests mid-unbind, etc,
I think this is the right call.
This clears data on RestyleManager::ContentRemoved for non-anonymous nodes, and
on UnbindFromTree for subtrees rooted at anonymous nodes.
This will hopefully yield enforceable invariants.
MozReview-Commit-ID: IMwX5Uh1apv
KeyframeEffect and KeyframeEffectReadOnly constructors can run in the caller
compartment, which is okay because the current compartment is used in the
following places and all of them are safe:
1. GlobalObject::CallerType(), that is ultimately passed to
nsDocument::IsWebAnimationsEnabled in KeyframeEffectParamsFromUnion,
to decide whether to copy mIterationComposite/mComposite to
KeyframeEffectParams.
GlobalObject::CallerType() can now be different than the target window's one,
if the caller has the system principal and the target is web content, and
in that case nsDocument::IsWebAnimationsEnabled there always returns true
while Web Animations can be disabled on web content.
honoring the mIterationComposite/mComposite properties is OK, since it just
changes the animation behavior, and this is disabled by default until
remaining spec issues are resolved.
2. GlobalObject::Context(), that is ultimately passed to
KeyframeUtils::GetKeyframesFromObject and used while extracting information
from passed-in keyframe object, with iterable/iterator protocols.
Performing that operation in the caller side is okay, since the same thing
can be done on caller, and the operation doesn't perform any GCThing
allocation on the target window global.
KeyframeEffect and KeyframeEffectReadOnly constructors can run in the caller
compartment, which is okay because of the following reasons:
1. The target window global is used for most operation:
* KeyframeEffectReadOnly::ConstructKeyframeEffect uses the target window
global instead of current global.
* KeyframeEffectParamsFromUnion which receives `aGlobal.CallerType()`
In Xray case, Web Animations API can be disabled on web content
(currently disabled on beta/release by default), and in that case some API
won't work even it's triggered from WebExtensions, but it should be fine.
2. GetKeyframesFromObject is executed in the caller's compartment to access
the passed-in JSObject that is keyframe, with iterable/iterator protocols.
This operation doesn't perform any GCThing allocation on the target window
global.
This is a short-term solution to our inability to apply CSP to
chrome-privileged documents.
Ideally, we should be preventing all inline script execution in
chrome-privileged documents, since the reprecussions of XSS in chrome
documents are much worse than in content documents. Unfortunately, that's not
possible in the near term because a) we don't support CSP in system principal
documents at all, and b) we rely heavily on inline JS in our static XUL.
This stop-gap solution at least prevents some of the most common vectors of
XSS attack, by automatically sanitizing any HTML fragment created for a
chrome-privileged document.
MozReview-Commit-ID: 5w17celRFr
--HG--
extra : rebase_source : 1c0a1448a06d5b65e548d9f5362d06cc6d865dbe
extra : amend_source : 7184593019f238b86fd1e261941d8e8286fa4006
Now that accessing nsIContent slots is not a blob of virtual function calls, we
should be able to unify logic here, and speed up the not-so-rare case for
chrome, while keeping the usual case fast.
MozReview-Commit-ID: 87iY5Cbhx4T
Give the compiler the chance to devirtualize / inline a bit more.
MozReview-Commit-ID: D5u2AxaZ7a1
--HG--
extra : rebase_source : e235b8b60322a113f459067e2762ea237cb26ec5
The textarea is inserted under a Shadow host, with no matching insertion point,
so its flattened tree parent node is null.
We're treating this case in the restyle root code as "the parent is the
document", but that's very wrong.
MozReview-Commit-ID: JlzUMRIYaYZ
--HG--
extra : rebase_source : feeaf7a7333097aa87b35358172472790f6c74a7
This is necessary in order to capture the correct triggering principal for
inline <style> nodes.
MozReview-Commit-ID: 9EaD40vRNkH
--HG--
extra : rebase_source : cdd4a730f24dc57783edcf666ae803379c0d6173
This is necessary in order to parse style attributes using the subject
principal of the caller, rather than defaulting to the page principal.
MozReview-Commit-ID: GIshajQ28la
--HG--
extra : rebase_source : 5dba46f61d70ec647cae16383b62961ac72d2f47