This ensures that styles from UA widgets apply. Turns out they look
pretty much right without them, but there's a bug in nsDateTimeBoxFrame
where we rely on the styles in order for the baseline to be sensible.
Differential Revision: https://phabricator.services.mozilla.com/D91616
This ensures that styles from UA widgets apply. Turns out they look
pretty much right without them, but there's a bug in nsDateTimeBoxFrame
where we rely on the styles in order for the baseline to be sensible.
Differential Revision: https://phabricator.services.mozilla.com/D91616
Also, for changes in CSS declarations, like changing
cssRules[i].style.color or something, we end up avoiding a lot of the
work we were doing.
This page still trips us in the sense that they add a stylesheet, then
call getBoundingClientRect(), then insert more rules in the stylesheet,
which causes us to rebuild a lot of the cascade data.
We could try to detect appends to the last stylesheet on the list or
something I guess, and avoid rebuilding the cascade data in some cases.
Depends on D85615
Differential Revision: https://phabricator.services.mozilla.com/D85616
- Remove function `Document::RemoveStyleSheet()`
- Remove function `ShadowRoot::RemoveSheet()`
- Remove function `DocumentOrShadowRoot::RemoveSheet()`, which was used by the former two functions.
- Add function `DocumentOrShadowRoot::RemoveStyleSheet()`, now uesed in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D70927
This also fixes some other bits, like mAdoptedStyleSheets.ElementAt(0) (which
really should be "the first applicable adopted stylesheet") and so on. Added a
test for that.
The new invariant also implies that a DocumentOrShadowRoot can't appear twice in
StyleSheet::mAdopters.
Also clears adopted stylesheets in Document::ResetStylesheetsToURI, as it's the
right thing to do (if you hit that code path with constructable sheets you'd end
up asserting, as we'd call FillStyleSetDocumentSheets after and find sheets in
there). I don't quite have a test-case for that though.
Differential Revision: https://phabricator.services.mozilla.com/D64151
This also fixes some other bits, like mAdoptedStyleSheets.ElementAt(0) (which
really should be "the first applicable adopted stylesheet") and so on. Added a
test for that.
The new invariant also implies that a DocumentOrShadowRoot can't appear twice in
StyleSheet::mAdopters.
Also clears adopted stylesheets in Document::ResetStylesheetsToURI, as it's the
right thing to do (if you hit that code path with constructable sheets you'd end
up asserting, as we'd call FillStyleSetDocumentSheets after and find sheets in
there). I don't quite have a test-case for that though.
Differential Revision: https://phabricator.services.mozilla.com/D64151
- Ensure that adopted styles are applied correctly to ShadowRoot
- Ensure that adopted styles are applied correctly to Document
- Add new WPT test cases to ensure the ordering of the styles.
Differential Revision: https://phabricator.services.mozilla.com/D60083
They do the same so no reason to have it duplicated. EnsureDOMStyleSheets
doesn't have any other caller so just inline it there.
Differential Revision: https://phabricator.services.mozilla.com/D56986
Have their own notification for when the child sheet loads instead of
piggy-backing in the RuleAdded one, and make the callers check instead.
This prevents incorrectly marking as modified sheets which only have @import
rules.
Differential Revision: https://phabricator.services.mozilla.com/D55184
This penalizes a bit non-shadow-DOM content, in exchange of making Shadow DOM
slightly faster as well.
The biggest advantage of this is that all ContentRemoved notifications would see
the flattened tree before the changes, which is something a11y needs to be
correct.
XBL would still not be handled right by a11y, but that's not new and content
cannot do random stuff with XBL so it's not too bad.
Differential Revision: https://phabricator.services.mozilla.com/D32639
I need this to make style invalidation work with Shadow Parts in a way that's
fast. If something in the ancestor shadow root or any of its ancestor changes,
that makes a ::part() selector change, I don't want to walk the whole shadow
tree over and over in order to find the parts that I need to restyle.
Unfortunately we cannot just use the mutation observer setup from ShadowRoot
since, unlike for slotted elements, there's no restriction of where a part can
appear in the shadow tree.
That means that the regular nsIMutationObserver notifications don't quite cut
it, since we'd get notified only of subtree roots and we'd need to tree-walk
around in order to figure out if we have any new part.
I thought that I was going to be able to share more code with other bits if I
moved them away from nsIMutationObserver, thus bug 1554498, but in the end it
was not the case, so here's the "without bug 1554498" version of the patch.
The patch on top of that bug (that as I mention in the commit message I'm
ambivalent about whether we should land or not) should be pretty similar either
way.
Differential Revision: https://phabricator.services.mozilla.com/D32641
We need to notify the whole parent chain (using NOTIFY) rather than just
mStyleSets, since mStyleSets is empty for @import-ed sheets.
Differential Revision: https://phabricator.services.mozilla.com/D31787
After landing bug 1517241, some lines in Document.cpp and Element.cpp depend on
`using namespace mozilla` and `using namespace mozilla::dom` of *different*
cpp files. Therefore, when you rename some cpp files in dom/base, you'll
hit compile error.
This patch fixes the dependency with moving some classes into mozilla namespace
and adding |mozilla::| or |dom::| to a couple of lines.
Differential Revision: https://phabricator.services.mozilla.com/D15897
As expected, this is specific to the UA widget stuff.
What's going on here is that given we don't clear out the host when unattaching
the shadow tree, mutating that shadow tree still notifies all the way up to the
document, and that gets all the other code confused, thinking that the node is
connected.
Indeed, the first assertion that fails when loading that test-case in a debug
build is:
https://searchfox.org/mozilla-central/rev/17f55aee76b7c4610a974cffd3453454e0c8de7b/dom/base/nsNodeUtils.cpp#93
This seems the best fix to avoid confusion. Also clear the mutation observer,
to completely forget about the host.
Chrome code dealing with UA widgets needs to be careful, but I think this is
safe. All the code that assumes that GetHost() doesn't return null is in code
dealing with connected shadow trees only (style system / layout), or in
mutation observer notifications from the host.
Differential Revision: https://phabricator.services.mozilla.com/D11369
So that we don't waste a bunch of memory with stuff like <svg:use>. I
plan to shrink AuthorStyles further, but this should help regardless, and isn't
very complex.
Differential Revision: https://phabricator.services.mozilla.com/D4618
This moves all the node-specific reporting to nsIDocument.
OrphanReporter delegates all the reporting to that and then returns the sum of
all sizes, which is not ideal but was pre-existing.
Also, I moved the main mStyleSheets size reporting to DocumentOrShadowRoot for
it to be shared between document and ShadowRoot.
I'll add memory reporting for the computed stylesheet maps and such in the
ShadowRoot in a followup.
I went through all the XBL bindings, though it seems I could just use
GetBindingWithContent(), since according to:
https://searchfox.org/mozilla-central/rev/55da592d85c2baf8d8818010c41d9738c97013d2/dom/xbl/nsXBLBinding.cpp#615
We don't allow multiple bindings to contribute anon content. Anyway it was the
same amount of code...
Differential Revision: https://phabricator.services.mozilla.com/D4433
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
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
The DOM elements within the UA Widget Shadow DOM should have its reflectors in
the UA Widget Scope. This is done by calling nsINode::IsInUAWidget() which
would check its containing shadow and its UA Widget bit.
To prevent JS access of the DOM element before it is in the
UA Widget Shadom DOM tree, various DOM methods are set to inaccessible to
UA Widget script. It would need to use the two special methods in ShadowRoot
instead to insert the DOM directly into the shadow tree.
MozReview-Commit-ID: Jz9iCaVIoij
Since sed on multiple lines ended up being such a pain and I didn't end up
writing a script for this because I didn't think it'd end up being so boring, I
may have made a couple cleanups here and there as well...
Differential Revision: https://phabricator.services.mozilla.com/D2887
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
