And make them actually sound. We're defining functions on Rust-land that get
structs as arguments, but declaring them in C++ as getting pointers.
This is another step in order to be able to autogenerate ServoBindings.h and
remove bindings.rs altogether.
We remove FooOwned in favor of Owned<Foo>, which is generated via cbindgen.
It'd be good to actually mark Owned and such as MOZ_MUST_USE_TYPE, so I sent
https://github.com/eqrion/cbindgen/pull/307 for that.
Differential Revision: https://phabricator.services.mozilla.com/D24681
And make them actually sound. We're defining functions on Rust-land that get
structs as arguments, but declaring them in C++ as getting pointers.
This is another step in order to be able to autogenerate ServoBindings.h and
remove bindings.rs altogether.
We remove FooOwned in favor of Owned<Foo>, which is generated via cbindgen.
It'd be good to actually mark Owned and such as MOZ_MUST_USE_TYPE, so I sent
https://github.com/eqrion/cbindgen/pull/307 for that.
Differential Revision: https://phabricator.services.mozilla.com/D24681
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
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
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
Various places in dom/ use the pattern:
already_AddRefed<NodeInfo> ni = ...;
which is supposed to be disallowed by our static analysis code, but
isn't, for whatever reason. To fix our static analysis code, we need to
eliminate instances of the above pattern.
Unfortunately, eliminating this pattern requires restructuring how Nodes
are created. Most Node subclasses take `already_AddRefed<NodeInfo>&` in
their constructors, and a few accept `already_AddRefed<NodeInfo>&&`. We
need to enforce the latter pattern consistently, which requires changing
dozens of source files.
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 is on top of bug 1486623.
While at it removed the 'stale computed styles' report, since it was unused
since I removed the undisplayed maps.
Differential Revision: https://phabricator.services.mozilla.com/D4453
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
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
Process and non-process managers have different script loader interfaces
(ProcessScriptLoader/GlobalProcessScriptLoader vs FrameScriptLoader). The WebIDL
conversion used the same interface for some process and
non-process managers, but because of the different script loader interfaces they really
should be using separate interfaces.
Our behavior is correct, this uses the same setup that nsDocument and the
stylesets use, which I may look into fixing up / making more explicit in
bug 1465031.
MozReview-Commit-ID: 75AToXCw1pV
Now that BeginUpdate is useless for the UPDATE_STYLE case, we don't need the
update mechanism at all. Just ensure that ApplicableStylesChanged is called on
the pres shell via the relevant RuleChanged, etc. notifications.
There's a big hidden gotcha here. nsIDocument::BeginUpdate does put a script
blocker on the stack for these updates. However it's not needed, since no script
can run during these notifications (only the stylesheet events we post for
devtools, but those use AsyncEventDispatcher and PostDOMEvents, so they don't
try to run immediately).
nsIDocument::BeginUpdate also does XBL binding attached queue stuff, but we
can't change bindings during these notifications anyway, so it also doesn't
matter.
MozReview-Commit-ID: HJvK6zQfloh
This is sound because the unlink implementation of the stylesheet drops the
preserved wrapper, and there are no strong references back to any node from the
stylesheet or any of the non-unlinked members.
This almost is the same setup that works for document sheets. We need to account
for a double reference in case the sheet is applicable because Servo keeps
another reference to it in that case, instead of in the StyleSet / PresShell.
Added the testcase as a crashtest, in the hopes that if it regresses leak
reporting on automation will catch it.
MozReview-Commit-ID: Kcc5oaOvP9A
The dirty bit fiddling is nontrivial, but it's pretty much what we do for
invalidation and allows to keep this incrementally easily.
The only caller that we cared about for the GetFlattenedTreeParent check in
DestroyFramesForAndRestyle was the old ShadowRoot invalidation functions that
went away.
MozReview-Commit-ID: GmgPPJ6d2qX
