Create test entries via update introduces performance overhead.
We can store them directly in LookupCache and do not save test entries
to disk.
Differential Revision: https://phabricator.services.mozilla.com/D34576
--HG--
extra : moz-landing-system : lando
Updated existing "suggestedsites_*" drawables to better match current websites
favicons.
Added new "suggestedsites_*" drawables that are to be used by the localized
Top Sites.
All images are added in density qualified drawable folders which based on my
testing need to range between 90x90px for mdpi to 360x360px for xxxhdpi.
Depends on D34680
Differential Revision: https://phabricator.services.mozilla.com/D34681
--HG--
extra : moz-landing-system : lando
With this changes we must now support 3 Onboarding versions.
With this changes we must now support 3 Onboarding versions.
Latest Onboarding UX will use a new title for the "Sync screen", new subtext,
new image and new text for the signin button.
This will be presented only if all this new Strings are localized.
Refactored the existing OnboardingStringUtil to serve as a central point of
getting the right resources to be used and querying the Onboarding UX version
the app should offer.
Added to SyncPanel the missing logic to hide the space otherwise occupied by
the Onboarding screen message, when there is no message.
(now behaving the same as the other Onboarding screens.)
Applied a lossless compression for the new sync image which resulted in a 26.5%
size reduction.
Removed the lint suppression initially necessary for when first added the
updated Sync Strings which were not used at the moment.
Differential Revision: https://phabricator.services.mozilla.com/D35012
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/util/OnboardingStringUtil.java => mobile/android/base/java/org/mozilla/gecko/util/OnboardingResources.java
extra : moz-landing-system : lando
With this changes we must now support 3 Onboarding versions.
Latest Onboarding UX will use a new title for the "Sync screen", new subtext,
new image and new text for the signin button.
This will be presented only if all this new Strings are localized.
Refactored the existing OnboardingStringUtil to serve as a central point of
getting the right Strings to be used and querying the Onboarding UX version the
app should offer.
Applied a lossless compression for the new sync image which resulted in a 26.5%
size reduction.
Removed the lint suppression initially necessary for when first added the
updated Sync Strings which were not used at the moment.
Differential Revision: https://phabricator.services.mozilla.com/D35012
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/util/OnboardingStringUtil.java => mobile/android/base/java/org/mozilla/gecko/util/OnboardingStringsUtil.java
extra : moz-landing-system : lando
`mozilla.widget.*` was used by old Fennec (Maemo/GTK2). But Android widget doesn't reference this.
### `mozilla.widget.disable-native-theme`
This preference is unused on Android widget. This is for GTK and Windows. Reftests on Android are disabled by `layout/reftests/reftest.list`.
### `mozilla.widget.force-24bpp`
This is unused on Android. This is GTK only.
### `mozilla.widget.use-buffer-pixmap`
No one uses this preference.
Differential Revision: https://phabricator.services.mozilla.com/D33609
--HG--
extra : moz-landing-system : lando
This follows the model set down for EME artifacts:
- a new tier is added that uses a new Python build action to fetch and
artifacts
- the action unpacks the fetched artifacts and moves specific inputs
into places expected by the build and packager
- in automation, MOZ_ARTIFACT_TASK* is used to ensure the artifacts
come from the correct tasks
In this case, the artifact fetching is done entirely in a new Python
build action that internally uses `mach artifact install --job ...`.
The action also verifies that the fetched artifacts are compatible and
that we're not assembling a fat AAR that is nonsensical. The specific
inputs are not used in the Fennec APK that is produced; they're only
used in the GeckoView AAR that is produced.
The artifact fetching itself required tweaking to fetch only
`target.maven.zip` artifacts and to not unpack them.
The specific inputs used are the native libraries (libs/$ARCH/*.so)
and the architecture-specific preference files ($ARCH/greprefs.js and
defaults/pref/$ARCH/geckoview-prefs.js). None of these inputs are
impacted by l10n.
Differential Revision: https://phabricator.services.mozilla.com/D31572
--HG--
extra : moz-landing-system : lando
Because the news strings are unused we need to add them in lint.xml as UnusedResources.
The suppress will be removed it in a future patch.
Differential Revision: https://phabricator.services.mozilla.com/D32979
--HG--
extra : moz-landing-system : lando
This scope now controls add-ons bundled in omni.ja as well as those in the app
directory, so we need to enable it on Fennec in order for the default theme to
work.
Differential Revision: https://phabricator.services.mozilla.com/D32223
--HG--
extra : rebase_source : 3dd7ddec5b73e41dc385e60f2e8f8ce36db5be1b
Bug 1533425 makes Gecko try to load from $ARCH/greprefs.js, etc on
Android. This patch teaches the packager to put certain preferences
into those architecture-specific locations for that code to find.
Differential Revision: https://phabricator.services.mozilla.com/D24984
--HG--
extra : moz-landing-system : lando
We no longer use small cache on mobile, so such small max_entry_size is inadequate.
Differential Revision: https://phabricator.services.mozilla.com/D32104
--HG--
extra : moz-landing-system : lando
Support using the Google Play-provided FIDO2 API for Web Authentication.
FIDO U2F API support is being handled subsequently in Bug 1550625.
This patch uses the privileged APIs and thus will only work on Fennec Nightly, Beta, and Release builds.
Differential Revision: https://phabricator.services.mozilla.com/D1148
--HG--
extra : moz-landing-system : lando
The "Make default browser" setting is now just a button, part of the "General" settings.
We'll remove the layout for 2-pane settings and the now unused String.
Depends on D30468
Differential Revision: https://phabricator.services.mozilla.com/D30469
--HG--
extra : moz-landing-system : lando
Starting from Android O, more fine-grained control over which notifications
should be displayed is available through Android's notification channel system.
To aid discoverability, we add a link to the corresponding settings screen from
inside our own settings menu.
Differential Revision: https://phabricator.services.mozilla.com/D29973
--HG--
extra : moz-landing-system : lando
This image was initially parts of the new Onboarding UX assets but
it is unused at the moment.
Differential Revision: https://phabricator.services.mozilla.com/D30193
--HG--
extra : moz-landing-system : lando
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
Normally when downloading media data we throttle the download only if we're
ahead of the read cursor more than the "readahead limit", and if we estimate
that the connection is fast enough that we'll be able to download at a rate
fast enough to playback in real time if we resume it later.
On mobile we additionally override this so that we always throttle the download
once we're ahead of the read cursor by the readahead limit. This is to save
data. I think we can relax this to only do this override if we're on a
cellular connection; if we're on WiFi we can assume data is cheap.
Differential Revision: https://phabricator.services.mozilla.com/D26234
--HG--
extra : moz-landing-system : lando
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
Normally when downloading media data we throttle the download only if we're
ahead of the read cursor more than the "readahead limit", and if we estimate
that the connection is fast enough that we'll be able to download at a rate
fast enough to playback in real time if we resume it later.
On mobile we additionally override this so that we always throttle the download
once we're ahead of the read cursor by the readahead limit. This is to save
data. I think we can relax this to only do this override if we're on a
cellular connection; if we're on WiFi we can assume data is cheap.
Differential Revision: https://phabricator.services.mozilla.com/D26234
--HG--
extra : moz-landing-system : lando
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
Normally when downloading media data we throttle the download only if we're
ahead of the read cursor more than the "readahead limit", and if we estimate
that the connection is fast enough that we'll be able to download at a rate
fast enough to playback in real time if we resume it later.
On mobile we additionally override this so that we always throttle the download
once we're ahead of the read cursor by the readahead limit. This is to save
data. I think we can relax this to only do this override if we're on a
cellular connection; if we're on WiFi we can assume data is cheap.
Differential Revision: https://phabricator.services.mozilla.com/D26234
--HG--
extra : moz-landing-system : lando
The new Onboarding process will have updated imagery and strings.
It will also not show the "Customize" screen anymore.
It will only be shown if the new Strings are localized;
Differential Revision: https://phabricator.services.mozilla.com/D28863
--HG--
extra : source : 035da268a5d5585c2d7d5996ca7c73263ffdbbc8
The new Onboarding process will have updated imagery and strings.
It will also not show the "Customize" screen anymore.
It will only be shown if the new Strings are localized;
Differential Revision: https://phabricator.services.mozilla.com/D28863
--HG--
extra : moz-landing-system : lando
dlee
Nils Ohlmeier [:drno]
Petru Lingurar
Andrew Creskey
Gurzau Raul
Peter Van der Beken
Makoto Kato
J.C. Jones
Nick Alexander
Tom Ritter
diana.iacos
Oana Pop Rus
Sebastian Hengst
Kris Maglione
Adam Orban
Michal Novotny
Botond Ballo
Vlad Baicu
shindli
Nagy Mihaly
Ciure Andrei
Jan Henning
Chris Pearce
Andreea Pavel
Narcis Beleuzu
Noemi Erli
Kartikaya Gupta