We need the .learnMore class here, otherwise the "Learn more" link does
not move to a new line, which is the current behavior.
Differential Revision: https://phabricator.services.mozilla.com/D167419
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 fixes the content cropping. The issue is that when there are
multiple subdialogs, we set the --inner-height of the latest (smaller in
this case) dialog on the dialog stack, overriding the inner-height for
other frames as well.
With XUL layout we flexed anyways instead of honoring the height:
var(--inner-height), which papered over the problem because the dialog
parent had a min-height.
Rework the window modal offset so that we don't need to set the
--inner-height variable on the parent.
Differential Revision: https://phabricator.services.mozilla.com/D166532
`QuickSuggestTestUtils.ensureQuickSuggestInit()` was written before Merino, so
it assumes the suggestion objects passed in are remote settings suggestions.
This revision modifies it so Merino and remote settings suggestions can both be
passed in. That makes it a little nicer for tests that need to test Merino
suggestions in particular, like navigational suggestions, dynamic Wikipedia,
etc.
Another motivation for this change is that it makes it clear which type of
suggestion is being passed to `ensureQuickSuggestInit()`. Unfortunately Merino
suggestion objects are slightly different from remote settings result objects
(`block_id` vs. `id` for example), which are both different from UrlbarResult
objects, and it can be confusing when reading tests. Since "result" is the name
of remote settings objects used internally in the remote settings client, I've
used that term here, and I've updated all callers to use it instead of
"suggestion".
This also makes `MerinoTestUtils` and `QuickSuggestTestUtils` singletons.
Otherwise the new `MerinoTestUtils` instance used inside `QuickSuggestTestUtils`
isn't the same as the one used in the test that calls into
`QuickSuggestTestUtils`, which is very confusing. This made me realize it's a
good idea for these test utils objects to be singletons.
Finally I removed `is_top_pick` handling from the remote settings client and
remote settings suggestions, since the related test is now using Merino. I also
removed `_test_is_best_match` since only one test was using it and it's not
necessary.
Depends on D166019
Differential Revision: https://phabricator.services.mozilla.com/D166050
This patch adds the content blocking pref setting for the level 2 list
pref in private windows. Also, we add tests for the new setting in this
patch.
Depends on D165938
Differential Revision: https://phabricator.services.mozilla.com/D165939
Move most the event handling stuff to the DOM. I've left nsMenuBarFrame
for now, but I will be removing that in the future.
The basic set up is:
* nsMenuParent becomes XULMenuParentElement (menubar or popup, manages
the current active menu item)
* nsMenuFrame -> XULButtonElements that return true for IsMenu().
Can't use XULMenuElement because of <button type=menu>, which
behaves like a, well, menu.
This makes the a11y events for menus (DOMMenuItem{Active,Inactive}) make
sense (before that we were firing duplicate Inactive events etc, and the
event order was rather suspicious).
Differential Revision: https://phabricator.services.mozilla.com/D164210
Move most the event handling stuff to the DOM. I've left nsMenuBarFrame
for now, but I will be removing that in the future.
The basic set up is:
* nsMenuParent becomes XULMenuParentElement (menubar or popup, manages
the current active menu item)
* nsMenuFrame -> XULButtonElements that return true for IsMenu().
Can't use XULMenuElement because of <button type=menu>, which
behaves like a, well, menu.
This makes the a11y events for menus (DOMMenuItem{Active,Inactive}) make
sense (before that we were firing duplicate Inactive events etc, and the
event order was rather suspicious).
Differential Revision: https://phabricator.services.mozilla.com/D164210
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
Our own updater is disabled when running out of an MSIX build, and we hide update related things from preferences because of that.
Differential Revision: https://phabricator.services.mozilla.com/D164671
Our own updater is disabled when running out of an MSIX build, and we hide update related things from preferences because of that.
Differential Revision: https://phabricator.services.mozilla.com/D164671
