This is what Chrome does.
documentElement-clientWidth-on-minimum-scale-size.tentative.html was the test
case for this but unfortunately it was disabled in bug 1515043. And it seems
that the test case failed on Android in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D19461
--HG--
extra : moz-landing-system : lando
Before this patch, we made scrollable frames derive their baseline from their
margin-box, because that's what the spec requires for scrollable inline-block
boxes. However, the spec now singles out inline-block as a special case, and
other sorts of scrollable inline-level containers are supposed to derive their
baseline from the scrolled content. So, this patch makes us do that, with an
exception for scrollable inline-block boxes.
For more info about the block-inside special case, see the end of the "block
containers" chunk here: https://drafts.csswg.org/css-align/#baseline-export
(Though that spec text may be a bit too specific, per my spec issue at
https://github.com/w3c/csswg-drafts/issues/3611 -- that's why this patch checks
for block-inside rather than inline-block.)
Differential Revision: https://phabricator.services.mozilla.com/D18481
--HG--
extra : moz-landing-system : lando
Without the check that I'm adding in this patch, we'd violate the
"parallel writing mode" expectation of some baseline accessors
that we use in the now-guarded code. And we'd produce bogus layout
as a result.
The added assertions are just for good measure. The included testcase
causes us to fail both assertions, in a build that's missing the fix.
Differential Revision: https://phabricator.services.mozilla.com/D18715
--HG--
extra : moz-landing-system : lando
This was lost in the change to only use the visual viewport if both the
size and offset were set.
Differential Revision: https://phabricator.services.mozilla.com/D17752
--HG--
extra : moz-landing-system : lando
This commit implements anchor offset adjustment. When the position of a frame
that is an anchor is changed during reflow, we notify the anchor container. The
anchor container will then post a reflow callback.
Then when reflow is completed, the anchor container will perform a scroll to
keep the anchor node in the same relative position.
Differential Revision: https://phabricator.services.mozilla.com/D13270
--HG--
extra : rebase_source : 9d40a5d5b73777d0da3799f162eeb85bb8e6d8f0
extra : source : d9052f7b34d9857863b66d64797f8b0b82504bec
This commit adds a barebones class called 'ScrollAnchorContainer' that will
contain most of the logic for scroll anchoring. It is owned as a member of
ScrollFrameHelper, and has the same lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D13267
--HG--
extra : rebase_source : 41f6f7691af60401f18f98a89f1878cfad2e74d3
extra : source : 3033401ef320414ef5f489c53526d015c38a89d7
This commit implements anchor offset adjustment. When the position of a frame
that is an anchor is changed during reflow, we notify the anchor container. The
anchor container will then post a reflow callback.
Then when reflow is completed, the anchor container will perform a scroll to
keep the anchor node in the same relative position.
Differential Revision: https://phabricator.services.mozilla.com/D13270
--HG--
extra : rebase_source : 44797fcf6585d5912f83baea90a8e554f39618b5
extra : histedit_source : c4354ba8aac99e0d083f40b515369db6a95f997d
This commit adds a barebones class called 'ScrollAnchorContainer' that will
contain most of the logic for scroll anchoring. It is owned as a member of
ScrollFrameHelper, and has the same lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D13267
--HG--
extra : rebase_source : 4d58b51aa6b893392d7c152d27750ebda059f784
extra : histedit_source : 9a2841931c47c4358e15d2fa6514ed347e3d0dad
This adds a notification from APZ to the scrollbar's slider frame to
inform it of APZ starting an async scrollbar drag. This is useful
because APZ can start a scrollbar drag and even change the scroll
position before the scrollbar frame even handles the mousedown event. In
such a case, the mousedown can land on where the scrollthumb *used to
be* before it was dragged away. This can result in scroll-to-click
behavior getting triggered and the scrollthumb glitching.
With this patch, the new notification follows the same path as the
request-repaint message, and so is guaranteed to arrive at the scrollbar
before any request-repaint messages. It sets some state that can be used
to correct the behaviour described above.
Differential Revision: https://phabricator.services.mozilla.com/D12364
--HG--
extra : moz-landing-system : lando
Currently, GetSplittableType() is called only in
nsCSSFrameConstructor::CreateContinuingFrame(). The splittable concrete frames
should inherit from nsSplittableFrame, and must explicitly create continuing
frame in CreateContinuingFrame(). Thus, no need to maintain GetSplittableType().
Differential Revision: https://phabricator.services.mozilla.com/D10798
--HG--
extra : moz-landing-system : lando
This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
--HG--
rename : gfx/layers/FrameMetrics.h => gfx/layers/ScrollableLayerGuid.h
rename : gfx/layers/FrameMetrics.h => gfx/layers/ZoomConstraints.h
extra : rebase_source : 29ac79f91460a181bf7437af5c371207e22858e2
extra : source : c2e70e531075493fc6e374dcec862827f0bc6e77
This commit adds a scroll origin, nsGkAtoms::relative, which can be used to
mark main thread scrolling that can be combined with a concurrent APZ scroll.
The behavior of this is controlled by a pref, apz.relative-update. This pref
is initially activated and is intended as an aid to narrowing down causes
of regressions for users in bug reports.
Relative scroll updates work by tracking the last sent or accepted APZ
scroll offset. This is sent along with every FrameMetrics. Additionally,
a flag is added to FrameMetrics, mIsRelative, indicating whether the
scroll offset can be combined with a potential APZ scroll. When this
flag is set, AsyncPanZoomController will apply the delta between the sent
base scroll offset, and sent new scroll offset.
This flag is controlled by the last scroll origin on nsGfxScrollFrame. The
new origin, `relative`, is marked as being able to clobber APZ updates,
but can only be set if all scrolls since the last repaint request or
layers transaction have been relative.
Differential Revision: https://phabricator.services.mozilla.com/D8234
--HG--
extra : rebase_source : 51351a84c9cda228a0975e22eda3fd3bd8d261c4
extra : histedit_source : 4b564c19b16fe2bd26adc671b62b7cb6106e8163
This commit changes `Window::ScrollBy` and `Element::ScrollBy` to use
ScrollByCSSPixels in preparation for marking ScrollByCSSPixels as a
relative scroll API.
Differential Revision: https://phabricator.services.mozilla.com/D8233
--HG--
extra : rebase_source : fa82acc12395569bd332573718f8a8013ac20b60
extra : histedit_source : 7ac061e65a2522051ed73f3ba6349d5ea696e15f
This field appears to be only ever used as a local variable, and can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D7126
--HG--
extra : rebase_source : 310057f703f4734ba9aef807100c5b5ff888da41
extra : histedit_source : 735d3f09bdb56d6eb386e2b5faffea1d769d97a1
We need to correctly populate the cumulative resolution field in the
ScrollMetadata in order to support zooming. Without this, the cumulative
resolution doesn't include the presShell resolution, and that results in
APZ getting into an inconsistent state.
Currently, the cumulative resolution is populated from the
ContainerLayerParameters object's scale, but in the case of WebRender,
we call ComputeScrollMetadata with an empty ContainerLayerParameters
since don't actually do layer building or rasterization in Gecko.
This patch makes this more explicit by changing the argument to a
Maybe<ContainerLayerParameters> and passing Nothing() from the WebRender
call sites.
In this scenario, we just use the cumulative presShell resolution as
the cumulative resolution, which should be correct for WebRender as
we won't have an "extra" CSS-derived resolution applied on the Gecko
side.
Depends on D9120
Differential Revision: https://phabricator.services.mozilla.com/D9121
--HG--
extra : moz-landing-system : lando
This change also renames several related functions, as well as fields,
and the header is moved into EXPORTS.mozilla given it is defined under
mozilla namespace.
MozReview-Commit-ID: LqCdcW8fmUN
--HG--
rename : layout/base/ScrollbarStyles.cpp => layout/base/ScrollStyles.cpp
rename : layout/base/ScrollbarStyles.h => layout/base/ScrollStyles.h
extra : rebase_source : 8933f3bca88d5db4b9508e3947f695ecf7511b3e
Currently in ContainerState::SetupScrollingMetadata we call
ComputeScrollMetadata for every layer and for each ASR in the layer's
clip chain. If there are many sibling layers with the same clip then
this is largely wasted work.
This change makes us cache the most recently calculated result, and
only recalculate if the ASR or clip is different.
There was a small portion of ComputeScrollMetadata that must actually
be executed for every layer and ASR in its clip chain. This has been moved
to a separate function, ClipLayerToDisplayPort, that is still called
every time.
MozReview-Commit-ID: 7Zzblmimtc5
--HG--
extra : rebase_source : 85ee310ceaaff5fa8a1ccb513ffaf90904ace19d
Currently in ContainerState::SetupScrollingMetadata we call
ComputeScrollMetadata for every layer and for each ASR in the layer's
clip chain. If there are many sibling layers with the same clip then
this is largely wasted work.
This change makes us cache the most recently calculated result, and
only recalculate if the ASR or clip is different.
There was a small portion of ComputeScrollMetadata that must actually
be executed for every layer and ASR in its clip chain. This has been moved
to a separate function, ClipLayerToDisplayPort, that is still called
every time.
MozReview-Commit-ID: 7Zzblmimtc5
--HG--
extra : rebase_source : 4554f908f42f761ddb2fca9be6bbe688c194c756
Currently in ContainerState::SetupScrollingMetadata we call
ComputeScrollMetadata for every layer and for each ASR in the layer's
clip chain. If there are many sibling layers with the same clip then
this is largely wasted work.
This change makes us cache the most recently calculated result, and
only recalculate if the ASR or clip is different.
There was a small portion of ComputeScrollMetadata that must actually
be executed for every layer and ASR in its clip chain. This has been moved
to a separate function, ClipLayerToDisplayPort, that is still called
every time.
MozReview-Commit-ID: 7Zzblmimtc5
--HG--
extra : rebase_source : d39908b2be2565d22079b3e5e8df56316159a918
