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
With a non-owning reference, a JS reference to the NodeList didn't keep its
items alive. With this change, the NodeList keeps the parent node (which keeps
its children alive) alive.
Differential Revision: https://phabricator.services.mozilla.com/D34151
The tests added in this patch do not fail any of their assertions with or
without the code changes in this patch. However, without the code changes in
this patch they will both fail due to reported memory leaks.
Differential Revision: https://phabricator.services.mozilla.com/D31577
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
Due to renaming nsContentIterator.cpp to ContentIterator.cpp, Document.cpp
and FragmentOrElement.cpp are compiled in a unified cpp file now. However,
both of them have same name constant, kNSURIs and some build systems claim
that it in FragmentOrElement.cpp is never used.
Fortunately, each of them is used only by one method. Therefore, this patch
moves the each declaration into each user method.
Differential Revision: https://phabricator.services.mozilla.com/D16186
Now, nobody requires nsIContentIterator interface. So, we can get rid of it.
Unfortunately, there is no macro to keep the inherited class,
ContentSubtreeIterator, in the cycle collection to make it keep managing
ContentSubtreeIterator::mRange without nsISupports interface. Therefore, this
patch moves it into ContentIteratorBase temporarily. Anyway, the following
patch makes those classes not refcountable. At that time, this issue will be
fixed.
Differential Revision: https://phabricator.services.mozilla.com/D15927
Now, nobody requires nsIContentIterator interface. So, we can get rid of it.
Unfortunately, there is no macro to keep the inherited class,
ContentSubtreeIterator, in the cycle collection to make it keep managing
ContentSubtreeIterator::mRange without nsISupports interface. Therefore, this
patch moves it into ContentIteratorBase temporarily. Anyway, the following
patch makes those classes not refcountable. At that time, this issue will be
fixed.
Differential Revision: https://phabricator.services.mozilla.com/D15927
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.
This needs to add a few of includes in other places which were relying on the
massive (now gone) list in nsDocument.h.
I also needed to move an AnimationTimeline destructor out of line because it
relied on dom::Animation being defined, yet Animation.h includes
AnimationTimeline.h, so include hell.
Differential Revision: https://phabricator.services.mozilla.com/D15366
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.
Referrer policy argurment is passed from sheet/doc to URLExtraData, default
value is RP_Unset. We use default value in some cases, particularly when there's
no certain spec talks about that (svg for example)
MozReview-Commit-ID: 5VAX1ZUXD3i
Differential Revision: https://phabricator.services.mozilla.com/D1922
This reports the memory as part of element-nodes, but I think that's OK for
now. If we want to, we can try to add more nsWindowSizes buckets for this stuff.
Differential Revision: https://phabricator.services.mozilla.com/D4811
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
