The regression range is baffling, but it just shows a missing
invalidation.
The extension has worked around this upstream:
a48ff54cf6
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
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 <jihye@igalia.com>
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 <jihye@igalia.com>
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
This will allow the browser chrome to use `<dialog>` etc, see
bug 1685313.
Tweak the check to support scrolling="false" on reftests, so that we can
test this.
Differential Revision: https://phabricator.services.mozilla.com/D102623
This will allow the browser chrome to use `<dialog>` etc, see
bug 1685313.
Tweak the check to support scrolling="false" on reftests, so that we can
test this.
Differential Revision: https://phabricator.services.mozilla.com/D102623
After applying the next part, 1161752.html's runTest2() can trigger the
following assertion without this patch.
```
ASSERTION: writing-mode mismatch: 'aWritingMode.IgnoreSideways() == GetWritingMode().IgnoreSideways()'
```
`kidDesiredSize` is initialized by ViewportFrame's reflow input, so it
stores the ViewportFrame's writing mode. But after calling
`ReflowChild`, the old code is accessing the kid's block-size by using
`kidDesiredSize.BSize(wm)`, where `wm` is being shadowed within the
inner if and becomes the kid's writing mode. This patch fixed it by
changing the inner `wm` to `kidWM` for the clarity and avoiding the
variable shadowing.
In the next part, ReflowOutput's documentation is updated, hoping to
prevent the writing mode misusages in the future.
Differential Revision: https://phabricator.services.mozilla.com/D93868
The default styling for a ::backdrop pseudo element results in it being fully opaque and occluding all the rest of the page.
This allows us to detect that case early, and skip doing any work for the rest of the page.
Differential Revision: https://phabricator.services.mozilla.com/D91669
The default styling for a ::backdrop pseudo element results in it being fully opaque and occluding all the rest of the page.
This allows us to detect that case early, and skip doing any work for the rest of the page.
Differential Revision: https://phabricator.services.mozilla.com/D91669
