mScale is the zoom at the time the displayport margins were set, but
the resulting ScreenMargin will be interpreted in the context of the
scale at which we're about to paint, which may be different.
Note that mMargins themselves are not affected by these two scales
being potentially different, since we want the magnitude of the
margins to the constant in Screen pixels (i.e. a constant fraction
of the viewport size).
Differential Revision: https://phabricator.services.mozilla.com/D173577
Gijs for front-end bits, layout for the new CSS properties and the
removal of nsDeckFrame / nsStackLayout, Jamie and Morgan for the a11y
changes.
As discussed in the bug, the main tricky part here is handling a11y
correctly. For <deck>, that's trivial (just use `visibility: hidden` to
hide the panels visually, while removing the unselected panels from the
a11y tree).
For <tabpanels> however we need to do something special. We do want to
hide stuff visually, but we want to preserve the contents in the a11y
tree.
For that, the easiest fix is introducing a new privileged CSS property
(-moz-subtree-hidden-only-visually), which takes care of not painting
the frame, but marks stuff offscreen in the accessibility tree. This is
not intended to be a property used widely.
Other than that, the changes are relatively straight-forward, though
some of the accessible/mac changes I could get a sanity-check on.
Differential Revision: https://phabricator.services.mozilla.com/D157875
Gijs for front-end bits, layout for the new CSS properties and the
removal of nsDeckFrame / nsStackLayout, Jamie and Morgan for the a11y
changes.
As discussed in the bug, the main tricky part here is handling a11y
correctly. For <deck>, that's trivial (just use `visibility: hidden` to
hide the panels visually, while removing the unselected panels from the
a11y tree).
For <tabpanels> however we need to do something special. We do want to
hide stuff visually, but we want to preserve the contents in the a11y
tree.
For that, the easiest fix is introducing a new privileged CSS property
(-moz-subtree-hidden-only-visually), which takes care of not painting
the frame, but marks stuff offscreen in the accessibility tree. This is
not intended to be a property used widely.
Other than that, the changes are relatively straight-forward, though
some of the accessible/mac changes I could get a sanity-check on.
Differential Revision: https://phabricator.services.mozilla.com/D157875
There is one thing to note in this patch that is a change: this patch changes the displayport that we log for test purposes from the critical display port to the display port.
This will only be different on android. If tests were checking this then they were broken because the critical display port has no significance. I did a quick survey of the tests I could find that used this. None of them seem like they really want the critical display port (given the new world where critical display port has no significance).
Depends on D127350
Differential Revision: https://phabricator.services.mozilla.com/D127351
The reason that GetDisplayPortForVisibilityTesting was using Drop was because there is a test that sets a 10x zoom and we ran image visibility without updating the displayport base rect (painting would update it), so the returned displayport was based on the much larger base rect. The patches goal was to avoid the assert we removed. Using a displayport that large in that situation for image visibility seems fine because it shouldn't make us decode any more images then were previously already visible.
Depends on D127731
Differential Revision: https://phabricator.services.mozilla.com/D127732
No longer necessary, and it only NS_ASSERTION'd if we failed anyway, and we weren't even checking on mac and android due to the tiling pref.
Differential Revision: https://phabricator.services.mozilla.com/D127731
This stuff is now a no-op because the RequestContentRepaint message has a
higher priority than vsync.
Depends on D127033
Differential Revision: https://phabricator.services.mozilla.com/D127593
With the old layers backend we had low precision buffer code controlled via the pref layers.low-precision-buffer that was used on android. We would expand the displayport by 4x and then paint it as 1/4 the resolution, and then we would have a critical displayport without the 4x multipler that we would paint at the real resolution. The code to do the painting at the lower resolution was in the layers backend and has since been removed. (This is okay because webrender doesn't rasterize all of the content in the displayport.) So the critical displayport or displayport are no longer treated differently anywhere. Except a few pieces of code that should be fixed/changed/removed. This patch being one of them.
GetHighResolutionDisplayPort would return the displayport without the multipler in all situations (pref on or off).
In DisplayPortUtils we are checking the displayport rect before/after setting new displayport margins to see if it changes to determine if we need to invalidate. Since the critical displayport isn't used for anything, the regular displayport is the correct thing to use here.
In nsGfxScrollFrame we are doing a similar thing, except checking that the displayport doesn't change after a scroll.
In nsDisplayListBuilder::OutOfFlowDisplayData::ComputeVisibleRectForFrame it's also the correct thing, as we want to include the same rect for fixed content as we do for non-fixed content. But this is an significant expansion of the dirty rect of fixed content and the code history has fixes related to drawing too much of fixed content and OOMing so a little more scrutiny is reasonable. However if there was a problem with OOM, since this is the same rect we use for non-fixed content we would have OOM problems with regular content, so this should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D127344
After the fixes in this patch, the REQUIRES_UNIFIED_BUILD declaration is no
longer needed, so I'm removing it here. This directory now builds successfully
with that removed and with ac_add_options --disable-unified-build in the
mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D125601
This patch is the result of auditing all places that look at the presence or absence of a display port to handle minimal display ports (HasDisplayPort, GetDisplayPort, etc).
Broadly speaking the places were in two categories:
1) things related to painting, that want to consider minimal display ports as display ports for purposes of things like sending over metadata and separating out layers.
2) things that care about async scrolling, and so actually want to have a properly sized display port.
Type 1) were not changed by this patch. Type 2) were changed to consider minimal display ports as not display ports.
Again, we are aiming to leave behaviour unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D103856
We introduce a new type of display port, a minimal display port. It is controlled via a property on the content element. When the property is present any other display port specified on the element is ignored and instead the display port rect is computed by assuming 0 display port margins and no alignment (this reuses the existing code for display port suppression).
We then add code to set a minimal display port on every scroll frame that is painted that has WantAsyncScroll() when certain prefs are set (the prefs are disabled as of this patch though).
We then need to manage removing the minimal display port property when, before this patch, we would have created a regular display port. As well we need to add the minimal display port property when, before this patch, we would have removed a regular display port.
In order to do this I audited all sites where we set the display port rect and display port margins property. The changes to the code for handling the removal display ports happens in a later patch.
My audit found that all of the places we set a display port want to clear the minimal display port property except:
-UpdateSub/RootFrame in APZCCallbackHelper
-UpdateDisplayPortMarginsForPendingMetrics in DisplayPortUtils
UpdateDisplayPortMarginsForPendingMetrics is basically a fast path of the UpdateSub/RootFrame code. These are the places where we handle calls to RequestContentRepaint from apz. By adding an assert and running it through try server I found that UpdateSub/RootFrame can create a display port in the following cases:
-a scroll info layer
-a scroll frame with !WantAsyncScroll() (the main thread never creates a display port for a scroll frame with !WantAsyncScroll()) (for example if the main thread creates a scroll id and sends over metadata via nsLayoutUtils::GetRootMetaData, and then the scroll rect changes, that will cause a RequestContentRepaint call)
-a few instances that don't fall into the above that happened on try server but didn't reproduce for me locally, so I don't know more about them.
It's not very important whether we clear the minimal display port property for these cases or not (the first two cases we don't async scroll the scroll frame at all, the last case seems quite rare).
Note that we intentionally do not change the existing behaviour of zero margin display ports set via SetZeroMarginDisplayPortOnAsyncScrollableAncestors as we are aiming for no behaviour changes with this patch (until we flip the pref). A later patch in a different bug handles changing these display ports over to minimal display ports.
Differential Revision: https://phabricator.services.mozilla.com/D103855
DisplayPortMargins objects are only meant to be created when setting
display port margins, not when querying them, because the object's
constructor records the visual and layout scroll offsets at the time
of construction to use for adjusting the margins to be layout-relative.
Differential Revision: https://phabricator.services.mozilla.com/D102075
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 when the margins don't come from APZ, they are relative to
the visual viewport, and for the RCD-RSF there may be an offset
between the visual and layout viewports that they should be
translated by.
Bug 1669982 modified the call site in
CalculateAndSetDisplayPortMargins() to do this. This patch
refactors things such that all setters of the display port
do this if appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D93428
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
Where an adjustment (to reflect a delta between the APZ and layout
scroll offsets) is necessary, the inputs needed to compute the
adjustment are stored with the margins, and the adjustment is
applied at query time.
A couple of notes on this patch:
* Storing DisplayPortMargins::mLayoutOffset is probably unnecessary,
we should be able to just query the scroll frame's layout offset
when applying the margins.
* Some callers of DisplayPortMargins::WithNoAdjustment() may be
incorrect, in that they pass in margins that are relative to the
visual viewport but do not make a corresponding adjustment.
This is a pre-existing issue that this patch just makes clearer.
As this is a regression-prone area, this patch is careful to avoid
making any functional changes, leaving the above issues to be
addressed in future bugs.
Differential Revision: https://phabricator.services.mozilla.com/D92506
Botond Ballo
Dan Robertson
Emilio Cobos Álvarez
Marian-Vasile Laza
Miko Mynttinen
Timothy Nikkel
Alexandru Michis
Noemi Erli
Jeff Muizelaar
Hiroyuki Ikezoe
Sandor Molnar
Daniel Holbert
Matt Woodrow
Kartikaya Gupta