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
FrameMetrics is currently used in about three ways.
1. Main thread to APZ transactions
2. Storing information in AsyncPanZoomController
3. APZ to main thread repaint requests
There's overlap in the use of fields in all these use cases, but it's not perfect. In a
following commit, I'd like to change the information used for (1) to support relative
scroll offset updates. This information isn't needed for (2) or (3), so it would be
good to refactor FrameMetrics out into these use cases.
This commit refactors out (3) as it is fairly easy to do. I'd like to refactor (2) out
as well, but that is trickier. I'd like to leave that for a future followup.
Differential Revision: https://phabricator.services.mozilla.com/D7127
--HG--
extra : rebase_source : f0be2be24fce7d0f0ed25f6f3bfab5f7f2864f23
extra : source : fc9898a9ab28cee292e201ddaf757ee267179433
extra : histedit_source : 35415d3dc2c0ae0f269994c385cceff75f150020
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
The cctools-port linker links against libraries from clang (for LTO),
which have different SONAMEs depending on the clang version. Which means
the linker needs to be used along the same version of clang it was built
against. Thus we also make it depend on linux64-clang-7.
But changing the dependency is not enough, cf. bug 1471905, so also
touch its build script, which it turns out, we need to do anyways
because llvm-dsymutil was renamed to dsymutil.
Relatedly, all toolchains that are built using cctools-port need to use
linux64-clang-7 too.
Building compiler-rt 7 with the OSX 10.11 SDK fails because of some
newer APIs being used in compiler-rt for xray, but this is not a feature
we use, so disable that.
Differential Revision: https://phabricator.services.mozilla.com/D6766
The previous resolution is restored when exiting fullscreen mode.
Depends on D9442
Differential Revision: https://phabricator.services.mozilla.com/D9443
--HG--
extra : moz-landing-system : lando
APZ wants the *size* of the layout viewport from the main thread, but it
knows the position better.
Differential Revision: https://phabricator.services.mozilla.com/D9448
--HG--
extra : moz-landing-system : lando
Sharing tabs with file:// URIs is not possible, but users can still send them to
other apps via the helper app system in the URL bar/context menu. "Intent:Open"
and "Intent:OpenForResult" are both sent from Gecko by HelperApps.jsm.
The same reasoning as in bug 1450449 applies as to why for publicly accessible
files content:// URIs are more trouble than they're worth.
Differential Revision: https://phabricator.services.mozilla.com/D9420
--HG--
extra : moz-landing-system : lando
This is an attempt to fix the intermittent on this test.
It looks like we were setting the listeners on some events
after the request message was received, which might have
made us missed some events.
We take this bug as an opportunity to do some cleanup
on the test.
Differential Revision: https://phabricator.services.mozilla.com/D9075
--HG--
extra : moz-landing-system : lando
After the previous patches, we no longer rely on the component manager
to incidentally start up XPConnect when we load the JS loader service
or to hold the JS component loader alive, so the do_GetService() call
for the JS loader in XPCOMInit.cpp can be removed. After that is done,
the JS loader is no longer used as an XPCOM component, so all of the
boilerplate for that can be removed.
Depends on D8757
Differential Revision: https://phabricator.services.mozilla.com/D8758
--HG--
extra : moz-landing-system : lando
