This ensures that the notion of a scroll frame's scrollable ancestor used in
SetZeroMarginDisplayPortOnAsyncScrollableAncestor() to activate ancestors
when activating a scroll frame, matches what the actual ancestor is
according to display list building logic.
This avoids us taking the buggy "activate a scroll parent after the fact"
codepath (AutoCurrentActiveScrolledRootSetter::InsertScrollFrame()), which
can result in a display list with incorrect ASRs, in at least some cases.
Differential Revision: https://phabricator.services.mozilla.com/D100303
Even though this particular test-case is regressed by bug 1624080, this
is really a pre-existing bug.
The reason why we didn't crash before that bug is that we were
incorrectly not accounting for logical border-radius properties (like
border-end-end-radius) in has_author_specified_rules, which caused us to
not disable native appearance. This in turn ended up fixing up our value
returned from AddIntrinsicSizeOffset, which covered the bug.
Use saturating math properly to prevent returning negative sizes
incorrectly from that function, which causes deeper bugs down the
pipeline.
Given the crashtest relies on our particular nscoord represenation it
doesn't seem to be worth putting in WPT, but let me know if you
disagree.
Differential Revision: https://phabricator.services.mozilla.com/D100186
We want to call it in nsFlexContainerFrame in the next part.
The method also tests form control elements via the helper
FormControlShrinksForPercentISize, not just replaced boxes, so rename it
for accuracy. We also rename the helper by dropping "I" from the
"PercentISize" because the axis the element contributingx to isn't
necessarily its inline-axis.
Differential Revision: https://phabricator.services.mozilla.com/D99951
And have it mirror in the parent process more automatically.
The docShellIsActive setter in the browser-custom-element side needs to
be there rather than in the usual DidSet() calls because the
AsyncTabSwitcher code relies on getting an exact amount of notifications
as response to that specific setter. Not pretty, but...
BrowserChild no longer sets IsActive() on the docshell itself for OOP
iframes. This fixes bug 1679521. PresShell activeness is used to
throttle rAF as well, which handles OOP iframes nicely as well.
Differential Revision: https://phabricator.services.mozilla.com/D96072
When show virtual keyboard, we calls ZoomToFocusedInput to scroll to focused
element. But this method only consider single line control. It means that this
doesn't scroll better position when focused element is multiple such as
content editable. Because we use element rectangle foo zoom to rect.
So I would like to change this for <textarea> and contenteditable.
If <textarea> or contenteditable, we should use caret frame to scroll to
better position.
Differential Revision: https://phabricator.services.mozilla.com/D96374
This is a best-effort thing of course, but so is the rest of the
visibility threshold stuff in practice and this should be good enough.
Differential Revision: https://phabricator.services.mozilla.com/D98360
This doesn't hold with fractional scale values. Right now GTK truncates
the scale factor, Windows rounds, and non-native theme rounds as well.
With this native theme will propagate correctly the floating point
values.
I tried to not change behavior meaningfully in any of the other themes,
mostly to avoid risk. GTK and Windows can be trivially tweaked to
support fractional scale factors properly if we wanted to, but seems
better to not do that as part of this patch.
Depends on D98099
Differential Revision: https://phabricator.services.mozilla.com/D98100
This reduces the chance that we accidentally introduce more
side-effect-producing code into this function. It doesn't remove
the side effects already in this function though.
Depends on D97624
Differential Revision: https://phabricator.services.mozilla.com/D97625
This patch is generated via the rename functionality in my editor; add
`mozilla::` prefix to `OverflowAreas` in headers; and remove the
`OverflowType` alias added in Part 1.
Differential Revision: https://phabricator.services.mozilla.com/D97235
This change removes docshell's `mTouchEventsOverride` and replaces it
with a new `BrowsingContext` field `TouchEventsOverrideInternal`.
All uses of the old field have been replaced and an override should
now work under fission when there are cross-origin descendent frames.
Differential Revision: https://phabricator.services.mozilla.com/D96414
Also add AsyncPanZoomController::CanScrollDownwardsWithDynamicToolbar to tell
whether the root APZC is scrollable or there is room covered by the dynamic
toolbar so that we can tell GeckoView to move the dynamic toolbar in such cases.
Differential Revision: https://phabricator.services.mozilla.com/D93914
Both are aliases to IntrinsicISizeType::MinISize and
IntrinsicISizeType::PrefISize.
Remove MOZ_ASSERT in nsLayoutUtils::IntrinsicForAxis and
nsContainerFrame::DoInlineIntrinsicISize since IntrinsicISizeType is a
enum class nowadays, which cannot have other values.
I've compiled this patch with DEBUG_INTRINSIC_WIDTH defined in
nsLayoutUtils.cpp, and fixed aWM undefined in
nsLayoutUtils::MinSizeContributionForAxis().
Differential Revision: https://phabricator.services.mozilla.com/D94618
The code in CalculateAndSetDisplayPortMargins computes metrics for the content,
which may be the RCD and therefore have separate visual and layout scroll offsets.
The code then uses CalculatePendingDisplayPort to compute displayport margins,
but that function computes the margins based on the visual scroll offset. The
code then uses that as the final margins, when in fact those margins might
need adjusting so that they can be applied to the base rect (which is based
on the layout scroll offset).
This function is invoked by MobileViewportManager after load complete, at
which point the displayport may already be set and the layout and visual offsets
may have diverged. This can happen if, for example, the user manipulates the
visual viewport early during page load, or if a visual viewport is restored
after navigating backwards. In these scenarios the existing "with adjustment"
displayport margins are clobbered by the new, incorrect "with no adjustment"
margins. This patch corrects this by specifying the necessary adjustment.
All the other call sites of this function only call it to initialize the
displayport for the first time, so they cannot run into this problem of
"clobbering" an existing margins. However, I kept this patch general enough
so that if any of those call sites were to change in the future, it wouldn't
run into the same problem.
Differential Revision: https://phabricator.services.mozilla.com/D93494
Keyboard arrow key scrolls go through PresShell::ScrollLine/ScrollCharacter. When these look for a scroll frame they eventually end up at nsLayoutUtils::GetNearestScrollableFrameForDirection.
nsLayoutUtils::GetNearestScrollableFrameForDirection does two things wrong when determining if the scroll frame is scrollable by apz: it disallows overflow hidden scrolling, and it uses GetAvailableScrollingDirections which is based on the layout scroll range.
Using GetAvailableScrollingDirectionsForUserInputEvents takes into account both of these factors.
GetNearestScrollableFrameForDirection is used by:
-gfx/layers/apz/src/FocusTarget.cpp
-EventStateManager::DoContentCommandScrollEvent
-PageMove, ScrollPage, ScrollLine, ScrollCharacter, CompleteScroll of PresShell
All of these should want the more apz aware function.
Differential Revision: https://phabricator.services.mozilla.com/D90498
This patch fixes two issues, described below:
First, the GetTopLevelDocument function was looking at the browsing
context tree. It should look at the window context tree, as looking at
the browsing context tree means that if you're in a discarded or
about-to-get-discarded document, you can end up with a document from a
different tree. Computing intersections between those of course makes no
sense and triggers the assertion we're enabling.
Second, this patch fixes an issue when you have fission enabled, and a
setup such as:
A1 -> B1 -> A2
If you try to use IntersectionObserver from A2 with the implicit root,
we'd end up with:
* rootRect: A1's root scrollport rect (this is fine, because it's only
used to compute the root margin and bounds and so on, not
to compute geometry).
* rootFrame: A1's root scroll frame (this is _not_ fine, see below).
Then, we'd try to map rects from A2's target to A1's viewport, and we
can't really do that sensibly with the existing nsLayoutUtils functions,
because we're not accounting for all the OOP iframe transforms that may
be going on. This also triggers the assertion that this patch enables in
same-origin-grand-child-iframe.sub.html.
To fix it, for the A2 case, use the same code that we have for other OOP
iframes. The test tweaks fails with fission enabled without the patch
(because we don't account for the OOP iframe clip).
Differential Revision: https://phabricator.services.mozilla.com/D92089
And enable the assertion for the same-document case.
Without this patch, the assertion would fire in tests like
gfx/layers/apz/test/mochitest/test_group_zoom.html, where stuff like
MaybeHandleEventWithAccessibleCaret, which passes a non-root-frame down
here, and a target, which ends up violating the preconditions of
ClipToFrame, etc.
Enable the assertion for the same-document case, there are other
violations when fission is enabled in the cross-document case.
Differential Revision: https://phabricator.services.mozilla.com/D91966
This allows it to be forward-declared (while a nested class cannot be),
such that headers files that use RectCallback by pointer or reference
do not need to include nsLayoutUtils.h.
This avoids including nsLayoutUtils.h in nsRange.h.
Differential Revision: https://phabricator.services.mozilla.com/D91685
Along with a dependent struct DirectDrawInfo.
This allows nsImageRenderer.h and CanvasRenderingContext2D.h to
avoid including nsLayoutUtils.h.
For nsImageRenderer.h in particular, a forward declaration is
not sufficient as nsImageRenderer stores SurfaceFromElementResult
by value.
A couple of method definitions elsewhere are moved out of line
to keep things compiling without including nsLayoutUtils.h in
additional headers.
Differential Revision: https://phabricator.services.mozilla.com/D91684
Right now the BoxToRect callback assumes that when it gets a
RECTS_ACCOUNT_FOR_TRANSFORMS flag, the "relative to" is an ancestor.
This holds for all the callers of GetAllInFlowRectsUnion except for [1],
which was introduced in bug 1581876, because they pass
GetContainingBlockForClientRect (that is, the root frame) as the root.
But that caller passes target, so IB split continuations or such would
get two siblings as the from/to frames, messing up the bounds.
An alternative would be to not pass the RECTS_ACCOUNT_FOR_TRANSFORMS
flag for that call (as it's computing a rect relative to self, but I
don't think that'd be quite correct in the presence of fragmentation
with transformed containers (if that's possible at all? would need to
think harder...)), but it seems like the API should just behave more
generally, or assert otherwise.
To that effect, this patch adds an assertion to TransformRectToAncestor
that would've caught this bug (though there are some pre-existing
violations, so we'll fix them in another bug).
[1]: https://searchfox.org/mozilla-central/rev/dfd9c0f72f9765bd4a187444e0c1e19e8834a506/dom/base/DOMIntersectionObserver.cpp#340-341
Differential Revision: https://phabricator.services.mozilla.com/D91883
For now, GetAspectRatio() is just an alias for GetIntrinicRatio(). In
Part 7, we're going to have GetAspectRatio() consider aspect-ratio
property so that each replaced elements only need to report their
intrinsic ratio via GetIntrinicRatio(). Non-replaced element can also
call GetAspectRatio() to get the ratio suitable to calculate layout
size.
As of this patch, all the replaced elements'
GetIntrinsicRatio() (including nsImageFrame::mIntrinsicRatio) consider
aspect-ratio properties (added in bug 1639963). This is wrong, because
it affects replaced element's content ratio. So we adapt only callers
[1] involving the computation of the frame's external sizes to retain
the behavior after Part 7.
This change shouldn't change behavior.
[1] Exceptions include 1) a caller in nsIFrame::ComputeSize() checking
the frame has no intrinsic ratio; 2) other frame classes implementing
nsIFrame::GetIntrinsicRatio() by calling their parent's
GetIntrinicRatio(). nsSubDocumentFrame::GetIntrinicRatio() is an
example.
Differential Revision: https://phabricator.services.mozilla.com/D91227
Apparently a bunch of Stringify(nsRect) sites were getting converted to
Stringify(nsRegion(nsRect)) due to the the nsRegion implicit constructor, so
this updates those too.
Depends on D91524
Differential Revision: https://phabricator.services.mozilla.com/D91525
Keyboard arrow key scrolls go through PresShell::ScrollLine/ScrollCharacter. When these look for a scroll frame they eventually end up at nsLayoutUtils::GetNearestScrollableFrameForDirection.
nsLayoutUtils::GetNearestScrollableFrameForDirection does two things wrong when determining if the scroll frame is scrollable by apz: it disallows overflow hidden scrolling, and it uses GetAvailableScrollingDirections which is based on the layout scroll range.
Using GetAvailableScrollingDirectionsForUserInputEvents takes into account both of these factors.
GetNearestScrollableFrameForDirection is used by:
-gfx/layers/apz/src/FocusTarget.cpp
-EventStateManager::DoContentCommandScrollEvent
-PageMove, ScrollPage, ScrollLine, ScrollCharacter, CompleteScroll of PresShell
All of these should want the more apz aware function.
Differential Revision: https://phabricator.services.mozilla.com/D90498
nsContainerFrame.h was only using the enum nsLayoutUtils::IntrinsicISizeType,
which this patch moves to LayoutConstants.h instead.
Depends on D91505
Differential Revision: https://phabricator.services.mozilla.com/D91506
The two existing uses were inconsistent in whether the margins
were relative to the visual viewport or the layout viewport.
We could fix this, but it turns out both uses are readily
refactored to not need the field, so this patch removes the
field.
Differential Revision: https://phabricator.services.mozilla.com/D91479
Keyboard arrow key scrolls go through PresShell::ScrollLine/ScrollCharacter. When these look for a scroll frame they eventually end up at nsLayoutUtils::GetNearestScrollableFrameForDirection.
nsLayoutUtils::GetNearestScrollableFrameForDirection does two things wrong when determining if the scroll frame is scrollable by apz: it disallows overflow hidden scrolling, and it uses GetAvailableScrollingDirections which is based on the layout scroll range.
Using GetAvailableScrollingDirectionsForUserInputEvents takes into account both of these factors.
GetNearestScrollableFrameForDirection is used by:
-gfx/layers/apz/src/FocusTarget.cpp
-EventStateManager::DoContentCommandScrollEvent
-PageMove, ScrollPage, ScrollLine, ScrollCharacter, CompleteScroll of PresShell
All of these should want the more apz aware function.
Differential Revision: https://phabricator.services.mozilla.com/D90498
The current formulation is inconsistent. If you call it with ScrollableDirection::Either it goes into nsLayoutUtils::GetNearestScrollableFrame which will return the first scroll frame with a non-hidden overflow. If you call it with any other ScrollableDirection it calls nsLayoutUtils::GetNearestScrollableFrameForDirection which returns the first scrollframe it finds that has non-hidden overflow AND has at least one dev pixel of scroll range.
So remove that function and call nsLayoutUtils::GetNearestScrollableFrameForDirection directly. This is a slight change of behaviour but it seems desirable for all callers.
Differential Revision: https://phabricator.services.mozilla.com/D91236
In SVG frame tree SVG{Inner,Outer}Frame is normally not scrollable but clips
descendants, thus nsLayoutUtils::GetNearestScrollableFrame is not able to find
the clip/scroll frame. So in this change, we introduce
GetNearestOverflowClipFrame which is a similar function to
GetNearestScrollableFrame but it also checks whether the frame is SVGInnerFrame
or SVGOuterFrame which is clipping the given nsIFrame during walking up the
frame tree.
In this change we also change the logic to get the clip/scroll frame and the scroll
id as follows;
1) Get the nearest overflow clip frame in the same document
2) Use the root frame if there is no clip frame
3) Then try to find the scroll id if the clip frame is asynchronously scrollable
so that it becomes clearer before. It's still messy though.
Differential Revision: https://phabricator.services.mozilla.com/D90647
The displayport is aligned to screen pixels by an alignment number; there was
code to increase that alignment number for the WebRender codepath. This is
desirable because it causes the displayport to move less frequently, which
provides better performance characteristics with WebRender. However, the
way that was implemented, it was possible for the aligned displayport to not
completely enclose the unaligned displayport, which could then result in
perma-checkerboarding.
This patch removes that code and replaces it with a simpler approach to scale
up the existing alignment number by a factor based on the size of the scroller's
base rect (roughly how much of the scroller is visible to the user).
This does make the displayports larger, more so for scrollers with more visible
area. This has negative performance implications, so we mitigate that by also
scaling down the displayport margin multiplier by the same scaling factor. This
isn't perfect, but seems to work well enough in practice.
Differential Revision: https://phabricator.services.mozilla.com/D90503
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
