Hide the selection action toolbar when the session is unfocused, or when
changing the selection action delegate.
Differential Revision: https://phabricator.services.mozilla.com/D5807
--HG--
extra : moz-landing-system : lando
If we're trying to detach and reattach the same compositor object for
whatever reason, we should skip it so we don't inadvertently end up not
attaching the object at all.
Differential Revision: https://phabricator.services.mozilla.com/D5608
--HG--
extra : moz-landing-system : lando
In some scenarios profileDir is null which can cause a crash. Added a Nullable
annotation to warn of this possibility and a null check to prevent the exception
from happening.
Differential Revision: https://phabricator.services.mozilla.com/D5878
--HG--
extra : moz-landing-system : lando
Currently the Notification settings screen lets the user enable/disable
two types of notifications, both depending on Switchboard experiments.
If none of those experiments are available for the user, the entire settings
group will be hidden to avoid any confusion.
Depends on D5854
Differential Revision: https://phabricator.services.mozilla.com/D5855
--HG--
extra : amend_source : 87c1ca3c186725a607062784a35e02319d9c8107
extra : histedit_source : 476c3a1e658daa987c413038ef0087dffa52b07b
The "What's new" notification (bug 1004734) is based on an experiment which
currently is available to noone.
To avoid any confusions the settings entry for it will be hidden if the user
is not in an active "What's new" experiment.
Differential Revision: https://phabricator.services.mozilla.com/D5854
--HG--
extra : histedit_source : 357a824de41260c09067143d87ad521ba36bdfd4
Currently the Notification settings screen lets the user enable/disable
two types of notifications, both depending on Switchboard experiments.
If none of those experiments are available for the user, the entire settings
group will be hidden to avoid any confusion.
Depends on D5854
Differential Revision: https://phabricator.services.mozilla.com/D5855
--HG--
extra : moz-landing-system : lando
The "What's new" notification (bug 1004734) is based on an experiment which
currently is available to noone.
To avoid any confusions the settings entry for it will be hidden if the user
is not in an active "What's new" experiment.
Differential Revision: https://phabricator.services.mozilla.com/D5854
--HG--
extra : moz-landing-system : lando
If we're trying to detach and reattach the same compositor object for
whatever reason, we should skip it so we don't inadvertently end up not
attaching the object at all.
Differential Revision: https://phabricator.services.mozilla.com/D5608
--HG--
extra : moz-landing-system : lando
To make the test work properly, there needs two functions. One is just setting
a value for testing and sending the notificaiton for the value changes, the
other one is to reset the state for testing.
The test itself will be introduced in bug 1486971, especially in
https://phabricator.services.mozilla.com/D5004
Depends on D5503
Differential Revision: https://phabricator.services.mozilla.com/D5504
--HG--
extra : moz-landing-system : lando
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
We want to use the classic, non-adaptive icon again as our launcher icon on
Android versions prior to Oreo, as well as to continue using it in various
places within our app.
Unfortunately this means that we still have to provide duplicate resources for
those two purposes:
Because we don't want to use the adaptive icon internally, we can't use the same
resource directly for both internal usage and our launcher icon, because other-
wise on Oreo and above we'd receive the adaptive icon that way.
One possible workaround would have been to use the PNG files of our classic icon
directly as a drawable for internal useage and then create a differently named
XML bitmap for our launcher icon, which in turn would be overridden by the
adaptive icon on Oreo and above.
Unfortunately, modern usage demands that the launcher icon should be provided as
a mipmap resource, where XML bitmaps
- aren't officially supported
- unofficially work with some devices/launchers, but not all.
Therefore, our only choice is to provide separate drawables for our internal
icon and our launcher icon, even if prior to Android O both will have the same
contents. We'll also get rid of the separate round icon again, since
- on Android O and above, both round and non-round icons were using the same
adaptive icon anyway
- prior to Android O our normal icon is already round enough, but not round
enough to pass the lint check
--HG--
extra : rebase_source : 6c06c903f4fed2ef4aee3c5a915e18c437c5b510
extra : amend_source : ab3eab8e4dc2523a336aef2a4d2889ab7dbc76b9
extra : intermediate-source : 56f9803240157892066fa5b1703b8fe50c28020d
extra : source : 6183adcbfc9d81ab0cb854a4734a98f10a897d6b
We want to use the classic, non-adaptive icon again as our launcher icon on
Android versions prior to Oreo, as well as to continue using it in various
places within our app.
Unfortunately this means that we still have to provide duplicate resources for
those two purposes:
Because we don't want to use the adaptive icon internally, we can't use the same
resource directly for both internal usage and our launcher icon, because other-
wise on Oreo and above we'd receive the adaptive icon that way.
One possible workaround would have been to use the PNG files of our classic icon
directly as a drawable for internal useage and then create a differently named
XML bitmap for our launcher icon, which in turn would be overridden by the
adaptive icon on Oreo and above.
Unfortunately, modern usage demands that the launcher icon should be provided as
a mipmap resource, where XML bitmaps
- aren't officially supported
- unofficially work with some devices/launchers, but not all.
Therefore, our only choice is to provide separate drawables for our internal
icon and our launcher icon, even if prior to Android O both will have the same
contents. We'll also get rid of the separate round icon again, since
- on Android O and above, both round and non-round icon were using the same
adaptive icon anyway
- prior to Android O our normal icon is already round enough (ignoring the
Fennec icon for local developer builds)
--HG--
extra : source : 6183adcbfc9d81ab0cb854a4734a98f10a897d6b
extra : amend_source : dc14ea076aafd9d24fd5ee7aebcf71348812942c
Added an extra check of bundle size due to some unexpected transactions sizes that exceed the limit.
The bundle gets lighter if the size exceeds the limit by removing the views' state as a last resort.
Differential Revision: https://phabricator.services.mozilla.com/D5682
--HG--
extra : moz-landing-system : lando
The MozAutoplayMediaBlocked event should have its target set to the video
element, not the document.
Also, MozNoControlsBlockedVideo event has to initialized from the CustomEvent
constructor of the right window for the XBL binding to access it. I don't know
when it stopped working.
Test is added to ensure the entire UI won't break.
Differential Revision: https://phabricator.services.mozilla.com/D5801
--HG--
extra : moz-landing-system : lando
Summary:
This also moves GeckoDisplay-related things out of LayerSession
and into GeckoSession. Additionally, we try to make sure
GeckoSession has only one attached GeckoDisplay.
Reviewers: jchen, droeh
Tags: #secure-revision
Bug #: 1486778
Differential Revision: https://phabricator.services.mozilla.com/D4449