The only reason not to do that is when there's after content in there. We know
that there isn't really any ::after content, since it would've been handled by
FindNextSibling, so we know we're performing a real append.
MozReview-Commit-ID: ExoPolZy4gG
Otherwise we may inappropriately style it or what not. This asserts with the
patches of bug 1414999 plus the cleanup of bug 1418456, since we no longer do
StyleNewChildren (which walks over the flattened tree children).
Too bad that GetXBLBinding is a virtual call in Gecko, probably can do just
MAY_BE_IN_BINDING_MGR...
MozReview-Commit-ID: CNU0YdKeaR0
Now we always restyle the whole subtree for Servo, so we may create another
style context for the bound element.
This trips assertions if we happen to create pseudo-element styles for them.
Since that assertion is pretty useful, just re-get the style context all the
time, which is a cheap operation otherwise.
The CLOSED TREE nightmare should end. This wasn't caught in my try run because
another assertion made the crashtests stop running, apparently.
MozReview-Commit-ID: 6U0phWFvvXO
They're useless now, provided we remove the hack to not traverse XBL-bound
elements on initial styling.
This also allows us to get rid of the fallback case.
MozReview-Commit-ID: AvBVdyF1wb6
We not only need to care about children getting inserted in the flat tree, but
also about children moving _out_ of the flat tree.
In particular, as of right now we may leave stale data on elements when they
disappear from the flattened tree.
We're lucky enough that in 99% of the situations we enter in[1] and that clears
all the stuff, including servo data. But my assertions for bug 1414999 caught
the template / observes case.
Thus, just clear the whole bound element subtree data, and restyle it in the
end, no need for StyleNewChildren. This matches what we do for shadow DOM
(though in the shadow DOM case we do it async in DestroyFramesForAndRestyle).
[1]: https://searchfox.org/mozilla-central/rev/9bab9dc5a9472e3c163ab279847d2249322c206e/dom/xbl/nsXBLBinding.cpp#368
MozReview-Commit-ID: 69A0aR0AFfU
I don't know why GetInsertionPrevSibling would get the parent wrong.
IsValidSibling handles the frameset case and a lot of the table caption cases.
The table caption cases IsValidSibling can't handle are due to elements which
create frames based on something other than display.
For those cases, while IsValidSibling will return incorrect results, we will end
up seeing that the parent frame is the wrong type after creating the frame
construction items for the new stuff and reframe under WipeContainingBlock.
MozReview-Commit-ID: 5b3L4CB6Oxl
InsertFirstLineFrames has been dead for a long time, and I don't think it's
worth to keep it around. It's in the VCS history anyway.
MozReview-Commit-ID: FetYB6nf38D
This is a significant rework of how do we compute the insertion point of a
node.
We handle pseudos in the same function instead of out of band, and also recurse
up when the parent has display: contents, which simplifies the code IMO.
MozReview-Commit-ID: 1rSfv1Tq5gO
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
Turns out that the patches in bug 1398448 fixed most of the layout stuff.
There's a GeckoRestyleManager assertion in test_shadowroot_style.html about
document mismatches while restyling, which looks scary, but I haven't
investigated (nor plan to, since that code is hopefully going away soon).
MozReview-Commit-ID: 4km5NCr5xp2
(This makes it behave a bit more like a normal CSS block, and it ensures that
it can provide a float manager to its descendants.)
MozReview-Commit-ID: FmnQYjzD2eD
Right now, date/time fields in Fennec appear as regular text fields,
which display the date/time values without formatting. This patch makes
the fields use the Gecko controls, which do support formatting. This
only changes the appearance of the fields; we still display the native
date/time pickers when the fields are tapped on. The reset button is
hidden in the controls because the Fennec date/time picker provides
a separate "clear" button.
MozReview-Commit-ID: 75QyKmolNuf
Right now, date/time fields in Fennec appear as regular text fields,
which display the date/time values without formatting. This patch makes
the fields use the Gecko controls, which do support formatting. This
only changes the appearance of the fields; we still display the native
date/time pickers when the fields are tapped on. The reset button is
hidden in the controls because the Fennec date/time picker provides
a separate "clear" button.
MozReview-Commit-ID: EBE2U1zL74Q
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
