The commit also adds a missing StaticPrefs_dom.h include for APZEventState.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D41915
--HG--
extra : moz-landing-system : lando
As a result of the expansion, position:fixed elements are attached to the
expanded layout viewport.
The expanded value is used behind a pref which is enabled by default on nightly
initially, and the pref will be fliped in bug 1571599 on other channels.
scrollbars-in-landscape-content.html still fails since the vertical overlay
scrollbar doesn't appear since we are not yet using the expanded value during
reflow to tell whether we need overlay scrollbars or not. This will be fixed
by the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D40771
--HG--
extra : moz-landing-system : lando
WebRender handling of position:sticky is buggy in the presence of zooming.
The fix for bug 1563717 exposes this bug in pinch-zoom-position-sticky.html.
Differential Revision: https://phabricator.services.mozilla.com/D39574
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
StaticPrefs.h will be removed two commits from now, so update these comments.
The patch removes the comment above SetUsesContainerScrolling() because it's
wrong -- it did use static prefs when introduced by bug 1181832 but then
stopped using static prefs in bug 1470504 -- and makes it inlinable.
Differential Revision: https://phabricator.services.mozilla.com/D39133
--HG--
extra : moz-landing-system : lando
These files exist because they were the proof-of-concept first step for
splitting the static prefs header files. Now that those header files can be
generated from a script, we need to move the `accessibility.*` prefs into the
YAML file.
Differential Revision: https://phabricator.services.mozilla.com/D39132
--HG--
extra : moz-landing-system : lando
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
Minor things to ease the transition to StaticPrefList.yaml.
- Rename apz_touch_drag_enabled() to the correct apz_drag_touch_enabled(), and
media_mwf_low_latency_force_disabled() to the correct
media_wmf_low_latency_force_disabled().
- Change some trailing C-style comments to C++-style comments. This makes life
easier for the script I wrote to convert StaticPrefList.h to
StaticPrefList.yaml, which will be used for the next patch.
- Avoid comments on #define lines, because they aren't handled in the YAML
input.
- Convert a multi-line `#if` condition to a single line, because
Preprocessor.py doesn't handle multi-line conditions.
- Remove one unnecessary `#undef PREF_VALUE` directive.
- Move intl.charset.detector.iso2022jp.allowed to the correct section, so the
YAML processing script won't complain.
- Change an `int` pref to `int32_t`, again so the YAML processing script won't
complain.
- Change OS_OPENBSD to XP_OPENBSD, because the former isn't defined for
preprocessor.py. (It's also only defined in C/C++ when chromium-config.h is
included, which isn't always the case.)
Differential Revision: https://phabricator.services.mozilla.com/D37815
--HG--
extra : moz-landing-system : lando
This should ensure that the OOPIF gets painted and attached to the
compositor layer tree before the main part of the test starts. We might
be able to do something more sophisticated like waitForAllPaints or
flushApzRepaints, but it's not trivial because this page loads with an
example.com domain and can't easily access SpecialPowers.
Differential Revision: https://phabricator.services.mozilla.com/D38225
--HG--
extra : moz-landing-system : lando
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
--HG--
extra : moz-landing-system : lando
This also disables the test on Windows 7 because the newly enabled subtests
fail intermittently there. We don't care so much about Windows 7 these days,
and I don't have a local setup to reproduce it, so I didn't investigate the
failure.
Differential Revision: https://phabricator.services.mozilla.com/D37819
--HG--
extra : moz-landing-system : lando
The APZ tree walk is recursive but the render root was not being updated when
walking up out of a subtree with a different render root. This changes the
code to use a stack and push/pop the render root for subtrees as we enter
and exit the subtrees as part of the tree walk.
Differential Revision: https://phabricator.services.mozilla.com/D37614
--HG--
extra : moz-landing-system : lando
This implements the machinery for the splitting of static prefs headers, and
uses it for a single header. #includes are used in such a way that the amount
of boilerplate for each static prefs header file is minimal.
Future patches will split the remaining prefs into more header files.
Differential Revision: https://phabricator.services.mozilla.com/D36154
--HG--
rename : modules/libpref/StaticPrefs.h => modules/libpref/StaticPrefsBase.h
rename : modules/libpref/StaticPrefs.h => modules/libpref/init/StaticPrefListBegin.h
extra : moz-landing-system : lando
We should also check IsRootContentDocumentCrossProcess instead of
IsRootContentDocument there, it will be fixed in bug 1562505.
The test case in this commit is almost copied-n-pasted from
helper_scroll_into_view_bug1516056.html.
Differential Revision: https://phabricator.services.mozilla.com/D36556
--HG--
extra : moz-landing-system : lando
Botond Ballo
Olli Pettay
Nicholas Nethercote
Hiroyuki Ikezoe
Brad Werth
John Dai
Sylvestre Ledru
Alexis Beingessner
Kartikaya Gupta
Andreea Pavel
Jeff Gilbert
Cosmin Sabou
arthur.iakab
Christina Cheung
Brindusan Cristian
Mihai Alexandru Michis
Victor Porof
Razvan Maries
Narcis Beleuzu
Henri Sivonen