It turns out we just had these two values wrong. Using the Keychain Access utility
on macOS, I was able to find the right values for both browsers and then do a
successfull password import from each.
Notably, both Opera and Opera GX share the same Keychain service and account
name despite being two separate products.
Differential Revision: https://phabricator.services.mozilla.com/D165180
Opera hasn't shipped Opera GX on Linux (yet), so it doesn't make sense to support it on that
platform since it can't be tested.
Depends on D164372
Differential Revision: https://phabricator.services.mozilla.com/D164373
Now that deCOM'ing migration is done, these comments can be removed. At the time of writing
those comments, it might have been reasonable to move those methods out at the same time as
deCOM'ing, but I don't want to blow out the scope of this patch series, so we can leave those
cleanups to some other time.
Depends on D164143
Differential Revision: https://phabricator.services.mozilla.com/D164144
Opera hasn't shipped Opera GX on Linux (yet), so it doesn't make sense to support it on that
platform since it can't be tested.
Differential Revision: https://phabricator.services.mozilla.com/D164373
Now that deCOM'ing migration is done, these comments can be removed. At the time of writing
those comments, it might have been reasonable to move those methods out at the same time as
deCOM'ing, but I don't want to blow out the scope of this patch series, so we can leave those
cleanups to some other time.
Differential Revision: https://phabricator.services.mozilla.com/D164144
This doesn't do a thorough job of actually documenting things, it just makes sure that
the existing documentation abides by the JSDoc formatting rules. I did flesh out some
documentation here and there, but writing new / updating / clarifying documentation is
left as later work.
Differential Revision: https://phabricator.services.mozilla.com/D163133
This adds:
1. A new <migration-wizard> component
2. A new migration-dialog.html document that loads it
3. JSWindowActors for communicating between whatever process the migration-wizard is
loaded in and the parent process. The actors are currently restricted to running
in these documents:
about:welcome
about:preferences
chrome://browser/content/migration/migration-dialog.html
4. A very small, simple mochitest-chrome test for testing the widget
5. Some Fluent strings for the new <migration-wizard>, dropped into a new folder in
/browser called "locales-preview". This is so that both the jar packaging can
put the Fluent file somewhere sensible that doesn't (currently) require our
localizers to translate, but also so that Storybook can load that Fluent file.
6. Modifications to our Storybook infrastructure so that attempts to load items
from locales-preview will map to the browser/locales-preview folder.
7. A Storybook story for the <migration-wizard> that puts it in a few basic states.
Most of those states aren't actually implemented yet, but are left in the story to
make it easier to develop those states in the component.
The hope is that when this is done, it should be relatively straight-forward to
embed the <migration-wizard> not just in the migration-dialog.html document (which
is used for tab modals and the stand alone migration dialog), but also in existing
in-content pages like about:welcome and about:preferences.
For those worried about the TODO strings or incomplete behaviour, remember that this
is just a base for building upon, and that this component / dialog isn't actually
exposed to users yet.
The dialog can be opened manually via:
```lang=js
gBrowser.getTabDialogBox(gBrowser.selectedBrowser).open("chrome://browser/content/migration/migration-dialog.html")
```
and see the documentation in browser/components/storybook/README.md for guidance on
how to view this component using Storybook.
Differential Revision: https://phabricator.services.mozilla.com/D162623
