This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
Most frame types have identical or very similar implementation for GetMinISize()
and GetPrefISize(), and many of them already have `IntrinsicISize()` to unify
the implementation. This patch introduces nsIFrame::IntrinsicISize() so that
derived classes only need to override one method.
`nsBlockFrame`, `ColumnSetWrapperFrame`, and `nsColumnSetFrame` are the only
three classes where their `GetMinISize()` and `GetPrefISize()` have significant
differences. Therefore, we rename `GetMinISize()` and `GetPrefISize()` to
`MinISize()` and `PrefISize`, respectively, and use them as helpers to implement
their `IntrinsicISize()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D217790
The regression range is baffling, but it just shows a missing
invalidation.
The extension has worked around this upstream:
https://github.com/AdguardTeam/AdguardBrowserExtension/commit/a48ff54cf6ec7e93f651e8b55b77d08eb0fe1be2
But the root cause is a bug in Firefox. The popup here had styles much
like:
```
html, body, #root {
height: 100%;
min-height: 100%;
width: auto;
min-width: 320px;
}
```
The popup starts off zero-sized, but then gets re-measured async at some
point by the extension code.
Main issue here is that, due to the bresize, we reflow the viewport,
then the html, but the html loses the bresize flag. So we don't reflow
the body element to give it the right height.
Before my patch, the body was reflowed because there was a BFC under it,
so it had the NS_BLOCK_HAS_CLEAR_CHILDREN flag, which ended up papering
over this bug.
I think this can only happen with the special shrink-wrap resize mode,
because it's the only thing that can turn a percentage bsize like 100%
from behaving like a percentage to behave like auto... So I haven't been
able to reproduce outside of our extension popup usage. Otherwise the
percentages resolving to different things would set the bresize flag
appropriately.
Differential Revision: https://phabricator.services.mozilla.com/D215842
When computing a hypothetical position for a fixed-pos element, we first compute
its position relative to the nearest block container `containingBlock`, and then
get the offset between `containingBlock` and the actual fixed-pos containing
block, i.e. the ViewportFrame.
However, using the ViewportFrame's origin (0,0) is incorrect. The fixed-pos
element's origin should exclude the scrollbar or scrollbar-gutter area [1].
We've fixed the containing block's origin for ViewportFrame (bug 728807), which
is used when reflowing the fixed-pos frames. The bug fixed the fixed-pos
element's position when `inset` value is specified. In this patch, when
computing the hypothetical position, we should also adjust the offset to the
containing block's origin for ViewportFrame so that the origin doesn't include
the scrollbar-gutter area, because we'll add the containing block's origin after
we reflow the fixed-pos frame at [2]. Failing to exclude the scrollbar-gutter
will cause us to shift the fixed-pos position by the scrollbar-gutter twice if
the element does use the hypothetical position as the final position
[1] A recent CSSWG resolution changed this so that top-layer or fullscreen
fixed-pos element cover the scrollbar or scrollbar-gutter. This is bug 1874091.
[2] https://searchfox.org/mozilla-central/rev/94f839e924ba6c69f3e0d062d4c6cc4fee7cad5b/layout/generic/nsAbsoluteContainingBlock.cpp#850-853
Differential Revision: https://phabricator.services.mozilla.com/D213345
When computing a hypothetical position for a fixed-pos element, we first compute
its position relative to the nearest block container `containingBlock`, and then
get the offset between `containingBlock` and the actual fixed-pos containing
block, i.e. the ViewportFrame.
However, using the ViewportFrame's origin (0,0) is incorrect. The fixed-pos
element's origin should exclude the scrollbar or scrollbar-gutter area [1].
We've fixed the containing block's origin for ViewportFrame (bug 728807), which
is used when reflowing the fixed-pos frames. The bug fixed the fixed-pos
element's position when `inset` value is specified. In this patch, when
computing the hypothetical position, we should also adjust the offset to the
containing block's origin for ViewportFrame so that the origin doesn't include
the scrollbar-gutter area, because we'll add the containing block's origin after
we reflow the fixed-pos frame at [2]. Failing to exclude the scrollbar-gutter
will cause us to shift the fixed-pos position by the scrollbar-gutter twice if
the element does use the hypothetical position as the final position
[1] A recent CSSWG resolution changed this so that top-layer or fullscreen
fixed-pos element cover the scrollbar or scrollbar-gutter. This is bug 1874091.
[2] https://searchfox.org/mozilla-central/rev/94f839e924ba6c69f3e0d062d4c6cc4fee7cad5b/layout/generic/nsAbsoluteContainingBlock.cpp#850-853
Differential Revision: https://phabricator.services.mozilla.com/D213345
`nsIFrame` provides `GetScrollTargetFrame()` for getting the scroll container
child under a frame. We can implement this for ViewportFrame so that callers
don't need to get the first child and then downcast.
Differential Revision: https://phabricator.services.mozilla.com/D213344
The two macros are used in `GetPrefISize()` and `GetMinISize()` implementations.
After removing them, we could further simplify some implementations because we
don't need a `result` variable in many cases.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D206316
ReflowInput's computed sizes and border&padding are stored in logical
coordinates, so accessing the physical version is slower [1]. This patch
converts as many callers as possible to use logical coordinates.
This patch doesn't change behavior.
[1] For example, accessing `ComputedWidth()` and `ComputedHeight()` needs two
`IsVertical()` check, but `GetPhysicalSize()` only needs one.
Differential Revision: https://phabricator.services.mozilla.com/D200237
The containing block rect which the fixed position elements are relative to
should exclude the scrollbar or scrollbar-gutter area. Current, we always use
the origin at (0,0), which makes fixed position elements draw behind the gutter
area on the left edge of the viewport.
This patch adjusts the fixed pos containing block's origin when there is a
scrollbar or scrollbar-gutter on the left edge of the viewport. In other words,
the containing block's origin becomes the same as `nsCanvasFrame`'s origin.
The "-001" test uses `scrollbar-gutter: stable`, and we already pass it without
this patch. The "-002" variant tests `scrollbar-gutter: stable both-edges`,
which requires this patch to pass.
Differential Revision: https://phabricator.services.mozilla.com/D199687
This pseudo-class is unused other than in the ua sheet. MozBrowser is
gone (getting actively removed in bug 1770944). Let's just do this since
that is taking a bit.
Differential Revision: https://phabricator.services.mozilla.com/D195095
Much like in bug 1620575. The front-end works with sizing in int CSS
pixels, so size to that so that there isn't a mismatch between our size
and the window size.
Differential Revision: https://phabricator.services.mozilla.com/D176359
This change adds support for `content-visibilty: auto` as well as
showing and hiding content based on the relevancy of the content as
defined in the specification. Changes to relevancy are handled by
triggering updates in a set of `content-visibility: auto` frames stored
in PresShell at the appropriate time in the document lifecycle.
Some tests are now failing due to this feature exposing the failures,
but they will be fixed in later changes.
This change is a reland of an earlier version that properly updates
intrinsic sizes and triggers an update of remembered size for the
purposes of contain-intrinsic-size when content relevancy changes.
Co-authored-by: Jihye Hong <[email protected]>
Differential Revision: https://phabricator.services.mozilla.com/D159693
This change adds support for `content-visibilty: auto` as well as
showing and hiding content based on the relevancy of the content as
defined in the specification. Changes to relevancy are handled by
triggering updates in a set of `content-visibility: auto` frames stored
in PresShell at the appropriate time in the document lifecycle.
Some tests are now failing due to this feature exposing the failures,
but they will be fixed in later changes.
Co-authored-by: Jihye Hong <[email protected]>
Differential Revision: https://phabricator.services.mozilla.com/D159693
The CSS Contain specification says that descendants of elements with
`content-visibility: hidden` that are in the top layer should not
generate boxes. Implementing this would lead to many open questions that
are currently not answered by the specification. While these questions
are hashed out in the specification, ensure that these top layer
elements do not generate display list items.
Differential Revision: https://phabricator.services.mozilla.com/D159051
In the description of the mTruncated bit, its purpose is the same as calling
SetInlineLineBreakBeforeAndReset(). We've removed all its usages in previous
patches, so the bit is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D151461
This patch doesn't change behavior. The "InProcess" version of this API (which
we're migrating to in this patch) is used to annotate GetCrossDocParentFrame()
callsites that have been vetted as being OK with the fact that this API returns
null at the boundary of a cross-origin iframe, if fission is enabled.
The call that's being migrated here is about propagating the NS_FRAME_IN_POPUP
state-bit into subframes that are nested inside of a popup. This bit is used to
detect cases where the display root frame is different from the document frame.
We don't need to propagate the bit across process boundaries, because the child
process will have its own display root frame, distinct from that of the parent
process. So we're OK to use the "InProcess" version of the API here.
Differential Revision: https://phabricator.services.mozilla.com/D113546
This creates a new leaf nsDisplayWrapper item for consumers that just want an empty wrapper, with a Paint method that asserts. This lets us leaves Paint pure-virtual on nsDisplayWrapList, and lets the compiler force us to implement it for the other leaf types.
It also disables flattening of transform/opacity items. This is because they flatten the items even when used with FlattenedDisplayItemIterator, even though this doesn't add markers to replace them (only FLB does this). We could in theory fix this, but I don't think FLB performance matters much any more.
Differential Revision: https://phabricator.services.mozilla.com/D114676
This creates a new leaf nsDisplayWrapper item for consumers that just want an empty wrapper, with a Paint method that asserts. This lets us leaves Paint pure-virtual on nsDisplayWrapList, and lets the compiler force us to implement it for the other leaf types.
It also disables flattening of transform/opacity items. This is because they flatten the items even when used with FlattenedDisplayItemIterator, even though this doesn't add markers to replace them (only FLB does this). We could in theory fix this, but I don't think FLB performance matters much any more.
Differential Revision: https://phabricator.services.mozilla.com/D114676
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
Ting-Yu Lin