We have no XUL throbbers anymore, so remove the html difference.
We could use <img srcset="..."> instead of image-set() in css, though
that'd mean a bit of duplication in about:preferences at least.
Differential Revision: https://phabricator.services.mozilla.com/D169457
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 changes about:neterror to show a specific error page when the DNS failure
occurs for a TRR mode3 page load. This offers the user more information about
the failure, and some options.
This page will be further improved at a later stage when we add a better
DNS over HTTPS settings page.
The page is visible when the browser is using DNS over HTTPS without fallback
to native DNS. To achieve this the user sets `network.trr.mode` to `3` then
loads a page such as `http://nonexistant.test`.
If a top level load's channel returns NS_ERROR_UNKNOWN_HOST we look at
whether the page was indeed loaded with an effectiveTRRMode == TRRONLY
(some loads are excluded from using TRR).
When that is true, we present the error page allowing the user to retry,
exclude the domain from TRR, or open the settings page.
Note: This initial implementation will not work if the
`network.dns.disablePrefetch` pref is set to true. In that case nsHttpChannel
does not get an OnLookupComplete callback, so it doesn't have the
effectiveTRRMode and trrSkipReason. This will be fixed in bug 1805372.
Project plan: https://docs.google.com/document/d/12IGABt1eXI276qHduXXbVZqRFrhLN7Ad3gKEgxz81sE
Copy deck: https://docs.google.com/document/d/130UTox8bQbybjYIwvltR4qBg2hWjsGhuNUHypLwUAEQ
Depends on D164642
Differential Revision: https://phabricator.services.mozilla.com/D164347
This changes about:neterror to show a specific error page when the DNS failure
occurs for a TRR mode3 page load. This offers the user more information about
the failure, and some options.
This page will be further improved at a later stage when we add a better
DNS over HTTPS settings page.
The page is visible when the browser is using DNS over HTTPS without fallback
to native DNS. To achieve this the user sets `network.trr.mode` to `3` then
loads a page such as `http://nonexistant.test`.
If a top level load's channel returns NS_ERROR_UNKNOWN_HOST we look at
whether the page was indeed loaded with an effectiveTRRMode == TRRONLY
(some loads are excluded from using TRR).
When that is true, we present the error page allowing the user to retry,
exclude the domain from TRR, or open the settings page.
Note: This initial implementation will not work if the
`network.dns.disablePrefetch` pref is set to true. In that case nsHttpChannel
does not get an OnLookupComplete callback, so it doesn't have the
effectiveTRRMode and trrSkipReason. This will be fixed in bug 1805372.
Project plan: https://docs.google.com/document/d/12IGABt1eXI276qHduXXbVZqRFrhLN7Ad3gKEgxz81sE
Copy deck: https://docs.google.com/document/d/130UTox8bQbybjYIwvltR4qBg2hWjsGhuNUHypLwUAEQ
Depends on D164642
Differential Revision: https://phabricator.services.mozilla.com/D164347
This changes about:neterror to show a specific error page when the DNS failure
occurs for a TRR mode3 page load. This offers the user more information about
the failure, and some options.
This page will be further improved at a later stage when we add a better
DNS over HTTPS settings page.
The page is visible when the browser is using DNS over HTTPS without fallback
to native DNS. To achieve this the user sets `network.trr.mode` to `3` then
loads a page such as `http://nonexistant.test`.
If a top level load's channel returns NS_ERROR_UNKNOWN_HOST we look at
whether the page was indeed loaded with an effectiveTRRMode == TRRONLY
(some loads are excluded from using TRR).
When that is true, we present the error page allowing the user to retry,
exclude the domain from TRR, or open the settings page.
Note: This initial implementation will not work if the
`network.dns.disablePrefetch` pref is set to true. In that case nsHttpChannel
does not get an OnLookupComplete callback, so it doesn't have the
effectiveTRRMode and trrSkipReason. This will be fixed in bug 1805372.
Project plan: https://docs.google.com/document/d/12IGABt1eXI276qHduXXbVZqRFrhLN7Ad3gKEgxz81sE
Copy deck: https://docs.google.com/document/d/130UTox8bQbybjYIwvltR4qBg2hWjsGhuNUHypLwUAEQ
Depends on D164642
Differential Revision: https://phabricator.services.mozilla.com/D164347
<menulist> still uses legacy XUL layout (for reasons, I plan to fix it
but it can take a little bit).
The issue here is a poor interaction between one of the wrapping hboxes
and the xul layout. But we can simplify the code and fix the bug at the
same time, so do that.
Differential Revision: https://phabricator.services.mozilla.com/D159254
That was presumably the intention of the explicit width in the CSS but
that wasn't working.
While at it, use a proper deck rather than a hand-rolled one.
Differential Revision: https://phabricator.services.mozilla.com/D158223
This patch adds a state to AppUpdater to represent when an internal error has occurred. It also adds the appropriate code to the Update UI to be able to handle this state, along with a panel in each UI and a string that can go in the panels to convey to the user that update has failed.
Ideally, it would be good if this message also directed the user to a SUMO article. See Bug 1787309 for details on this. But at the moment, I would prefer to address Bug 1756450 quickly rather than wait for that to be ready.
Differential Revision: https://phabricator.services.mozilla.com/D156998
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
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
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
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
