Since callers want just an effective color to compute whether it's dark,
we simplify the API a bit too.
This makes sure we find the dark background in plain text documents.
Differential Revision: https://phabricator.services.mozilla.com/D151018
This doesn't change behavior but makes the next patch simpler, and makes
the ignore-scrollframe and non-ignore-scrollframe code-paths match.
Differential Revision: https://phabricator.services.mozilla.com/D151473
The old code in AddFloat() used to call nsBlockFrame::ComputeFloatISize() to
compute a float's inline-size, compare it with current line's available
inline-size, and determine whether FlowAndPlaceFloat() should be called.
However, it doesn't handle an orthogonal float with an auto block-size.
Luckily, FlowAndPlaceFloat() already has logic dealing with orthogonal
floats (bug 1141867), so this patch defers the decision to place a float below
the current line until the float's margin inline-size is computed in
FlowAndPlaceFloat().
Differential Revision: https://phabricator.services.mozilla.com/D151209
This patch is a preparation for the next part, and doesn't change the behavior
yet.
FlowAndPlaceFloat() is used to return true and false. This patch changes its
return value `true` to `PlaceFloatResult::Placed` and `false` to
`PlaceFloatResult::ShouldPlaceInNextContinuation`.
In the next part, we'll move the logic dealing with "below the current line
floats" into FlowAndPlaceFloat(), and make it return
`PlaceFloatResult::ShouldPlaceBelowCurrentLine`.
Differential Revision: https://phabricator.services.mozilla.com/D151208
First of all, `nsBlockFrame::AdjustFloatAvailableSpace()` is misleading. It
doesn't adjust the argument `aFloatAvailableSpace` at all, nor does it use any
fields in nsBlockFrame. It simply returns the available space in the parent
block's content area. Thus, I move it into BlockReflowState, and have it return
the available size rather than a rect because a size is sufficient for reflowing
a float.
Also, nsBlockFrame::ReflowFloat() only cares about the available size, but not
the position of the available space, so it is sufficient to pass a LogicalSize
computed by the new method ComputeAvailableSizeForFloat().
In FlowAndPlaceFloat(), there is a loop searching for a wide enough band to
place the float. We don't need to adjust availSize every time mBCoord is changed
in the loop. We can just call ComputeAvailableSizeForFloat() to get a new
available size before reflowing the float in the `!earlyFloatReflow` branch.
This patch shouldn't change the behavior.
Differential Revision: https://phabricator.services.mozilla.com/D151207
In FlowAndPlaceFloat(), condense two identical assertions about float frame
parent into one.
FlowAndPlaceFloat() calls ReflowFloat() only once, either an early reflow (when
`earlyFloatReflow` is `true`) or a late reflow (when `earlyFloatReflow` is
`false`), so the reflow status is always fresh.
Differential Revision: https://phabricator.services.mozilla.com/D151203
The `widget->DispatchInputEvent` codepath only works in gecko CI
configurations, so to allow this to be used for e.g. WebDriver
implement a path that doesn't go via the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D150632
aIsAdjacentWithBStart is used to clear the mIsTopOfPage bit for the ReflowInput
argument `aFrameRI`. However, ReflowBlock() already has aState argument to query
IsAdjacentWithBStart(), so there's no need for aIsAdjacentWithBStart argument.
Differential Revision: https://phabricator.services.mozilla.com/D150832
The basic machinery to trigger re-snap is same as what scroll anchoring does,
queueing a triggering request and flush the queued requests after reflows
finished.
Depends on D148862
Differential Revision: https://phabricator.services.mozilla.com/D148863
There are some call sites of ScrollTo involving will a GetSnapPointForDestination
call. For re-snapping, we need to inform not only the snap point but also the
snap target id(s). To do it, in subsequent patches in this commit series, we will
change only ScrollToWithOrigin arguments rather than both ScrollTo and
ScrollToWithOrigin.
Depends on D148857
Differential Revision: https://phabricator.services.mozilla.com/D148858
See bug 1758757 comment 0 for the rationale.
Note: the old code in nsTableRowGroupFrame::SlideChild() is bogus because it
calls ApplyRelativePositioning() via the nsTableRowGroupFrame's ReflowInput
instance. That is, it applies relative positioning to nsTableRowGroupFrame, but
not to the aKidFrame (nsTableRowFrame).
While I'm here, I expand `SlideChild` in its only caller, and simplify it.
Differential Revision: https://phabricator.services.mozilla.com/D150323
`aY * aY` or `aRadiusY * aRadiusY` can lead to 32-bit integer overflow,
resulting a negative number. Then `sqrt()` will produce a `nan` on a negative
number.
We should compute the `y/radiusY` division, and then square the result.
Differential Revision: https://phabricator.services.mozilla.com/D149951
As the comment in the moved hunk said, a floating first letter frame's
incomplete status means that there is more content to be reflowed on the line.
If the block containing the floating first letter has `break-inside:avoid`
style, the old code would call `SetInlineLineBreakBeforeAndReset()`, and the
block's parent frame would misinterpret the status as "this block needs to be
push to the next fragment" even if we are *not* in a paginated environment.
Hence the assertion "Shouldn't be incomplete if availableBSize is
UNCONSTRAINED."
To fix this bug, we can reset the float's reflow status for a first letter frame
before checking `ShouldAvoidBreakInside`.
Differential Revision: https://phabricator.services.mozilla.com/D149712
This patch doesn't change behavior.
This is similar to the previous patch in this series, but now for
FindBackgroundFrame().
Differential Revision: https://phabricator.services.mozilla.com/D149338
This patch doesn't change behavior.
Before this patch, the FindBackground API returns a bool to indicate
success/failure, and sets its outparam to a non-null pointer-value on success.
This patch simplifies the API by just promoting the promoting the outparam to
be the actual return value, with nullptr as a sentinel value to indicate
failure.
(This patch adds some braces to affected/contextual if statements, too, to
match our coding style guide.)
Differential Revision: https://phabricator.services.mozilla.com/D149337
With this, a relatively positioned element e.g. being offset to the left
should not decrease the scrollport size. For this, overflow area calculation
for relatively positioned elements must behave like
`nsIFrame::GetActualAndNormalOverflowAreasRelativeToParent`. We aren't
using the function directly since it's meant to be called post-reflow, and
we want to report it correctly during reflow in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D149156