Because we are going to use it for prefers-reduced-motion media feature which
is tied to a system setting.
Differential Revision: https://phabricator.services.mozilla.com/D5502
--HG--
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoInputDeviceListener.java => mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoSystemStateListener.java
rename : widget/android/GeckoInputDeviceListener.h => widget/android/GeckoSystemStateListener.h
extra : moz-landing-system : lando
The framework to simulate the setting change works as following;
- nsIDOMWindowUtils.setPrefersReducedMotion() calls an IPC function which ends
up calling nsChildView::SetPrefersReducedMotion() in the parent process
- nsChildView::SetPrefersReducedMotion() sets the given value into
nsLookAndFeel::mPrefersReducedMotionCached just like we set the value queried
via NSWorkspace.accessibilityDisplayShouldReduceMotion in the parent process
and send a notification which is the same notification MacOSX sends when the
system setting changed
- Normally the cached value is cleared before quering new values since the
cache value is stale, but in this case the value is up-to-date one, so
nsChildView::SetPrefersReducedMotion() tells that we don't need to clear the
cache, and nsIDOMWindowUtils.resetPrefersReducedMotion() resets that state
of 'we don't need to clear the cache'
There are two test cases with the framework in this commit, one is just setting
the value and checking the value queried by window.matchMedia. The other one is
receiving 'change' event and checking the value of the event target.
Note that to make this test works the patch for bug 1478212 is necessary since
the test runs in an iframe.
Depends on D5003
Differential Revision: https://phabricator.services.mozilla.com/D5004
--HG--
extra : moz-landing-system : lando
In child processes on MacOSX we don't spin native event loop at all.
Without native event loops NSWorkspace.accessibilityDisplayShouldReduceMotion
doesn't return up-to-date value when the system setting changed for some reasons.
To workaround this we use NSWorkspace.accessibilityDisplayShouldReduceMotion
only on the parent process which spins native event loop or when it's the
initial query on the child process. And we give the up-to-date value to the
child process via an IPC call just like other cached values do.
Depends on D5002
Differential Revision: https://phabricator.services.mozilla.com/D5003
--HG--
extra : moz-landing-system : lando
To make it clear that ApplyFullscreen is one of the places where
fullscreen requests are consumed.
Depends on D5851
Differential Revision: https://phabricator.services.mozilla.com/D5852
--HG--
extra : moz-landing-system : lando
This is done so that we can encapsulate more logic in this struct in following commits.
Depends on D5847
Differential Revision: https://phabricator.services.mozilla.com/D5848
--HG--
extra : moz-landing-system : lando
This patch fixes an issue where a suite was being found in the full path to the test which led to the baseline coverage tests being considered on a per-suite basis (like browser-chrome), when it should be on a per-file-extension basis for '.html' files. This is fixed by only considering the test name and excluding the full path to it.
Differential Revision: https://phabricator.services.mozilla.com/D5890
--HG--
extra : moz-landing-system : lando
This makes sure to release blockers (so that content process
preallocation can resume) in error cases, and stops making preallocated
processes themselves blockers, because it's unnecessary (we don't
currently support multiple preallocated processes) and not doing it
means not having to handle those error cases as well.
(Also, in the future we might want to allow the possibility of multiple
concurrent launches if the hardware can support it with acceptable
performance.)
Differential Revision: https://phabricator.services.mozilla.com/D5725
--HG--
extra : moz-landing-system : lando
This will be used when we migrate away from XBL and to a Custom Element
in the following changesets.
Differential Revision: https://phabricator.services.mozilla.com/D5598
--HG--
extra : moz-landing-system : lando
Even with no options, this is not a simple retrigger -- it adds voluminous
debug output. So let's keep it as a custom action.
Differential Revision: https://phabricator.services.mozilla.com/D5879
--HG--
extra : source : 841dccc8771929583260a968a97910adad8c4a6b
extra : amend_source : 38fe427071f9478716b161f72876385383cc20b6
When checking whether the new relocations sizes are going to be a win, we
need to account for the fact that there are non-elfhacked relocation
remaining.
Differential Revision: https://phabricator.services.mozilla.com/D5837
--HG--
extra : moz-landing-system : lando
Now that we ship builds using clang on all platforms, pick it during
configure. It is still possible to opt-in to building other compilers by
setting CC/CXX (or even only CC) to the desired compiler.
Depends on D5829
Differential Revision: https://phabricator.services.mozilla.com/D5637
--HG--
extra : moz-landing-system : lando
Before this change, we'd derive a host compiler and handle things as if
HOST_CC/HOST_CXX had been passed. With this change, we change the list
of compilers that are tested with check_prog instead.
Depends on D5828
Differential Revision: https://phabricator.services.mozilla.com/D5829
--HG--
extra : moz-landing-system : lando
While those builds are not fully supported yet, it's better to ensure
the coming changes to toolchain.configure won't break them.
Differential Revision: https://phabricator.services.mozilla.com/D5828
--HG--
extra : moz-landing-system : lando
Some mozconfigs actually rely on testing whether the variable is set or
not, which may or may not depending on the mozharness configuration,
and doesn't necessarily match what the mozconfigs do.
So in all mozconfigs that enable PGO, make them use an environment
rathen than ac_add_options.
Differential Revision: https://phabricator.services.mozilla.com/D5843
--HG--
extra : moz-landing-system : lando
* A new accepted-cards element to represent the labeled list of card icons
* Add the accepted cards section to the summary and card add/edit page
* mochitest for the accepted-cards element
* Make cc-type a required field and validate it against the list of supported networks
* Add verification of the pay button disabling when card network is not supported
Depends on D5823
Differential Revision: https://phabricator.services.mozilla.com/D5824
--HG--
extra : moz-landing-system : lando
* Includes a workaround to explicitly cloneInto the paymentMethods data when we create the PaymentRequest object in the content window in tests.
MozReview-Commit-ID: LFy0h3fIXXA
Differential Revision: https://phabricator.services.mozilla.com/D5823
--HG--
extra : moz-landing-system : lando
