This does a few things to support this new behaviour:
1. Adds the ability for about:preferences category modules to indicate that
they want to specially handle subcategories. In this particular case, it
causes the "migrate" subcategory of the "general" category to open up the
migration dialog.
2. Updates MigrationUtils to open about:preferences#general-migrate if the opener
is a tabbrowser window.
3. Adds some utility functions to make writing tests easier.
4. Updates existing tests to expect the wizard to be opened in the about:preferences
subdialog.
5. Makes pressing "Escape" close the migration wizard when it's loaded in the
migration-dialog.html document.
Differential Revision: https://phabricator.services.mozilla.com/D167873
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
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
It seems that at build time, we already make decisions about what migrators we register
with XPCOM in browser/components/migration/components.conf. This doesn't, however, give
us the ability to turn off a migrator that happens to be misbehaving, nor make it easy
for us to do development of a new migrator without exposing it to the migration dialog
(without doing binary recompiles).
This adds another layer to the enable-ment of our migrators so that they must both
be registered AND enabled in order to appear in the import dialog.
Differential Revision: https://phabricator.services.mozilla.com/D159544
Before bug 1792730, we didn't look at style.minWidth, even though this
dialog used it (but contents can be larger).
Using scrollWidth is the right thing to do here. Also fix some other
hard-coded widths I found while at it.
Differential Revision: https://phabricator.services.mozilla.com/D158462
