When XBL is disabled, no code in dom/xbl will be built. Also, adds ifdefs
to remove any of the XBL related code elsewhere. There's definitely more
that can be done here, but I think it's better to wait to do the rest of
the cleanup when we actually remove the code.
Depends on D45612
Differential Revision: https://phabricator.services.mozilla.com/D45613
In that case, the flat tree cannot possibly be changing, so we don't really need
to invalidate anything. This, in theory, is just a really minor optimization.
In practice however, the browser chrome needs it, at least for now, because XUL
elements get frames really early (because we don't have lazy frame construction
for XUL, bug 1584935), and because destroying some kinds of frames (like panels)
does have side effects (they're popups), even though ideally they shouldn't.
Differential Revision: https://phabricator.services.mozilla.com/D48428
It was complaining about
"unrooted '<returnvalue>' of type 'JSObject*' live across GC call at dom/base/Element.cpp:588"
Where the GC call is:
Function '_ZN7mozilla3dom7Element10WrapObjectEP9JSContextN2JS6HandleIP8JSObjectEE$JSObject* mozilla::dom::Element::WrapObject(JSContext*, JS::Handle<JSObject*>)' has unrooted '<returnvalue>' of type 'JSObject*' live across GC call '_ZN6RefPtrI12nsXBLBindingED1Ev$RefPtr<T>::~RefPtr() [with T = nsXBLBinding]' at dom/base/Element.cpp:588
Element.cpp:588: Assign(64,65, return := __temp_29**)
Element.cpp:588: Call(65,66, binding.~__dt_comp ()) [[GC call]]
Element.cpp:588: Call(66,67, principal.~__dt_comp ())
Element.cpp:588: Call(67,68, uri.~__dt_comp ())
Element.cpp:588: Call(68,69, style.~__dt_comp ())
Element.cpp:588: Call(69,70, obj.~__dt_comp ())
Element.cpp:589: [[end of function]]
GC Function: _ZN6RefPtrI12nsXBLBindingED1Ev$RefPtr<T>::~RefPtr() [with T = nsXBLBinding]
RefPtr<T>::~RefPtr() [with T = nsXBLBinding] [[base_dtor]]
static void RefPtr<T>::ConstRemovingRefPtrTraits<U>::Release(U*) [with U = nsXBLBinding; T = nsXBLBinding]
static void mozilla::RefPtrTraits<U>::Release(U*) [with U = nsXBLBinding]
uint32 nsXBLBinding::Release()
uint64 nsCycleCollectingAutoRefCnt::decr(void*, nsCycleCollectionParticipant*, uint8*) [with void (* suspect)(void*, nsCycleCollectionParticipant*, nsCycleCollectingAutoRefCnt*, bool*) = NS_CycleCollectorSuspect3; uintptr_t = long unsigned int]
NS_CycleCollectorSuspect3
nsCycleCollector.cpp:void SuspectAfterShutdown(void*, nsCycleCollectionParticipant*, nsCycleCollectingAutoRefCnt*, uint8*)
nsCycleCollectionParticipant.DeleteCycleCollectable
void nsIContent::cycleCollection::DeleteCycleCollectable(void*)
nsIContent.DeleteCycleCollectable
unresolved nsIContent.DeleteCycleCollectable
I don't think the analysis is right since the Rooted<> thing will go out of the
scope after the RefPtr.
MANUAL PUSH: Bustage fix for broken (I think) analysis
People keep shooting themselves in the feet because of this codepath and writing
slow code.
There are just a few elements with bindings left, so just check those.
Also simplify a bit the code. The XUL element + tagname check should be pretty
fast now, and ComputedStyle objects no longer keep weak pointers to pres
contexts and such, so can be safely kept on a RefPtr across an style flush.
Differential Revision: https://phabricator.services.mozilla.com/D47995
* wpt runs chrome priv for a subset of tests (mostly things testing toolkit chrome stuff), but it's still in the content process
* we only ever hit this case if the test is explicitly loaded as chrome. originally added for a couple osx tests at https://bugzilla.mozilla.org/show_bug.cgi?id=1465457. then expanded for all xul tests at https://bugzilla.mozilla.org/show_bug.cgi?id=1557371
* so what we used to do here is run xul/xbl in the content process (not chrome priv)
* the change here is that with our chrome Custom Elements we need to run with chrome priv for https://searchfox.org/mozilla-central/rev/4218cb868d8deed13e902718ba2595d85e12b86b/toolkit/components/processsingleton/CustomElementsListener.jsm#16 to load the elements
* so we made it explicit. the alternative at the time was to change wpt harness to load these tests in parent process, but it was too complex for what we needed (discussed with dbaron)
* this parentprocess check was meant kind of as an optimization so that we wouldn't have to check priv on random pages. but (a) that's short circuited anyway by the xul elem check and (b) this is only called when attachShadow is called on a non-html element so not in any kind of hot path
Differential Revision: https://phabricator.services.mozilla.com/D46310
And remove the NodeInfoChanged override that used to call it.
This is dead since we removed the old style system. Was used to force a reparse
on cross-style-back-end adoption.
Differential Revision: https://phabricator.services.mozilla.com/D44134
This contains an (intentional) behavior change, which is that we always copy
(i.e. don't reparse) style attributes, even across documents.
XUL and HTML already had this behavior. This makes stuff like SVG and MathML
consistent with that.
Depends on D44128
Differential Revision: https://phabricator.services.mozilla.com/D44129
After addressing review comments in the other patch of this bug, debug builds
assert all the time here when called from UnbindFromTree() on an already-unbound
subtree.
We clear the binding parent on unbind, so this is only guaranteed to match for
connected nodes, as far as I can tell.
Differential Revision: https://phabricator.services.mozilla.com/D43641
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
ReferrerPolicy gets tossed back and forth as a uint32_t and
ReferrerPolicy enum in header file. Expose ReferrerPolicyValues from
webidl file and use consistently in native code.
Differential Revision: https://phabricator.services.mozilla.com/D41954
When we're slotted, we inherit our directionality from the slot element. But
when binding an ltr subtree into an rtl subtree, we used to bind the explicit
kids first, then the shadow root kids (which includes the slots to which
explicit kids may have been assigned).
So the explicit kids looked at the slot directionality before it was recomputed,
and thus ended up with ltr rather than rtl directionality.
Differential Revision: https://phabricator.services.mozilla.com/D42304
Return a raw pointer instead of a strong reference to a ComputedStyle, and
handle the case of the style not being present by returning null rather than
requiring an extra function to check it and crashing if the precondition is not
met.
Also, name them so that it's clear they just return outdated styles and don't
make any extra effort.
This is just cleanup that makes the next patch easier / more obvious.
Differential Revision: https://phabricator.services.mozilla.com/D40080
We naively remove and then recreate accessibles when their content's
frame is reconstructed. By delaying the removal until we are certain the
content does not have a new layout frame, we can cut down on redundant
recreations.
When reconstructed content is re-inserted we can check it and its
subtree for missing frames and prune those accessibles from the tree.
Differential Revision: https://phabricator.services.mozilla.com/D38380
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
This is pretty much the same as ScrollStyles::IsSmoothScroll right now,
but in the next commit, we will no longer propagate scroll-behavior on <body> to
the root element so that nsIScrollableFrame::IsSmoothScroll will be changed
to reflect it.
Differential Revision: https://phabricator.services.mozilla.com/D35737
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
This is intended to give a reasonable number that scales with the amount of
content in a website during page load, for scheduling purposes.
This effectively counts the amount of text connected to a document that isn't
likely to be inline style or script.
Potential improvements:
* Maybe have some more heuristics for hidden elements, like presence of the
`hidden` attribute?
* Maybe skip whitespace-only text? This does a pretty good job anyways because
whitespace nodes are usually pretty small (like a couple newlines and
spaces), so they don't add too much to the number. This could be done cheaply if
looking at sSpaceSharedString / sTabSharedString.
* Add some weight to some elements? Maybe images should have a fixed weight,
for example. Though you don't want 0x0 images and such to count... Maybe we
should add to this heuristic out of band when processing image loads or some
such.
* Handle shadow DOM and such better? Right now Shadow DOM and XBL are always
assumed visible as long as they're connected. You _can_ in theory do
something like stash a `<div>` inside a `<style>` element, attach a
ShadowRoot and such, and append a bunch of stuff inside. But I don't think
it's something we should be particularly worried about.
* Probably add some check to CharacterData::AppendText as well? Otherwise this
undercounts when loading big amount of text arrives via the network, for
example, but also I'm not sure we're optimizing for log files and such so it
might be ok.
In any case, this gives us a heuristic that we can iterate on later. This does a
pretty good job at representing the amount of content in the examples over here:
* https://faraday.basschouten.com/mozilla/executionorder/
For example for:
* https://faraday.basschouten.com/mozilla/executionorder/allinlinedual.html
You get an output like the following if you print the heuristic after each bind
operation (and de-duplicating them):
```
0
3 // Some whitespace in <head>
4 // Some whitespace in the <body>.
5
6
7
8
9
10
65547 // Actual content injected by the first script.
65548 // Some more whitespace.
131085 // Actual content injected by the second script.
131087 // Some more whitespace.
```
I'm not a fan of what clang-format has done to my code btw :)
Differential Revision: https://phabricator.services.mozilla.com/D34397
This makes some callers a bit less awkward by not having, for example, to read
from the parent node or not depending on whether Element::BindToTree has been
called already or not.
Differential Revision: https://phabricator.services.mozilla.com/D33368
BindContext was going to have way more information at first, but then I realized
that most of the things I wanted to know were basically a flag away using the
parent node.
Still I think it's worth it, now experimenting with BindToTree will only mean
adding a field to a struct that's included from a couple cpp files, instead of a
massive pain.
I also think this is clearer, and doing this highlights quite a few
inconsistencies in our code which I've left untouched, but commented with
FIXMEs.
Steps are:
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsresult BindToTree(Document\* aDocument, nsIContent\* aParent,#nsresult BindToTree(BindContext\&, nsINode\& aParent)#g' $file; done
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's# nsIContent\* aBindingParent) override#override#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(Document\* aDocument, nsIContent\* aParent,#::BindToTree(BindContext\& aContext, nsINode\& aParent)#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsIContent\* aBindingParent)##g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(aDocument, aParent, aBindingParent)#::BindToTree(aContext, aParent)#g' $file; done
$ ./mach clang-format
Then manual fixups.
Depends on D32948
Differential Revision: https://phabricator.services.mozilla.com/D32949
This doesn't clean up as much as a whole, but it's a step in the right
direction. In particular, it allows us to start using simple bindings for:
* Filters
* Shapes and images, almost. Need to:
* Get rid of the complex -moz- gradient parsing (let
layout.css.simple-moz-gradient.enabled get to release).
* Counters, almost. Need to:
* Share the Attr representation with Gecko, by not using Option<>.
* Just another variant should be enough (ContentItem::{Attr,Prefixedattr},
maybe).
Which in turn allows us to remove a whole lot of bindings in followups to this.
The setup changes a bit. This also removes the double pointer I complained about
while reviewing the shared UA sheet patches. The old setup is:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* UrlValueSource
* Arc<CssUrlData>
* load id
* resolved uri
* CORS mode.
* ...
```
The new one removes the double reference to the url data via URLValue, and looks
like:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* CorsMode
* LoadData
* load id
* resolved URI
```
The LoadData is the only mutable bit that C++ can change, and is not used from
Rust. Ideally, in the future, we could just use rust-url to resolve the URL
after parsing or something, and make it all immutable. Maybe.
I've verified that this approach still works with the UA sheet patches (via the
LoadDataSource::Lazy).
The reordering of mWillChange is to avoid nsStyleDisplay from going over the
size limit. We want to split it up anyway in bug 1552587, but mBinding gains a
tag member, which means that we were having a bit of extra padding.
One thing I want to explore is to see if we can abuse rustc's non-zero
optimizations to predict the layout from C++, but that's something to explore at
some other point in time and with a lot of care and help from Michael (who sits
next to me and works on rustc ;)).
Differential Revision: https://phabricator.services.mozilla.com/D31742
