Unfortunately this means that we need to export a couple more headers, but that
should be ok.
In particular, we have to export some headers that are #included by
nsCSSFrameConstructor.h, because nsCSSFrameConstructor.h itself will now be
included in more places outside of layout/, by .cpp files that don't necessarily
have the ability to indirectly #include its other headers, unless we export
them.
MozReview-Commit-ID: 2n9KHW6Yjrd
Most of them just want GetRootFrame(), and there's no need to explicitly go
through the frame manager for that, we have a handy alias in the shell.
MozReview-Commit-ID: GriEqkasidY
Instead move UndisplayedNode to its own file, which is what causes the include
hell due to requiring nsIContent / nsStyleContext.
MozReview-Commit-ID: 1opiajueZNb
This also includes unified build fixes that were needed as a result of
the shuffling around.
MozReview-Commit-ID: 1AGG3DHnN1m
--HG--
extra : rebase_source : 7399cea6dff2bd91ab305dee22d93b32382cc0be
-Wmissing-prototypes is a new optional warning available in clang ToT. It warns about global functions that have no previous function declaration (e.g. from an #included header file). These functions can probably be made static (allowing the compiler to better optimize them) or they may be unused.
Confusingly, clang's -Wmissing-prototypes is equivalent to gcc's -Wmissing-declarations, not gcc's -Wmissing-prototypes. A function prototype is a function declaration that specifies the function's argument types. C++ requires that all function declarations specify their argument types, but C does not. As such, gcc's -Wmissing-prototypes is a C-only warning about C functions that have no previous function *prototypes* (with argument types), even if a previous function *declaration* (without argument types) was seen.
MozReview-Commit-ID: FGKVLzeQ2oK
--HG--
extra : rebase_source : 81e62163bf41a5d5dd87abf5397e6e8c62ed4096
extra : source : 653a9fc279e2f6a6d066474a94a70d65ac703d6b
mNeedStyleFlush is also set by animation restyle request. So it's possible
that the flag is set again in PostRestyleForThrottledAnimations() or in
sequential tasks for updating animations after the flag is cleared at the top
DoFlushPendingNotifications().
MozReview-Commit-ID: KPSS6cJb4HX
--HG--
extra : rebase_source : 31d839f12b654d52b352cd50e19bc1953c46b7c2
The old style system can't find the appropriate style to inherit from when
::first-line and display: contents are involved...
MozReview-Commit-ID: 98t1ABgLulQ
It doesn't make sense, since they have no frame themselves, and it breaks
invariants other code relies on. Use the parent frame instead.
The stack overflow happens because we give the first-letter frame to the
display: contents element, then we reframe it.
Removing a display: contents node calls ContentRemoved on all the children. One
of these children is this text-node inside the first-letter frame. Since it was
split by bidi resolution we go ahead and reframe the parent in:
https://searchfox.org/mozilla-central/rev/d2b4b40901c15614fad2fa34718eea428774306e/layout/base/nsCSSFrameConstructor.cpp#9688
But the parent is the display: contents node, which results in infinite
recursion.
The usage of GetParent() is wrong anyway too, since it doesn't handle XBL or
Shadow DOM in any way.
MozReview-Commit-ID: JFD16at316V
--HG--
extra : rebase_source : e485b45bc146a70c26f8534f760899218da07500
Deletion at the end of a text-node ends up translated to an empty append. It's
harmless though.
Reviewers: xidorn
Bug #: 1442506
Differential Revision: https://phabricator.services.mozilla.com/D667
MozReview-Commit-ID: DqheOYVWx8o
When sizing the container under a min- or max-content constraint,
the item's min/max-content contribution needs to be clamped (when
Automatic Minimum Size / clamping applies) if its size is 'auto'.
That'll give the container the right intrinsic size. In Reflow,
we'll size the track initially to the clamped min-content
contribution again (in the Resolve Intrinsic Track Sizes step),
but since the container now has a definite size we'll grow
the track in the Maximize Tracks step up to its limit
(i.e. the clamp size).
For more details on the underlying issue, see:
https://github.com/w3c/csswg-drafts/issues/2303
If a single element is inserted in the document, from the lazy frame
construction path we mark it as the restyle root.
It has no restyle data, and we weren't calling ClearServoData when its parent
was being removed from ClearServoDataFromSubtree, thus leaving the stale restyle
root.
MozReview-Commit-ID: GY812b8tDk0
--HG--
extra : rebase_source : e6d1035e7d3a72b931aa53ac8dcbf7db58982479
We used to do it this way effectively until I fixed it in bug 1400936.
Per the list of fuzz bugs that bug has in the "Depends on" field, some of those
without a super-clear fix, and others that aren't listed in there, and all the
complexity we had to deal with while receiving restyle requests mid-unbind, etc,
I think this is the right call.
This clears data on RestyleManager::ContentRemoved for non-anonymous nodes, and
on UnbindFromTree for subtrees rooted at anonymous nodes.
This will hopefully yield enforceable invariants.
MozReview-Commit-ID: IMwX5Uh1apv
--HG--
extra : rebase_source : 6cafc4499c9b80cbc96f1c4d1496e524f59e3c4d
We never removed the event listeners (the code was there, lol, but the function
that was supposed to call into the tooltip listener returned
NS_ERROR_NOT_IMPLEMENTED instead).
Furthermore, we added an event listener each time we reframed an element, which
is insane. Basically, each time an element with tooltip / tooltiptext gets its
frame tree reconstructed, we add the even listener, again, and we never free it.
Xidorn pointed out that this is not such a huge deal because we deduplicate
event listeners per spec, but still...
Move the code from the RestyleManager and the frame constructor to AfterSetAttr
/ BindToTree / UnbindFromTree in nsXULElement to hopefully make this saner.
MozReview-Commit-ID: 6BQbIQJ87qt
As for now, the scrollable direction with a mouse wheel for a single-line text
control is hard-coded; that is, only horizontal wheel scrolls are able to take
effect while vertical ones aren't. However, this isn't the desired case for
vertical writing mode, where the opposite case definitely suits better.
This commit refines the hard-coded scrollable direction for a single-line text
control to be writing-mode-adaptive.
MozReview-Commit-ID: 4Zkoe2ExPCZ
--HG--
extra : rebase_source : 113b2ea80b6bbbcd2d8379b438de97eedd616551
In the era of B2G, we wanted to hide the carets during scrolling, and
PostScrollState was designed to avoid carets flicking during momentum
scrolling.
These days, we no longer hide carets during scrolling, so PostScrollState
can be removed to make the code simpler and easier to maintain.
MozReview-Commit-ID: Bf6ZgYVlt1q
--HG--
extra : rebase_source : 272bf91b8acaae6d81a3291b6ad85703ff2696dc
We just need to use the existing StyleChildrenIterator which iterates over them.
We need to be a bit careful though, since ::before and ::after are owned by
their own frame, and thus could be unbound from the tree or even dead after
removing the frame.
Hopefully the only access to the node being removed is unnecessary (anon roots
don't have siblings anyway).
There's also the weird thing of the thing we're iterating changing under the
hood. It works fine for this case, but maybe it would be better to handle them
explicitly like:
if (Element* before = nsLayoutUtils::GetBeforePseudo(aChild)) {
bool didReconstruct = ContentRemoved(aChild, ...);
if (didReconstruct) {
return true;
}
MOZ_ASSERT(!nsLayoutUtils::GetBeforePseudo(aChild));
}
// Same for ::after.
StyleChildrenIterator iter(aChild);
for (..) {
// Do the rest of the kids, which can't get unbound.
}
That'd repeat a bunch of code, so not a fan neither... I pointed this out more
explicitly in a comment instead.
MozReview-Commit-ID: HBsjLH01Db3
This unfortunately doesn't fix my test-case (because we're replacing the text
content all the time and all that), but it's still worth it, since it fixes the
case we care about (the parser appending).
We could also optimize pure insertions (since in that case we can still figure
out what the old text was), but it's probably annoying and not worth the churn.
In any case, we cannot optimize anything that resembles any kind of removal,
because from there we don't know the old text in any way (and the text nodes
like to reuse string buffers and such).
We could do two other optimizations to replace / extend this one, in that order:
* Pass the buffer and length to CharacterDataWillChange, and use that to get
the exact old text and the new one in RestyleManager. That would make the
optimization exact.
* Pass some sort of Maybe<bool> mWasWhitespace down the CharacterDataChangeInfo
which is computed like:
HasFlag(NS_CACHED_TEXT_IS_ONLY_WHITESPACE)
? Some(NS_TEXT_IS_ONLY_WHITESPACE)
: Nothing()
It's not clear to me it's going to be completely worth the churn, so I haven't
done those yet, if we see code in the wild which resembles my testcase, we can
think of doing it.
MozReview-Commit-ID: 2rTWaZti8rv
--HG--
extra : rebase_source : 7390b8740801eb7b91700bb2533c43c173ac5db9
We assert the same in nsCSSFrameConstructor::RecreateFramesForContent, which
asserts aContent.
MozReview-Commit-ID: 5r0ZjfTJ4zZ
--HG--
extra : rebase_source : dcf3ecaa2f7bd6fc8887f84d1f85018ebcae5cd3
Much like we do in nsIFrame::UpdateStyleOfOwnedChildFrame.
There's also the fact that ::-moz-math-anonymous shouldn't probably be
content-exposed... Oh well.
MozReview-Commit-ID: 8mthwW7Nivy
--HG--
extra : rebase_source : b772ca036ac3817d8e5f54b029892e9ece957d40
It would be convenient to get nsPresContext from nsIDocument.
MozReview-Commit-ID: Ei6V3UE8XGr
--HG--
extra : rebase_source : 8d2a917eb62cf341e4e1810451fd01c01dbc3bad
