We expose these via CSS system colors, so this way we don't need to
rebuild the preference sheet when the link color is different.
Differential Revision: https://phabricator.services.mozilla.com/D120677
Call MaybePushFloatContainingBlock() before some of
ConstructFramesFromItemList()'s caller to enforce the invariant that a
float containing block candidate is handled before processing its
children. Most of them handle nsIFrame::eXULBox frame like nsMenuFrame
that forbid float descendants.
The assertion condition only requires us to call
MaybePushFloatContainingBlock() if aParentFrame forbids float
descendants or is a float containing block, because it is a waste if
aParentFrame has nothing to do with floats, e.g. aParentFrame is
nsInlineFrame or nsCanvasFrame.
Note: ProcessChildren() calls ConstructFramesFromItemList() internally,
so adding the assertion in ConstructFramesFromItemList() is sufficient.
Differential Revision: https://phabricator.services.mozilla.com/D120741
When we are in CreateColumnSpanSiblings(), there are floats in
nsFrameConstructorState::mFloatedList that are waiting to be added to
aInitialBlock once we leave scope of the float containing block.
However, since we are creating non-column-span continuations, which are
continuations of aInitialBlock, we should reparent the floats to these
continuations if their placeholders are the descendants of the
newly-created continuations.
multicol-span-float-002.html exercises
nsCSSFrameConstructor::ConstructBlock() and multicol-span-float-003.html
exercises nsCSSFrameConstructor::CreateIBSiblings().
Without this patch, multicol-span-float-002.html and
multicol-span-float-003.html still pass, but they trigger
```
ASSERTION: nsBlockFrame::CheckFloats: Explicit float list is out of
sync with float cache
```
1524382.html used to trigger the above assertions. Now it's fixed.
Differential Revision: https://phabricator.services.mozilla.com/D120105
Before this patch, a floating containing block (block frame)'s float
descendants are added to its mFloatedList in
~nsFrameConstructorSaveState() after returning from ProcessChildren().
This patch delays that by avoiding calling
MaybePushFloatContainingBlock() in ProcessChildren(), and move the call
one level up to ProcessChildren()'s callers so that the float
descendants are parented to the block frame after leaving the callers.
This is similar to how we handle the scope of abspos containing block.
This surely adds burden to some of the ProcessChildren() callers, but it
also unifies the float containing block scope for those callers
utilizing both ConstructFramesFromItemList() and ProcessChildren().
This doesn't change the behavior for now, but it is required by the next
part to correctly reparent the float descendants to the correct
non-column-span block continuations split by column-span wrappers.
Differential Revision: https://phabricator.services.mozilla.com/D120104
Extract a helper to consolidate the if-else-if logic dealing with float
containing block, and adapt the callers to use it rather than
PushFloatContainingBlock().
This patch shouldn't change the behavior.
Note: In ConstructTableCell(), `!isBlock` is equivalent to
ShouldSuppressFloatingOfDescendants(cellInnerFrame) since
nsMathMLmtdInnerFrame is of eMathML type, so it's OK to just call
MaybePushFloatContainingBlock().
Differential Revision: https://phabricator.services.mozilla.com/D120103
This is basically equivalent to marking the viewport frame modified when the root scroll frame is marked modified.
We wrap the top layer items in a display wrap list that uses the viewport frame as it's mFrame here
https://searchfox.org/mozilla-central/rev/bb37e6fe8bbe383a57a4ad21a201e26416613ca1/layout/generic/ViewportFrame.cpp#236
So when we invalidate the root scroll frame for getting a new display port we do a partial update. The wrap list item for the top layer items has a new display item parent, a display async zoom item (the creation of the display port changed this), so the a new display wrap list item is created. All of it's children are matched with the old children of the old display wrap list so those go away, but the old display wrap list item itself sticks around: it's mFrame is the viewport frame which was not marked modified. So the next paint we have these two identical display wrap list items (one empty), and we hit the assert.
So it seems like we need to mark the viewport frame modified if the root scroll frame is marked modified if we have top layer items (since those top layers items end up being inside the root scroll frames display list). This in turn would disable a partial update for the next paint because ShouldBuildPartial would return false because a viewport frame is modified
https://searchfox.org/mozilla-central/rev/bb37e6fe8bbe383a57a4ad21a201e26416613ca1/layout/painting/RetainedDisplayListBuilder.cpp#1309
I'm not sure this is even a bad thing, since we also disable partial updates if the canvas frame (child of the root scroll frame) is marked modified. Perhaps we would want to disable partial updates if the root scroll frame is marked modified, but we can't detect root scroll frames purely from their layout frame type.
Differential Revision: https://phabricator.services.mozilla.com/D109848
This is already a known divergence in this test that affects all of WR, rather than a new finding for only Android. We just need to move the fuzz a bit so that Android falls into it as well.
Differential Revision: https://phabricator.services.mozilla.com/D120261
Making <source> display: none is not web compatible. <track> could
probably stay, your call, but other browsers also don't do this so
perhaps we should just change the spec...
Differential Revision: https://phabricator.services.mozilla.com/D120454
This is an known issue for nscoord because we don't have a better way to
distinguish between the unresolved size and the resolved super large size.
Using NS_WARNING_ASSERTION is the current acceptable way.
Differential Revision: https://phabricator.services.mozilla.com/D119470
Tooltool images are hard to update because we don't provide a script to
generate the image and documentation is often inaccurate.
This patch makes it so we generate the AVD in the android-sdk TL job instead.
Differential Revision: https://phabricator.services.mozilla.com/D119221
Instead, fix up the various content data structures when the stylesheet
is mutated. This makes reading a stylesheet not disable style sharing.
Differential Revision: https://phabricator.services.mozilla.com/D115203
Tooltool images are hard to update because we don't provide a script to
generate the image and documentation is often inaccurate.
This patch makes it so we generate the AVD in the android-sdk TL job instead.
Differential Revision: https://phabricator.services.mozilla.com/D119221
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
Without explicitly setting the clipping rect to the specified page size, the
building rect of the display lists will be kept to the size of the nsPageFrame.
This means that any content in the nsPageContentFrame which is larger than the
physical paper size will be clipped.
The actual content frames are scaled down when this is too large, so no
overdraw will occur.
Differential Revision: https://phabricator.services.mozilla.com/D119459
Tooltool images are hard to update because we don't provide a script to
generate the image and documentation is often inaccurate.
This patch makes it so we generate the AVD in the android-sdk TL job instead.
Differential Revision: https://phabricator.services.mozilla.com/D119221
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
Emilio Cobos Álvarez
Ting-Yu Lin
Matt Woodrow
Neil Deakin
Sebastian Hengst
Andreea Pavel
Sonia Singla
Timothy Nikkel
Kashav Madan
Lee Salzman
Miko Mynttinen
Boris Chiou
Agi Sferro
Alex Henrie
Botond Ballo
Alex Lopez
Butkovits Atila
Emily McDonough
Alexandru Michis