This patch uses a case-insensitive matcher to highlight the title of a history
entry that's been typed by the user. Previously the matching substring was
calculated manually as lowercase assuming that it's representation would have
the same number of characters as the original mixed case. In some locales
howerver this assumption is wrong leading to out-of-bound exceptions when
highlighting part of the title.
Differential Revision: https://phabricator.services.mozilla.com/D6661
--HG--
extra : moz-landing-system : lando
This patch prevents Fennec/GeckoView crash reporters from sending the large,
useless StackTraces field when submitting a report. I've also taken the
liberty of removing an obsolete crash annotate that was being added to
Fennec's reports.
Differential Revision: https://phabricator.services.mozilla.com/D6389
--HG--
extra : moz-landing-system : lando
back out the Fennec GWS/Facebook UA-spoofing system addon added in bug 1453691
Differential Revision: https://phabricator.services.mozilla.com/D6065
--HG--
extra : moz-landing-system : lando
The content of e.target has been changed in bug 1375319 from document
to the fullscreen element, so the current code makes it never dispatch
DOMFullScreen:Start, so the Java side would not be aware of such state.
This code was initially added in bug 859683 for supporting scrolling
when the fullscreen element is the document element. Since then, it
seems that the related code had been refactored, and the only usage
of rootElement was removed in bug 1416330.
Because of that, it is no longer necessary to use event target, and
we can just use document directly, which would fix this issue.
Differential Revision: https://phabricator.services.mozilla.com/D6221
--HG--
extra : moz-landing-system : lando
This will allow to check that indeed, when a Notifications related experiment
is enabled, the "Notifications" setting will appear in the menu.
Depends on D5855
Differential Revision: https://phabricator.services.mozilla.com/D6136
--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 : 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
So far, we've generally opted for a policy of disabling the Updater when we've
been installed from the Play Store, not least because this is not allowed by the
Play Store's terms of service.
While other references to the Updater in the Android app UI are already
completely hidden in that case and we don't do any automatic checking for up-
dates either, the "Check for Updates" button on about:firefox is only hidden via
the MOZ_UPDATER build define and therefore still visible on all Nightly builds.
Since dynamically hiding it might be more involved, we just make sure that the
Updater simply aborts and returns NOT_AVAILABLE when an Update request has been
triggered from Gecko on a Play Store-installed build.
That way, we should be able to avoid all situations where the Updater might want
to display a notification, which of course doesn't work when the corresponding
notification channel hasn't been registered.
Differential Revision: https://phabricator.services.mozilla.com/D6060
--HG--
extra : moz-landing-system : lando
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
Send the new "GeckoView:PinToScreen" event in Fennec code so the Fennec
toolbar is pinned when dragging selection carets.
Differential Revision: https://phabricator.services.mozilla.com/D5191
Add a flag for whether the session should be pinned to the screen. The
app would check the flag and prevent scrolling of the session when it's
pinned.
Differential Revision: https://phabricator.services.mozilla.com/D5190
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
