This also adds some belt-and-suspenders checks here so that even if the Migration Wizard
somehow gets confused and sends resource types that the migrator can't import from, they'll
just get ignored rather than having a forever-progress-spinner for that resource type.
Differential Revision: https://phabricator.services.mozilla.com/D173848
Some of this styling requires us to hack around with inline styles from JS since
the <panel-list>, <panel-item>'s and <xul:panel> are slotted. Bug 1823489 has been
filed to investigate not using slotted items to make it easier to style using the
migration-wizard.css stylesheet instead.
Differential Revision: https://phabricator.services.mozilla.com/D173064
Along with bringing us closer to the layout and spacing from Figma, this does the following:
1. Changes the header element to an <h1> and uses CSS to get the expected font size. This should
make the organization of the wizard make more sense to screenreaders.
2. Handles the "single resource" case for Variant 2, where we hide "Select All" and align the
resource list to the left if there's only a single resource to import.
3. Fixes a string to match the spec.
Differential Revision: https://phabricator.services.mozilla.com/D173054
Notably, this also updates the em ratio of the "base" font size and the deemphasized font-size.
In the Figma specification, the base font size is 13px, and the deemphasized font-size is 10px,
which is ~84% of 13px.
Differential Revision: https://phabricator.services.mozilla.com/D172443
Up until now, we've used the connectedCallback to initialize the MigrationWizard. That's
been fine, except that it requires us to remove and then re-add the element to the DOM
if we want to "reset" it and start over.
This patch adds a method "requestState" to the MigrationWizard that kicks off the
initialization. Embedders can set the `auto-request-state` attribute on the
element if they're happy to just use the connectedCallback.
Finally, this adds an intrinsic width to the entire MigrationWizard element to reduce
flicker when transitioning between states.
Differential Revision: https://phabricator.services.mozilla.com/D171742
This will make it easier to use Storybook to simulate how the MigrationWizard is likely to
be used in practice - which is to say, declaratively.
Differential Revision: https://phabricator.services.mozilla.com/D170666
This causes the MigrationWizardChild to request the full collection of available
migrators and user profiles, and then based on which resourceTypes those migrators
and user profiles have available, changes the visibility of the checkboxes in the
selection page of the new MigrationWizard component.
Differential Revision: https://phabricator.services.mozilla.com/D167617
This causes the MigrationWizardChild to request the full collection of available
migrators and user profiles, and then based on which resourceTypes those migrators
and user profiles have available, changes the visibility of the checkboxes in the
selection page of the new MigrationWizard component.
Differential Revision: https://phabricator.services.mozilla.com/D167617
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
