nsCSSFrameConstructor::CreateContinuingFrame creates a frame based on the
result of nsIFrame::Type(). The regressing bug changed the nsFileControlFrame
type from Block to its own FileControlType type, which meant that we stopped
creating nsBlockFrame continuations for it.
Fix it by restoring the previous behavior: changing the Type() back to return
Block, and using QueryFrame instead to check for the specific
nsFileControlFrame where we need to.
This is all rather messy, see bug 1555477 for related discussion.
Differential Revision: https://phabricator.services.mozilla.com/D175062
Make all UA widgets also NAC.
Keep the UA widget flag but break at anonymous subtree boundaries, so
that only nodes inside the UA widget directly (and not NAC from those)
get the flag.
This is important because two callers depend on this difference:
* The style system, since we still want to match content rules from
stylesheets in the UA widget. We also match user rules, which is a
bit sketchy, but that was the previous behavior, will file a
follow-up for that.
* The reflector code, since we want the scope for UA widgets to not
include the NAC nodes inside that UA widget. nsINode::IsInUAWidget
got it wrong.
After this patch, ChromeOnlyAccess is equivalent to
IsInNativeAnonymousSubtree, so we should probably unify the naming.
That's left for a follow-up patch because I don't have a strong
preference.
Differential Revision: https://phabricator.services.mozilla.com/D174310
This slightly simplifies gfxTextRun::BreakAndMeasureText, and should make it less confusing
to reason about trailing whitespace in nsTextFrame/nsLineLayout.
Differential Revision: https://phabricator.services.mozilla.com/D174377
The containing block's block-size (`blockContentSize.BSize(wm)`) can be
unconstrained if the block has `position:relative` at the time we call the
`CalculateBorderPaddingMargin()`. That triggers the warning further down in the
stack in `ComputeCBDependentValue`.
However, the percentage margin and padding should resolve against the containing
block's inline-size rather than the block-size. Hence this patch.
Differential Revision: https://phabricator.services.mozilla.com/D174340
This patch deals with two things:
1. Push tall monolithic flex items to next-in-flow, and adjust their positions.
2. Grow flex container's block-size if its block-size is unconstrained.
This patch doesn't fix:
1. Item shifts in different lines in a multi-line column-oriented container
(bug 1806717).
2. Flex container block-size grow due to flex item's block-size grow in
fragmentation.
If a flex item has break-before:avoid, we don't want to push it to the
next-in-flow (in the computaion of `shouldPushItem`). Otherwise, we'll fail
web-platform/tests/css/css-break/flexbox/multi-line-column-flex-fragmentation-034.html
Differential Revision: https://phabricator.services.mozilla.com/D165192
MoveFlexItemToFinalPosition() already has a log printing flex item's position.
This patch adds a log in ReflowFlexItem() to print flex item's position, too.
Differential Revision: https://phabricator.services.mozilla.com/D165191
The intention is to allow PrintedSheetFrame::Reflow to access the page style
prior to reflowing its child so that it can decide whether to apply page style
to the sheet (in the case of one page-per-sheet). This will happen in a
subsequent bug.
Differential Revision: https://phabricator.services.mozilla.com/D173773
We had these spread around, it's better to have a single central place where we
update the widget based on the styling of the popups.
Differential Revision: https://phabricator.services.mozilla.com/D173836
Use a MiddleCroppingBlockFrame subclass that looks at the value attribute
instead. We don't need accesskey etc for these so we can just reuse it as is.
Differential Revision: https://phabricator.services.mozilla.com/D173669
We still have some remnants of XUL layout due to nsBox / nsLeafBoxFrame
which XUL trees / nsTextBoxFrame still use.
However all this code can go away before we get rid of those.
nsSplitterFrame was the last thing inheriting from nsBoxFrame.
Differential Revision: https://phabricator.services.mozilla.com/D173601
We don't want to support randomly-styled scrollbar boxes. This asserts
because it removes the scrollbar appearance. It's only a debug assert
but I don't think we want to support this.
MANUAL PUSH: Orange fix CLOSED TREE
This rewrites scrollbar layout to work with regular reflow rather than
box layout.
Overall it's about the same amount of code (mostly because
nsScrollbarFrame::Reflow is sorta hand-rolled), but it cleans up a bit
and it is progress towards removing XUL layout altogether, without
getting into much deeper refactoring.
This also blocks some other performance improvements and refactorings I
want to make in this code.
We make some assumptions to simplify the code that to some extent were
made already before, both explicitly and by virtue of using XUL layout.
In particular, we assume that scrollbar / slider / thumb has no border or
padding and that the writing-mode is horizontal ltr.
Differential Revision: https://phabricator.services.mozilla.com/D173489
This rewrites scrollbar layout to work with regular reflow rather than
box layout.
Overall it's about the same amount of code (mostly because
nsScrollbarFrame::Reflow is sorta hand-rolled), but it cleans up a bit
and it is progress towards removing XUL layout altogether, without
getting into much deeper refactoring.
This also blocks some other performance improvements and refactorings I
want to make in this code.
We make some assumptions to simplify the code that to some extent were
made already before, both explicitly and by virtue of using XUL layout.
In particular, we assume that scrollbar / slider / thumb has no border or
padding and that the writing-mode is horizontal ltr.
Differential Revision: https://phabricator.services.mozilla.com/D173489
Factor a MiddleCroppingBlockFrame that does the double reflow shenanigans.
That should both be faster and easier to reason about. The only thing we need
to be careful about is to use the current inline coord from the line layout if
present to compute the real available isize.
Differential Revision: https://phabricator.services.mozilla.com/D173668
In my local testing, this seems to be harmless, but we should be alert for reports of any erratic
or poorly-rasterized text that results.
Differential Revision: https://phabricator.services.mozilla.com/D173633
In my local testing, this seems to be harmless, but we should be alert for reports of any erratic
or poorly-rasterized text that results.
Differential Revision: https://phabricator.services.mozilla.com/D173633
Prevents backplates from being drawn for any text that has forced-color-adjust: none set by checking the value of StyleText()->mForcedColorAdjust.
Differential Revision: https://phabricator.services.mozilla.com/D173362
Previously, for writing-mode using central baseline alignment (i.e. `vertical-(lr|rl)`,
we simply used the center of content-box in `nsLineLayout::VerticalAlignFrames`.
However, this is incorrect for e.g. a `div` with two lines of text - just like how
its alphabetical baseline is the baseline of the second line of text, the central
baseline should be the centerline of the second line.
Differential Revision: https://phabricator.services.mozilla.com/D172165
With the patches of bug 1815229, these errors appear:
browser/base/content/test/performance/browser_startup_images.js | Loaded image resource://gre-resources/loading-image.png should have been shown
It's a real issue, where we eagerly load the broken image icon and so on
even though we don't use them.
This fixes it by lazily-loading the icon once, only when needed.
Differential Revision: https://phabricator.services.mozilla.com/D170159
I didn't revert some tweaks for tests (e.g. allowing small fractional scroll
position differences) since we will end up allowing the differences until
we fixed all rounding/snapping scroll related metrics issue, bug 1774315 for
example.
Differential Revision: https://phabricator.services.mozilla.com/D170465
Previously, for writing-mode using central baseline alignment (i.e. `vertical-(lr|rl)`,
we simply used the center of content-box in `nsLineLayout::VerticalAlignFrames`.
However, this is incorrect for e.g. a `div` with two lines of text - just like how
its alphabetical baseline is the baseline of the second line of text, the central
baseline should be the centerline of the second line.
Differential Revision: https://phabricator.services.mozilla.com/D172165
Previously, for writing-mode using central baseline alignment (i.e. `vertical-(lr|rl)`,
we simply used the center of content-box in `nsLineLayout::VerticalAlignFrames`.
However, this is incorrect for e.g. a `div` with two lines of text - just like how
its alphabetical baseline is the baseline of the second line of text, the central
baseline should be the centerline of the second line.
Differential Revision: https://phabricator.services.mozilla.com/D172165
WhiteMind
Robert Longson
Jonathan Kew
Natalia Csoregi
Timothy Nikkel
Emilio Cobos Álvarez
Ting-Yu Lin
Noemi Erli
Emily McDonough
Jonathan Watt
Iulian Moraru
Sandor Molnar
Cosmin Sabou
Cristian Tuns
Fred Chasen
David Shin
Hiroyuki Ikezoe
Norisz Fay
Stanca Serban