This is the first patch of bug 1684236 tweaked as per review comments.
Keeps us with one source of truth for reflowInput.
This could be cleaned up in the future if we manage to remove that
printing hack or what not.
Co-Authored-By: fantasai <fantasai.cvs@inkedblade.net>
Differential Revision: https://phabricator.services.mozilla.com/D181857
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This patch introduces functional pseudo parameters, i.e. `::highlight(foo)`,
for `getComputedStyle()`. This required adapting the parse algorithm (`nsCSSPseudoElements::ParsePseudoElement()`) and forwarding the functional pseudo parameter into the style engine.
Differential Revision: https://phabricator.services.mozilla.com/D183773
We need to inline Self::new() so cbindgen generates the constants, which
is kinda lame, but seems better than duplicating the values and type
definitions.
Differential Revision: https://phabricator.services.mozilla.com/D183921
We need to inline Self::new() so cbindgen generates the constants, which
is kinda lame, but seems better than duplicating the values and type
definitions.
Differential Revision: https://phabricator.services.mozilla.com/D183921
We need to inline Self::new() so cbindgen generates the constants, which
is kinda lame, but seems better than duplicating the values and type
definitions.
Differential Revision: https://phabricator.services.mozilla.com/D183921
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
When balancing columns, if a block frame doesn't have enough available
block-size for a float's continuation, we move the float continuation into the
block's pushed floats list.
Typically, the float's continuation is expected to be pulled by the block's next
continuation and reflow there. However, if the block happens to be in the *last*
column, the float continuation will stay in the pushed float list until we
reflow its block again in the next column balancing loop. In this case, we
should pull it from the pushed floats list regardless of whether the
continuation has a previous continuation or not. Otherwise, it will not be
reflowed if it remains in the pushed floats list.
Differential Revision: https://phabricator.services.mozilla.com/D178141
This patch shouldn't change the behavior.
- Use `nsIFrame::PresShell()` to get PresShell directly.
- Rewrite the loop, and rename `next` to `prevSibling` for clarity.
Differential Revision: https://phabricator.services.mozilla.com/D178140
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
The only functional change in this patch is the added `else` clause.
Other changes are non-functional such as removing the `Note` and retrieving
block-end BP directly from `borderPadding` (an alias of
`BlockReflowState::BorderPadding()`). We can simplify it because nowadays
`BlockReflowState::BorderPadding()` won't skip the block-end border and padding,
and `mBorderPadding` is initialized with `PreReflowBlockLevelLogicalSkipSides()`
[1], which always assumes the current fragment is the last fragment.
The only difference between the added test and reference file are `height` and
`max-height`, so the test verifies the fragmentation are consistent internally.
[1] https://searchfox.org/mozilla-central/rev/4a5c56f4aca291802ce27320cd9a752dd5dd955e/layout/generic/BlockReflowState.cpp#43-46
Differential Revision: https://phabricator.services.mozilla.com/D176614
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
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
The expectations in page-name-propagated-003.html have turned out to be wrong
now that we have more correct abspos support.
We also need to check for placeholders in block reflow to actually support
named pages causing breakpoints where in-flow frames meet placeholders for out-
of-frame siblings.
Differential Revision: https://phabricator.services.mozilla.com/D170821
nsBlockFrame clears its line cursor at the beginning of reflow.
This test-case triggers a mix of conditions where a line iterator /
cursor can be created in the middle of reflow because of
nsListControlFrame::DidReflow triggering scrolling:
nsLineList_const_iterator::operator=
nsLineIterator::nsLineIterator
nsBlockFrame::GetLineIterator
nsIFrame::GetFrameFromDirection
nsFrameSelection::GetPrevNextBidiLevels
nsFrameSelection::GetPrevNextBidiLevels
nsCaret::GetCaretFrameForNodeOffset
nsCaret::GetFrameAndOffset
mozilla::AccessibleCaretManager::IsCaretDisplayableInCursorMode
mozilla::AccessibleCaretManager::UpdateCaretsForCursorMode
mozilla::AccessibleCaretManager::UpdateCarets
mozilla::AccessibleCaretManager::OnScrollPositionChanged
mozilla::AccessibleCaretEventHub::NoActionState::OnScrollPositionChanged
mozilla::AccessibleCaretEventHub::ScrollPositionChanged
nsDocShell::NotifyScrollObservers
mozilla::ScrollFrameHelper::ScrollToImpl
mozilla::ScrollFrameHelper::CompleteAsyncScroll
mozilla::ScrollFrameHelper::ScrollToWithOrigin
mozilla::ScrollFrameHelper::ScrollTo
nsHTMLScrollFrame::ScrollTo
non-virtual thunk to nsHTMLScrollFrame::ScrollTo
ScrollToShowRect
mozilla::PresShell::ScrollFrameIntoView
nsListControlFrame::ScrollToFrame
nsListControlFrame::ScrollToIndex
nsListControlFrame::ResetList
nsListControlFrame::DidReflow
nsLineLayout::ReflowFrame
nsBlockFrame::ReflowInlineFrame
nsBlockFrame::DoReflowInlineFrames
nsBlockFrame::ReflowInlineFrames
nsBlockFrame::ReflowLine
nsBlockFrame::ReflowDirtyLines
nsBlockFrame::Reflow
nsBlockReflowContext::ReflowBlock
nsBlockFrame::ReflowBlockFrame
nsBlockFrame::ReflowLine
Move the scrolling to happen at a stable state instead.
Differential Revision: https://phabricator.services.mozilla.com/D171998
Before, there existed 3 virtual functions that calculated baselines:
- `GetLogicalBaseline`
- `GetVerticalAlignBaseline`
- `GetNaturalBaselineBOffset`
Each of them had slightly different behaviours:
- `GetLogicalBaseline` would synthesize a baseline if there is no baseline.
Others would simply return `false`.
- `GetNaturalBaselineBOffset` requires the caller to pick which of first/last
baseline to calculate. Others pick on on their own.
- `GetNaturalBaselineBOffset`'s result can be either offset from border box
start/end edge, depending on the caller-supplied baseline. Others always
return offset from border box start edge.
Now:
- `GetNaturalBaselineBOffset` is the sole virtual function.
- `GetLogicalBaseline` exists to support its use, with 2 virtual helper functions:
- `SynthesizeFallbackBaseline` to generate a baseline for elements that
doesn't have one.
- `GetBaselineSharingGroup` to preserve the default baseline picking behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D167990
This currently only includes block frames, grid containers, and flex
containers, and the document and pagination frames. It is possible more frames
will need to be added or more advanced checks in the future.
This adds some related tests to ignoring some subtrees, but are expected fails
until bug 1816570 is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D169018
This currently only includes block frames, grid containers, and flex
containers, and the document and pagination frames. It is possible more frames
will need to be added or more advanced checks in the future.
This adds some related tests to ignoring some subtrees, but are expected fails
until bug 1816570 is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D169018
For ToResolvedValue implementation purposes we wouldn't need to split
out the vertical / font / line-height arguments and we could just pass
around the ComputedStyle, but the lh unit would need that distinction,
(because computing lh on font properties should use the parent style).
Differential Revision: https://phabricator.services.mozilla.com/D168705