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
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
When the window temporarily loses focus (e.g. due to auto-fill popups),
don't call setFocus(false). Otherwise, we can end up disrupting user
interaction (e.g. causing the auto-fill popup to flicker). Only call
setFocus(false) when we are reasonably sure the focus loss is not
temporary.
Differential Revision: https://phabricator.services.mozilla.com/D5329
To avoid unnecessary setActive calls, only call it when we have a
display and when the display acquires or releases a surface. In other
cases, we can delay the setActive call until later.
Differential Revision: https://phabricator.services.mozilla.com/D5328
