test_dynamic_reflow_root_disallowal.html: in the next part, we can calculate
`min-size:auto` as the minimum of specified size and content size correctly
regardless of the value of `flex-basis`. If we do not reset the `inline-size`
(or `block-size`) to `auto`, the flex item's min-width (or min-height) will
always be its specified size (`width:10px` or `height:10px` set in
`gReflowRootCandidateStyles`), and changing `inner` to the content size from
`width:20px` to `width:40px` will have no effect.
flex-minimum-{width,height}-flex-items-005.xht: To make the flex item
resolve min-height:auto as the specified size, the content (image) size
must be larger than it. So here we change the image size to 200x200.
Google Chrome can also pass this test after this patch.
Differential Revision: https://phabricator.services.mozilla.com/D90619
nsIFrame::ComputeSize() respects UseAutoBSize, and so should
ComputeSizeWithIntrinsicDimensions(). This is essential in order to pass
layout/reftests/w3c-css/submitted/flexbox/flexbox-min-height-auto-002{a,c}.html
and flex-aspect-ratio-img-column-011.html [.flexbox 7] after updating
specified / content size suggestion in a later part.
Differential Revision: https://phabricator.services.mozilla.com/D90618
Flex item's intrinsic size can affect the content size suggestion in the
automatic minimum size resolution, so we shouldn't optimize the reflow
away. https://drafts.csswg.org/css-flexbox-1/#min-size-auto
Add `IsFlexItem()` condition to the methods to avoid set
`IMAGE_SIZECONSTRAINED` bit in `nsImageFrame::Reflow()`. So after
decoding the image and updating its intrinsic size, we'll reflow the
flex item again.
This is needed to pass
testing/web-platform/tests/css/css-flexbox/flex-minimum-width-flex-items-013.html
after updating specified / content size suggestion in a later part.
Differential Revision: https://phabricator.services.mozilla.com/D90453
This works, though probably we want to do some follow-up tweaks, like
the adding of the onload blocker and so on, so that we can avoid the
UpdateDimensions hack.
We may also want a PrintObject in the nsPrintJob tree, perhaps...
Differential Revision: https://phabricator.services.mozilla.com/D90310
Otherwise the only time it gets set is when the ZoomConstraintsClient specifically sets it in response to one of the things that can change it. But if the scroll frame gets reconstructed and one of those things don't happen it will be wrong.
This shows up with desktop zooming scrollbars because we check mZoomableByAPZ (or WantAsyncScroll()) before we use the apz scroll path in ScrollFrameHelper::ScrollBy().
Differential Revision: https://phabricator.services.mozilla.com/D90384
This patch is just refactoring and is not intended to change behavior.
Basically, we make mIntrinsicRatio also accept the value from
aspect-ratio, so it works for both replaced elements and non-replaced
elements now.
Differential Revision: https://phabricator.services.mozilla.com/D88194
For flex items with used 'flex-basis:content', normally we resolve that
(to get the 'flex base size') by behaving as if their main-size property
had the value 'max-content'.
But if the flex item has an aspect ratio and a definite cross size, then
'flex-basis:content' is instead supposed to use those values (the ratio
& cross size) to produce the flex base size. So in that scenario, we need
to behave as if the main-size property were 'auto', *not* 'max-content'.
This lets us get past an IsAuto() check & reach the codepath that calls
`Compute{Inline,Block}SizeFromAspectRatio` which does what we want.
Reference:
https://drafts.csswg.org/css-flexbox-1/#valdef-flex-basis-contenthttps://drafts.csswg.org/css-flexbox-1/#algo-main-item
Differential Revision: https://phabricator.services.mozilla.com/D86633
In some cases (in this scenario, with a RTL XUL scrollframe), the scrollframe
can have a nonzero scroll position upon construction or reconstruction, without
having executed the scrolling code in ScrollFrameHelper::RestoreState or
ScrollFrameHelper::ScrollToRestoredPosition. In such cases APZ is not properly
notified of the scroll position, and it can get into a state where it is out of
sync with the main thread scroll position (until a subsequent scroll).
To correct this, we replace the ScrollPositionUpdate that is created during
scrollframe construction with a new ScrollPositionUpdate that holds the correct
scroll position, so that APZ is properly notified of the scroll position.
Differential Revision: https://phabricator.services.mozilla.com/D90674
We usually suppress background images in
nsCSSRendering::PaintStyleImageLayerWithSC, but that codepath isn't hit
by WebRender, so instead do it during display list building, the same
way we suppress background colors.
Differential Revision: https://phabricator.services.mozilla.com/D90278
We usually suppress background images in
nsCSSRendering::PaintStyleImageLayerWithSC, but that codepath isn't hit
by WebRender, so instead do it during display list building, the same
way we suppress background colors.
Differential Revision: https://phabricator.services.mozilla.com/D90278
In ScrollFrameHelper::ScrollToImpl we suppress repainting scrollbars when calling UpdateScrollbarPosition if we've decided not to schedule a paint (because we are sending a pending scroll update instead). Otherwise we repaint which is what we are trying to avoid.
The desktop zooming scrollbars code added a call to UpdateScrollbarPosition in SetVisualViewportOffset because the vv offset is what determines the scrollbar position, no longer the layout scroll position. This means that we can trigger a repaint via that path, and there is a test that checks that we don't.
This patch moves the SetVisualViewportOffset call to just after the code that determines if we need to schedule a paint (it was just before it), and then add the AutoScrollbarRepaintSuppression class.
Differential Revision: https://phabricator.services.mozilla.com/D89902
Also combine the border and padding arguments for
nsContainerFrame::ComputeSizeWithIntrinsicDimensions(), too. This method
is used as a helper to implement ComputeSize() for various replaced
elements. Its callers are all within nsIFrame's derived classes'
overridden methods, so I'm not bothering to convert them in a separate
patch.
This change shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D90064
UpdateScrollbarPosition should have been using scroll range and not scrolled rect for a long time. It didn't matter because we only used the top left of the rect which matched until bug 1654933 made GetScrollRangeForUserInputEvents return a rect that wasn't located at 0,0.
Differential Revision: https://phabricator.services.mozilla.com/D90031
Doing rAF rAF flushApzRepaints is not enough to make sure that any potential scroll events are sent to content. The reason is that if the apz repaint request causes us to do scrolling on the main thread then the scrolling will be finished after flushApzRepaints, and the scroll event will be pending, but it's not sent until the next refresh driver tick. So we need to do at least one rAF after flushApzRepaints.
Differential Revision: https://phabricator.services.mozilla.com/D90035
Per spec we shouldn't behave differently depending on how we blocked the
image/object/etc.
This may have made sense in the past when ad blockers were implemented
via nsIContentPolicy, but I think nowadays it doesn't make sense, and
showing fallback is preferred.
There's a couple extra cleanups we can do after this lands, like
removing HTMLImageElement.imageBlockingStatus and simplifying a bit that
code. But I'll do that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D89912
Per spec we shouldn't behave differently depending on how we blocked the
image/object/etc.
This may have made sense in the past when ad blockers were implemented
via nsIContentPolicy, but I think nowadays it doesn't make sense, and
showing fallback is preferred.
There's a couple extra cleanups we can do after this lands, like
removing HTMLImageElement.imageBlockingStatus and simplifying a bit that
code. But I'll do that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D89912
This is just moving code to make it reusable in APZ. As part of this, I replace
use of Preferences::* with the StaticPrefs::* API, because we can't use
Preferences:: in the GPU process and we'll want to be able to invoke this code
from there.
Differential Revision: https://phabricator.services.mozilla.com/D89665
The only place these fields are still read are for detecting if an APZ animation
is pending (not yet submitted in a transaction) and we can replace that code
with something slightly simpler. And then delete the unused fields.
Differential Revision: https://phabricator.services.mozilla.com/D88751
The previous patches caused the scroll-behavior-element WPT to fail, specificallly
the subtest that does a no-op instant scroll immediately following an APZ smooth
scroll, within the same transaction. In this subtest, the APZ smooth scroll
request gets added to mScrollUpdates but then the instant scroll is a no-op
(destination is same as current position) so we early return and don't add a
scroll update for it. This patch adds a bit of code to the early-exit path to
detect this scenario and let APZ know to cancel the animation. By itself this
causes a different test to fail, because we also hit this codepath when the
main thread internally does a no-op instant scroll to reclamp the scroll offset
after a reflow. That requires further refining the condition with a new scroll
origin used for the clamping call.
This ain't the prettiest thing but I'm hopeful that after untangling more of
the surrounding code in the future we can replace this with something more
elegant.
Differential Revision: https://phabricator.services.mozilla.com/D88745
This rewrites a big chunk of the NotifyLayersUpdated code (most of the code that
deals with incoming scroll requests from the main-thread) to instead iterate
through the list of ScrollPositionUpdates on the metadata and apply them in
order. A bunch of the ApplyXXXUpdateFrom functions on FrameMetrics have their
innards deduplicated and boil down to a single line, which is then inlined, so
those functions get removed entirely.
Note that this rewrite doesn't yet handle all the possible types of
ScrollPositionUpdate instances, just the ones that the old code handled. In the
future this support will be fleshed out with tests to exercise the relevant
codepaths.
There is also a change to nsGfxScrollFrame which slightly modifies the semantics
of mApzScrollPos to handle the case where multiple relative scrolls happen in a
single transaction. As the implementation now requires multiple relative
ScrollPositionUpdates rather than a single "unified" relative scroll in the
FrameMetrics, we need to update mApzScrollPos for each relative
ScrollPositionUpdate we generate.
Differential Revision: https://phabricator.services.mozilla.com/D88744
The existing ScrollUpdateInfo that is used to store a "paint-skipped scroll" for
empty transactions is very similar to the new ScrollPositionUpdate class, so
we can delete the former and use the latter instead.
The important part of this change is that when applying the pending info to
a FrameMetrics, we now also append the ScrollUpdateInfo to the mScrollUpdates
list on the ScrollMetadata. This aligns the code with the previous few patches,
where we duplicate the scroll information in both the regular FrameMetrics
fields and the ScrollMetadata::mScrollUpdates array.
Note that the existing code may have a defect when multiple paint-skip scrolls
occur in a single transaction; only the newest one is kept. In the case where
the last paint-skip is an absolute scroll, this is fine, but a relative scroll
may end up clobbering a previous absolute scroll. This patch explicitly detects
the scenario with multiple paint-skip scrolls and bails out to a full paint
transaction. As a followup it should be possible to relax this restriction by
storing an array of pending ScrollPositionUpdate instances.
Differential Revision: https://phabricator.services.mozilla.com/D88743
This adds a ScrollPositionUpdate class. Code in nsGfxScrollFrame creates
instances of these classes every time the scroll generation is incremented,
and saves them to an array. The array is sent in the scroll metadata to the
compositor as part of a paint transaction.
Currently this data is not used at all on the APZ side, and exists alongside
(independently of) the existing scroll fields, so this patch should not have
any functional effects.
Differential Revision: https://phabricator.services.mozilla.com/D88741
We treat it exactly the same as -moz-broken. The pseudo-class is not
exposed to content, so I don't think we have a reason to keep it around.
Differential Revision: https://phabricator.services.mozilla.com/D89904
This happens when nsColumnSetFrame reflows its last column in an
unconstrained available block-size.
The wpt test can trigger the bug in a debug build easily. In opt builds like
Nightly, if one wants to load the test manually, additional incremental reflow
(such as opening devtools) may be needed to trigger the bug.
Co-authored-by: Mats Palmgren <mats@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D86672
Ting-Yu Lin
Emilio Cobos Álvarez
Razvan Maries
Timothy Nikkel
Boris Chiou
Cameron McCormack
Sylvestre Ledru
Kartikaya Gupta
Hiroyuki Ikezoe
Dorel Luca
Sean Feng
Narcis Beleuzu
Noemi Erli