This patch enforces the invariant for `AbsoluteContainingBlock::Reflow()` that
most of the `Reflow()` functions already have.
Differential Revision: https://phabricator.services.mozilla.com/D302429
Removed the Reflow Input in nsIFrame. Added includes for ReflowInput as
necessary in cpp files. Also Forward Declared nsLineLayout in 3 header
files.
Differential Revision: https://phabricator.services.mozilla.com/D298203
They never inherit anything (except background, but that is a no-op
because viewport inherits from nullptr, which is the initial style).
It seems in the past we relied on recomputing some of this for direction
propagation or so, according to the comments, but that's definitely no
longer true.
Also the comment about needing overflow: auto is wrong, because we've
since always created scrollbars for the root (and avoided reframes).
Similarly, the assertion about viewport is kinda unnecessary. It was
introduced in:
https://hg.mozilla.org/mozilla-central/rev/8fd06045940a05d56d833a0488262fe2279d3702
But since then we always skip fixup for all anon boxes anyways, and
specify display: block explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D293710
After the previous patches, nsViewManager is basically a backpointer to
its pres shell.
Remove it and just make PresShell manage the root view directly. After
this is done, we can decide what to do about nsView (which is itself
little more than a widget listener that forwards to pres shell right
now).
This technically starts listening to mParentWidget slightly later (on
pres shell creation), but I think that's ok.
Differential Revision: https://phabricator.services.mozilla.com/D272890
* Dimensions don't need to be a rect, just a size.
* We don't need a frame, it's just the pres shells root frame.
* mWidgetIsTopLevel is always true iff there is a widget.
Differential Revision: https://phabricator.services.mozilla.com/D272573
Remove and simplify some view-using code:
* Add nsIFrame::GetOwnWidget() to get an nsIWidget rather than doing
menupopup-or-view.
* Move widget invalidation to the only place it's used.
* Don't deal with reentrant paints. Assert more strongly.
* Move SetView only to ViewportFrame.
Differential Revision: https://phabricator.services.mozilla.com/D272208
I couldn't repro this locally but I think the paragraph below explains
what's going on.
Bug 1998125 made nsView::DropMouseGrabbing clear the mouse grab
unconditionally. Instead do it if only on our document to restore the
previous behavior when the document is going away.
Differential Revision: https://phabricator.services.mozilla.com/D272202
No need to reposition views during layout and so on, now that we don't
use views for either popups nor subdocuments.
No need for nsView to have parent / sibling / children either.
Differential Revision: https://phabricator.services.mozilla.com/D271205
`AdjustReflowInputAsContainingBlock` and
`GetContainingBlockAdjustedForScrollbars()` does the same thing, except the
former adjusts the `ReflowInput` parameter.
I assume the adjustment of `ReflowInput` is not really needed if we pass the
testcase `layout/reftests/bugs/844178.html` added in bug 844178.
Differential Revision: https://phabricator.services.mozilla.com/D268305
With this patch moves `AbsoluteContainingBlock` into `mozilla` namespace, we
could remove `mozilla::` qualifiers in the header.
Differential Revision: https://phabricator.services.mozilla.com/D266558
The asr of some display items depends on the items that it contains. When we do a partial display list update and we merge display list we can change what an item contains so we might have to update the asr of the item. UpdateASR performs this work. Unfortunately it doesn't quite do it correctly.
Items whose asr depends on the items that it contains will pick the asr that is an ancestor (or equal to) of the asr of every item that it contains. Additionally we want the asr to be an ancestor (or equal to) the initial asr for the item.
aContainerASR in UpdateASR contains the asr that is an ancestor of every contained item. So UpdateASR assumes that if the item is not a wrap list item that it wants the container asr as its asr. This is not correct. Additionally it assumes that if the item is a wrap list item (or subclass) that it wants the ancestor behaviour for it's asr. This is also not correct. What each display item wants for its asr is more complicated then that.
The pernosco session https://bugzilla.mozilla.org/show_bug.cgi?id=1764863#c1 gives an example of this going wrong. In that case the item is a transform item and it only contains items whose asr is a descendant of the asr of the transform item. The transform item is not a wrap list, so we set the asr of the transform item to a descendant of the asr that it should be.
To fix this we add a function to all display items that opts them in to this ancestor behaviour for asrs if they want it. Some display item types only want the ancestor behaviour in some cases so it can't just be based on the display item type. In making this change we need to look at all display item types that can return non-null from GetChildren (if they can't have children the asr won't change dynamically based on children/the contents). There are four such classes (and then all of their subclasses): nsDisplayContainer, nsDisplayTransform, nsDisplayPerspective, nsDisplayWrapList. In practice nsDisplayContainer is always Ancestor asr (but we still pass Ancestor at all places we create one). nsDisplayPerspective and nsDisplayTransform are always Constant asr. and nsDisplayWrapList has a very large tree of subclasses with various different behaviours of asr.
This also fixes a bug in UpdateASR: if aContainerASR is nothing then we should set the asr to the frame asr rather then early exiting.
Differential Revision: https://phabricator.services.mozilla.com/D262257
Per spec, snapshot containing block should include scrollbar-gutter, so
we shouldn't adjust its position and size by the scrollbar sizes.
However, for the rest of children of viewport frame still need this
adjustment, so we move all the calculation into
nsAbsoluteContainingBlock::Reflow() and
nsAbsoluteContainingBlock::ReflowAbsoluteFrame(), and choose the proper
ReflowInput and containing block for different kid frames.
https://www.w3.org/TR/css-view-transitions-1/#snapshot-containing-block-concept
Differential Revision: https://phabricator.services.mozilla.com/D260220
This function may be used outside ViewportFrame, and we expect its
parameter, `ReflowInput`, is non-null always, so use reference to avoid
any accidents.
Differential Revision: https://phabricator.services.mozilla.com/D260511
This patch makes sure that top layer display items that we build for a
given page are uniquely tagged with the page number, which avoids
uniqueness assertion failures with the patch from bug 1972694.
In theory this could also trivially happen by printing a modal <dialog>
or so, but it currently doesn't, see bug 1981732.
The patch in bug 1972694 exposes this on a devtools test
(browser_browser_toolbox_print_preview.js) because we start creating an
isolation container for the DevTools anonymous content, which is in the
top layer, and we currently didn't set the page number in the
ViewportFrame::BuildDisplayList which ends up building it, failing our
unique display item assertions.
Differential Revision: https://phabricator.services.mozilla.com/D260270
This requires splitting the top layer code a little bit, but nothing too
crazy.
This also prevents filters on the root element from applying to things
like the devtools highlighters, which seems would be otherwise
unintended.
Differential Revision: https://phabricator.services.mozilla.com/D254079
I haven't been able to reproduce this locally, but I see what's going
on, and I think we could do better.
This avoids the frame flush from nsCanvasFrame::CreateAnonymousContent,
and in general makes the anonymous content timing a lot more reasonable
(see the FlushPendingNotifications call that's getting removed).
The ServoStyleSet changes are needed now that there are multiple style
roots that can be unstyled like that.
It also simplifies the API as now it's not dependent on having a canvas
frame around (and thus doesn't need to flush layout).
Differential Revision: https://phabricator.services.mozilla.com/D250531
We introduce `::-moz-snapshot-containing-block` pseudo-element to wrap
the view transition pseudo-element tree. This pseudo-element is only for
internal usage and cannot be accessed from outside.
Note that the related wpt,
`snapshot-containing-block-static.html`
`snapshot-containing-block-absolute.html`
are still failed because of Bug 1960755.
Also, add a test to check the snapshot containing block in the iframe,
and avoid hitting the issue of Bug 1960755.
There is no better way to verify that we do establish the fixed
positioning containing block, because it's unlikely to make the size of the
snapshot containing block be different from the viewport size on desktop
(note: this pseudo-element doesn't expose to the web), so I verified this
patch by changing the size of snapshot containing block manually in the UA
stylesheet, to see if it establish the fixed positioning containing block.
Differential Revision: https://phabricator.services.mozilla.com/D245648
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
Ting-Yu Lin