***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
This also makes various AutofillRecords methods async, with the exception of
remove() and removeAll().
Noted that I didn't implement any kind of "lock" for FormAutofillStorage --
please do not call these methods concurrently -- if you must please |await|
for the last call to resolve. This most likely would happen in tests, and
shouldn't happen in the real world, given that all user actions happen on
macrotasks, and probably not at the next tick, unless Quicksilver is a
Firefox user.
FormAutofillStorage can be improved if there are complex use cases for it.
Differential Revision: https://phabricator.services.mozilla.com/D4420
--HG--
extra : moz-landing-system : lando
This also makes various AutofillRecords methods async, with the exception of
remove() and removeAll().
Noted that I didn't implement any kind of "lock" for FormAutofillStorage --
please do not call these methods concurrently -- if you must please |await|
for the last call to resolve. This most likely would happen in tests, and
shouldn't happen in the real world, given that all user actions happen on
macrotasks, and probably not at the next tick, unless Quicksilver is a
Firefox user.
FormAutofillStorage can be improved if there are complex use cases for it.
Differential Revision: https://phabricator.services.mozilla.com/D4420
--HG--
extra : moz-landing-system : lando
* Add cc-type as a valid field for credit card forms
* Add a select menu and new string for designating a card type in the add/edit form
* Enforce matching of cc-type to one of the list of supported network ids for Basic Card
* Expose the network ids list as CreditCard.SUPPORTED_TYPES
* Populate the cc-type options using a getCreditCardTypes util method passed into the EditCreditCard constructor
* Web Payment tests: verify cc-type picker is presented, populated as expected and selections received in the response
MozReview-Commit-ID: 9QyU1UwTRay
Differential Revision: https://phabricator.services.mozilla.com/D3830
--HG--
extra : rebase_source : 4ffffa97e845d727f1bfbcc88218992ed7d6c5a0
Based on work by Jared Wein.
A follow-up will handle the persist checkbox and billing address.
Differential Revision: https://phabricator.services.mozilla.com/D4174
--HG--
extra : rebase_source : 2d06beed9083f5f565ed83f8ec0fdcaf66b10eea
Based on work by Jared Wein.
A follow-up will handle the persist checkbox and billing address.
Differential Revision: https://phabricator.services.mozilla.com/D4174
--HG--
extra : rebase_source : ebca2596db11846da171ddc7d34db3dd6e161a6f
Show the labels as placeholders inside of the fields.
Differential Revision: https://phabricator.services.mozilla.com/D2955
--HG--
extra : rebase_source : 4ca24b7b6833c3c1bcd4821ec127fe07c24b44d0
* Provide an cc-exp-year option to match cc-exp-month
* Make cc-number and cc-name required in the basic-card-form
* Disable the basic-card-page save button when the form is invalid.
MozReview-Commit-ID: LjzsnAKJp6R
--HG--
extra : rebase_source : 4dcbee371cd0e30b5823b803c4f4734f897ec786
* Provide an cc-exp-year option to match cc-exp-month
* Make cc-number and cc-name required in the basic-card-form
* Disable the basic-card-page save button when the form is invalid.
MozReview-Commit-ID: LjzsnAKJp6R
--HG--
extra : rebase_source : 467fa09ea07c0234e1839b6dfd7e53375c118104
The point of this is to remove dependencies on privileged code from autofillEditForms.js so it can
be used in the unprivileged PaymentRequest dialog. The PaymentRequest dialog will be able to inject
the privileged APIs in a different way.
MozReview-Commit-ID: 34PvRxzWcSr
--HG--
extra : rebase_source : 610d157c41739eb160ea48ed8fa28627df837424
We want to re-use the field/form logic but not the dialog-specific logic so this separates them out.
Custom Elements aren't enabled by default yet so we can't use them yet.
MozReview-Commit-ID: 60hMpgSOmpp
--HG--
rename : browser/extensions/formautofill/content/editDialog.js => browser/extensions/formautofill/content/autofillEditForms.js
extra : rebase_source : c75c68793e7e37f5fbb7a438d1419632975074fe
