Under Flatpak we cannot determine if the application is set as default handler
for http/https protocols and also the application cannot set the system defaults.
In order to avoid user confusion we hide the defaultBrowserBox which
under flatpak shows always: "Firefox is not your default browser" and the
"Make Default..." button does not make any change to the system.
Differential Revision: https://phabricator.services.mozilla.com/D170590
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
I also renamed migration-dialog.[js|html|css] to migration-dialog-window.[js|html|css] to
make it clearer that those resources are for when the wizard is being shown in a separate
window. I also updated the documentation to reflect this.
Differential Revision: https://phabricator.services.mozilla.com/D169014
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
Replaces the "Recommend extensions as you browse" and
"Recommend features as you browse" XUL labels with the moz-support-link
element.
Differential Revision: https://phabricator.services.mozilla.com/D166467
This patch was made to guard Update functionality from being called in BrowserGlue.jsm if Firefox was not built with support for the Updater. However, it also ended up touching the updater build configuration. I discovered while testing this patch that building with `--disable-updater` does not imply `--disable-maintenance-service` or `--disable-update-agent`. So I fixed that issue as well. Once that was fixed, I could change some other code that checked `AppConstants.MOZ_UPDATER && AppConstants.MOZ_UPDATE_AGENT` since that is now equivilant to `AppConstants.MOZ_UPDATE_AGENT`.
Differential Revision: https://phabricator.services.mozilla.com/D156902
The default download folder prefs are now counterintuitively used
whether browser.download.useDownloadDir is enabled or not, since we no
longer save downloads to the "temp" folder. But the display for these
prefs in about:preferences makes it seem as though the configured path
will not be used if the "Always ask..." option is selected. This patch
removes the radiogroup and replaces it with a checkbox, so that the
download folder path can be changed irrespective of useDownloadDir's
value (unless browser.download.dir is disabled by policy).
Differential Revision: https://phabricator.services.mozilla.com/D143555
The fallback locale is not guaranteed to have all of the strings for
non-fluent files, even if it is one of the available locales. This patch
shares the logic with about:preferences for getting the available
locales.
Differential Revision: https://phabricator.services.mozilla.com/D143910
When downloading a file, we check for existing mime types and construct
a new one if it's unrecognized. Mime types have a flag,
alwaysAskBeforeHandling, that determines whether the unknown content
type dialog should be opened before handling the file. Before bug
1733492, the default value for that flag was simply true. Since the new
downloads flow is intended to avoid unnecessary steps, the default value
was changed to the inverted value of the new downloads panel
improvements pref. This patch adds a new pref that the mime info
constructor will read in configuring the flag's value. If the
improvements pref is not enabled, then the flag will be true, so the UCT
dialog will open. If the improvements pref is enabled, then it'll use
the value of the new pref. Also add a an interface for the pref to the
about:preferences UI, and automatically migrate a false value for
browser.download.improvements_to_download_panel to a true value for this
pref. I'm updating some tangentially related test files since they
happen to be touched slightly by this change. Strictly speaking they
would still work, but if the pref value was somehow changed from the
default they would fail.
Differential Revision: https://phabricator.services.mozilla.com/D143002
When downloading a file, we check for existing mime types and construct
a new one if it's unrecognized. Mime types have a flag,
alwaysAskBeforeHandling, that determines whether the unknown content
type dialog should be opened before handling the file. Before bug
1733492, the default value for that flag was simply true. Since the new
downloads flow is intended to avoid unnecessary steps, the default value
was changed to the inverted value of the new downloads panel
improvements pref. This patch adds a new pref that the mime info
constructor will read in configuring the flag's value. If the
improvements pref is not enabled, then the flag will be true, so the UCT
dialog will open. If the improvements pref is enabled, then it'll use
the value of the new pref. Also add a an interface for the pref to the
about:preferences UI, and automatically migrate a false value for
browser.download.improvements_to_download_panel to a true value for this
pref. I'm updating some tangentially related test files since they
happen to be touched slightly by this change. Strictly speaking they
would still work, but if the pref value was somehow changed from the
default they would fail.
Differential Revision: https://phabricator.services.mozilla.com/D143002
In addition, if someone has pdf set to open internally but then disables the pdf viewer, an error occurs when trying to view a pdf. Handle this case by just asking what to do.
Differential Revision: https://phabricator.services.mozilla.com/D143313
We might want to do this on Windows 11 as well, but Windows 11 has a
system-wide preference with UI so let's not do that just yet at least,
UI-exposed preference.
Differential Revision: https://phabricator.services.mozilla.com/D138502
The new pref app.update.suppressPrompts will allow user to suppress
update-available prompts (popupnotifications) for up to seven days.
Instead, Nightly will display an update badge and banner immediately,
and wait 7 days before showing an interactive prompt. It will also
disable update-restart prompts entirely, instead showing badge and
banner. This also adds telemetry to measure how often these update
prompts are being suppressed via user preference. All of these features
are only enabled on Nightly builds.
Differential Revision: https://phabricator.services.mozilla.com/D135449
I felt somewhat disoriented in the code when ramping up on it, so I
started documenting it with JSDoc as way to better understand the code.
Differential Revision: https://phabricator.services.mozilla.com/D136020
These were all areas that were confusing me when I was onboarding on to
this code, so I tried to make the terminology less ambiguous and more
precise.
The default language is now the primary language.
UI is now appended to words that are dealing with DOM elements rather
than data stores.
Differential Revision: https://phabricator.services.mozilla.com/D136019
