When calling HTMLSlotElement.assign(), we might end up removing the
manual assignment from an earlier slot.
That was unconditionally calling RemoveAssignedSlot tho, even if we
weren't in a manually-assigned shadow tree, causing the flat tree to end
up in an inconsistent state.
Differential Revision: https://phabricator.services.mozilla.com/D284171
The previous approach wasn't quite sound, because it makes the frame
constructor receive the WillBeRemoved after the flat tree has already
changed.
Instead, what do you think about something like this? This creates a
very simple wrapper over an array, but special-cases removals from the
front, and uses it for TreeOrderedArray and also AssignedNodes...
It could be polished (in particular there are a few places where an
Span::IndexOf operator could be beneficial and so).
Differential Revision: https://phabricator.services.mozilla.com/D277301
The previous approach wasn't quite sound, because it makes the frame
constructor receive the WillBeRemoved after the flat tree has already
changed.
Instead, what do you think about something like this? This creates a
very simple wrapper over an array, but special-cases removals from the
front, and uses it for TreeOrderedArray and also AssignedNodes...
It could be polished (in particular there are a few places where an
Span::IndexOf operator could be beneficial and so).
Differential Revision: https://phabricator.services.mozilla.com/D277301
Most changes are automated. Relevant bit is dom/.clang-format. I had to
manually disable clang-format in a few places where importing external
files and so on that aren't self-contained, and fix a couple includes /
forward declarations.
Differential Revision: https://phabricator.services.mozilla.com/D256800
HTML reflected IDL attributes that return a FrozenArray<T>? need to cache the
FrozenArray. This switches them from using a reserved slot on the JS object
per attribute to using an array of values for all of these types of attributes
for a particular interface, which is then stored in one reserved slot on the JS
object. This reduces the memory reserved for these attributes if they're not
actually used.
Differential Revision: https://phabricator.services.mozilla.com/D228797
Along the parent chain of a node, multiple ancestors can be assigned to dir=auto slots that the element then impacts. The flag NodeAncestorHasDirAuto is therefore not sufficient anymore.
Depends on D208338
Differential Revision: https://phabricator.services.mozilla.com/D209704
Much like BindToTree.
This will be useful because I need to pass more information through
UnbindFromTree() to speed up dir=auto for bug 1874040.
Differential Revision: https://phabricator.services.mozilla.com/D202215
ParseAttribute ideally would be const (see bug 1829138), but the SVG and
SMIL code is rather messy. Still, now that BeforeSetAttr can't really
fail, swapping the order of ParseAttribute and BeforeSetAttr shouldn't
really change behavior.
Sorry for the extra `virtual` keyword removal and such. I had to do this
one by hand unlike the dependent bugs, and I went a bit drive-by, lmk if
you want me to split those changes.
Differential Revision: https://phabricator.services.mozilla.com/D176086
Same rg + sed shenanigans as the first patch.
There were two that could fail, both due to OOM:
* HTMLInputElement::AfterSetAttr: If we fail (only in the type=range
case) we end up with an old value without it being clamped by
min/max/step.
* HTMLBodyElement::AfterSetAttr: If we fail we won't peek up the
DocShell's frame margins and styling could be incorrect.
That seems better than having to deal with broken states after we've
already set the attribute.
Depends on D176069
Differential Revision: https://phabricator.services.mozilla.com/D176070
rg BeforeSetAttr -l | xargs sed -i 's/nsresult BeforeSetAttr/void BeforeSetAttr/g'
rg ::BeforeSetAttr -l | xargs sed -i 's/nsresult \(.*\)::BeforeSetAttr/void \1::BeforeSetAttr/g'
Plus trivial fixes, plus clang-format.
The only meaningful changes are in nsXULElement::BeforeSetAttr. Two
things could fail:
chromemargin: I removed it because we don't use the parsed attribute any
other place than here:
https://searchfox.org/mozilla-central/rev/31f5847a4494b3646edabbdd7ea39cb88509afe2/dom/xul/ChromeObserver.cpp#136
And that deals just fine with it not being parsed.
usercontextid: We have a debug assertion that we don't dynamically change it.
I kept it but I don't think it's worth failing to set the attribute on release for that
Differential Revision: https://phabricator.services.mozilla.com/D176069
Otherwise we won't clear frames / style data from the assigned nodes.
I'm surprised there's no existing test catching this.
Differential Revision: https://phabricator.services.mozilla.com/D137662
According to our current usage, I don't see a case where we need to call
SlotAssignedNodeChanged without acutally moving the node. So this patch
just simpifies that behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D119443
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
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
$ for file in $(rg UnbindFromTree | cut -d : -f 1 | sort | uniq); do sed -i 's#UnbindFromTree(bool aDeep = true,#UnbindFromTree(#g' $file; done
$ for file in $(rg UnbindFromTree | cut -d : -f 1 | sort | uniq); do sed -i 's#UnbindFromTree(bool aDeep,#UnbindFromTree(#g' $file; done
$ for file in $(rg UnbindFromTree | cut -d : -f 1 | sort | uniq); do sed -i 's#UnbindFromTree(aDeep,#UnbindFromTree(#g' $file; done
$ ./mach clang-format
And fix the two callers and little use of the aDeep argument (see the "Manual
changes" patch attached to bug).
Differential Revision: https://phabricator.services.mozilla.com/D32898
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.