Right now, we have no idea how often an origin may offer us multiple alt-svc options. As we are considering racing multiple alt-svc connections (if they're available), it would be good to know how often we actually have (or would have, were we to store them) multiple options available. It would also be good to know how often an origin may change the target of its alt-svc mapping (even if there is only one target), as changes in target may make it useful to store/race multiple targets, as well.
Differential Revision: https://phabricator.services.mozilla.com/D8878
--HG--
extra : moz-landing-system : lando
Delaying the loading of some OS.Constants.Path members to reduce startup
IO is breaking the test_system_delay_update.js test, because it leaves
tmpaddon-* files in the user's temp directory. As far as I can tell this
is okay (please correct me if wrong) - but the error in AddonTestUtils
was being avoided because the OS.Constants.Path.tmpDir value was being
read before we override TmpD for the test. So now we are leaving them
to be ignored in the TmpD directory we specified, rather than leaving
them to be ignored in the user's temp directory.
Depends on D6080
Differential Revision: https://phabricator.services.mozilla.com/D6081
--HG--
extra : moz-landing-system : lando
In bug 1388134 we're lazifying some members of OS.Constants.Path
to avoid the extra startup IO. userApplicationDataDir is ripe for
being made lazy, except it's read early in CrashManager.jsm. This
defers that until it's used, and adjusts the affected tests.
Depends on D6079
Differential Revision: https://phabricator.services.mozilla.com/D6080
--HG--
extra : moz-landing-system : lando
These calls to GetPathToSpecialDir are performing some unnecessary IO
during early startup which we'd like to defer. Simply adding the
required ones to the list in osfile_async_front.jsm should mostly get
us there.
Differential Revision: https://phabricator.services.mozilla.com/D6079
--HG--
extra : moz-landing-system : lando
Depends on D8334.
In this changeset we also change the way we are reading the preferences
in adb-addon.js to avoid caching the value of the preference the first
time the module is loaded.
This allows the module to follow updates of said preferences without
having to restart Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D8335
--HG--
extra : moz-landing-system : lando
Maybe we want to land the simplest solution for now and discuss
quickly how to style the message to reduce confusion in a follow up?
Differential Revision: https://phabricator.services.mozilla.com/D8334
--HG--
extra : moz-landing-system : lando
How often is a successful (native) resolve delayed by a preceeding TRR
failure. (Replaces DNS_TRR_FIRST)
MozReview-Commit-ID: Da8oH53CZTs
Differential Revision: https://phabricator.services.mozilla.com/D8060
--HG--
extra : moz-landing-system : lando
For now, the options panel was calling `attach` to know if the javascript was disabled
on the debugged document. But this property is already cached during the `attach`
request done by the toolbox.
MozReview-Commit-ID: JcDT6vxCUzN
Depends on D8851
Differential Revision: https://phabricator.services.mozilla.com/D8852
--HG--
extra : moz-landing-system : lando
Primary changes:
- Rewrap some lines that are too long.
- Adjust some failure-messages with s/has/should have/ etc.
- Replace 'nearlyEqual' function with the standard mochitest
'isfuzzy()' API (which is like 'is()' with an extra epsilon arg)
- Remove dependence on hardcoded element IDs, and simply walk over the
flex container's children in order instead (still noting each child node
and making sure it matches the node in the flex API).
Differential Revision: https://phabricator.services.mozilla.com/D8933
--HG--
extra : moz-landing-system : lando
In case of loss of OS key store key, we should still allow users to go into the manage credit cards dialog and fill the numbers back in.
This is not the migration strategy, see Part III.
Differential Revision: https://phabricator.services.mozilla.com/D5083
--HG--
extra : moz-landing-system : lando
For Nightly users who already have credit cards saved in their profile, we will do a one-off upgrade of their encrypted credit card number.
This only applies to users who have NO master password set, to avoid showing them the master password prompt when we migrate.
For those who did, we would quietly delete their credit card record from the store.
Differential Revision: https://phabricator.services.mozilla.com/D8029
--HG--
extra : moz-landing-system : lando
Given that the new store is always considered enabled, the not-enabled code
is now dead code. This patch removes them.
Differential Revision: https://phabricator.services.mozilla.com/D5717
--HG--
extra : moz-landing-system : lando
This patch morphs MasterPassword.jsm to OSKeyStore.jsm while keeping the same
API, as an adaptor between the API and the native API exposed as nsIOSKeyStore.idl.
Noted that OS Key Store has the concept of "recovery phrase" that we won't
be adopting here. The recovery phrase, together with our label, allow
the user to re-create the same key in OS key store.
Test case changes are needed because we have started asking for login in
places where we'll only do previously when "master password is enabled".
This also made some "when master password is enabled" tests invalid because
it is always considered enabled.
Some more test changes are needed simply because they previously rely on the
stable order of microtask resolutions (and the stable # of promises for a
specific operation). That has certainly changed with OSKeyStore.
The credit card form autofill is only enabled on Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D4498
--HG--
rename : browser/extensions/formautofill/MasterPassword.jsm => browser/extensions/formautofill/OSKeyStore.jsm
rename : browser/extensions/formautofill/test/browser/browser_creditCard_fill_master_password.js => browser/extensions/formautofill/test/browser/browser_creditCard_fill_cancel_login.js
extra : moz-landing-system : lando
Only we do that. Align with other browsers instead.
I removed the max-asserts as well because I cannot make my browser assert when
running this test on a debug build.
Differential Revision: https://phabricator.services.mozilla.com/D8929
--HG--
extra : moz-landing-system : lando