- 20 Mar, 2020 3 commits
-
-
Johan Lorenzo authored
-
Mozilla L10n Automation Bot authored
-
Michael Comella authored
It's better to fail fast on pre-push hooks so devs can get feedback as fast as possible. Assembling is faster than unit testing so we assemble everything first before unit testing.
-
- 19 Mar, 2020 16 commits
-
-
Mozilla L10n Automation Bot authored
-
Sawyer Blatz authored
-
Sebastian Kaspari authored
-
Grisha Kruglov authored
In order to eat the perceived performance costs, we initialize storage once we're visually complete. This way, we're reducing chances of user performing a UI action which will trigger storage init and delay said action.
-
Grisha Kruglov authored
Make sure that we actually lazily initialize our storage layers. With this patch applied, storage layers (history, logins, bookmarks) will be initialized when first accessed. We will no longer block GeckoEngine init, for example, on waiting for the logins storage to initialize (which needs to access the costly securePrefStorage). Similarly, BackgroundServices init will no longer require initialized instances of the storage components - references to their "lazy wrappers" will suffice. In practice, this change changes when our storage layers are initialized in the following ways. Currently, we will initialize everything on startup. This includes loading our megazord, as well. With this change, init path depends on if the user is signed-into FxA or not. If user is not an FxA user: - on startup, none of the storage layers are initialized - history storage will be initialized once, whenever: - first non-customTab page is loaded (access to the HistoryDelegate) - first interaction with the awesomebar - history UI is accessed - bookmarks storage will be initialized once, whenever: - something is bookmarked, or we need to figure out if something's bookmarked - bookmarks UI is accessed - logins storage will be initialized once, whenever: - first page is loaded with a login/password fields that can be autofilled - (or some other interaction by GV with the autofill/loginStorage delegates) - logins UI is accessed - all of these storages will be initialized if the user logs into FxA and starts syncing data - except, if a storage is not chosen to be synced, it will not be initialized If user is an FxA user: - on startup, none of the storage layers are initialized - sometime shortly after startup is complete, when a sync worker runs in the background, all storage layers that are enabled to sync will be initialized. This change also means that we delay loading the megazord until first access (as described above).
-
Aaron Train authored
The Nexus 6 (x86 AVD) on API 25 is causing too many instablility issues. Let’s see what happens with a Nexus 6P on API 27.
-
Gregory Mierzwinski authored
-
mcarare authored
-
mcarare authored
-
mcarare authored
-
MickeyMoz authored
-
Ryan Kelly authored
-
Arturo Mejia authored
-
Arturo Mejia authored
-
Arturo Mejia authored
-
Arturo Mejia authored
-
- 18 Mar, 2020 4 commits
-
-
mcarare authored
-
mcarare authored
-
Mozilla L10n Automation Bot authored
-
liuche authored
Co-authored-by:
Florin Strugariu <bebe@mozilla.ro> Co-authored-by:
Johan Lorenzo <jlorenzo@mozilla.com>
-
- 17 Mar, 2020 9 commits
-
-
Jonathan Almeida authored
In order to target specific variants of Fenix, we're adding schemas that are specific that app in order to avoid collisions with the other variants and with other forks of fenix that may have the same schemas. The current schema for variants: - Fenix Nightly: `fenix-nightly://` - Fenix Beta: `fenix-beta://` - Everything else: `fenix://`
-
Johan Lorenzo authored
-
Sawyer Blatz authored
-
Gregory Mierzwinski authored
* Add visual-metrics docker type. * Add required browsertime toolchain fetches. * Add browsertime tests for technical and visual metrics. * Run browsertime tests in a cron task. * Run visual metrics on all browsertime tests. * Use spaces instead of tabs, and resolve visual-metric nits. * Enable browsertime on pull request for testing. * Restrict PR tests to amazon on browsertime. * First attempt using multi_dep. * Add a primary dependency to browsertime. * Try by not popping. * Debug prints. * Make one grouping per browsertime task. * Try without the multi_dep transform. * Delete dependent-tasks in visual-metrics transformer. * Update setuptools installed and copy run-on-tasks-for. * Use get when getting run-on-tasks-for. * Add new pinned requirements. * Try it. * Set run-on-tasks-for properly. * Remove print statement. * Remove single_dep loader, and print statements. * Remove run-on-tasks-for testing setting. * Restart testing, and set user to root in visual-metrics Docker. * Remove testing settings. * Remove fetch-content from Docker. * Change attributes grouping method. * Run all tests as a check. * Undo testing changes, and fix a bad test name.
-
Christian Sadilek authored
-
Edouard Oger authored
-
MickeyMoz authored
-
Sebastian Kaspari authored
-
Chenxia Liu authored
This reverts commit 090fec20.
-
- 16 Mar, 2020 3 commits
-
-
Severin Rudie authored
* No issue: fixes test broken by snapshot * No issue: ignore flaky tests
-
Tom Prince authored
-
Florin Strugariu authored
-
- 13 Mar, 2020 4 commits
-
-
Christian Sadilek authored
-
isabelrios authored
-
Mozilla L10n Automation Bot authored
-
Jonathan Almeida authored
-
- 12 Mar, 2020 1 commit
-
-
codrut.topliceanu authored
-