This is an unusual revision, but it adds a checkbox to the Search Suggestions
section of the Search pane for the urlbar Quick Suggest experiment, which is
en-US only. The checkbox is hidden by default and it's only shown if the
`browser.urlbar.quicksuggest.enabled` pref, which controls the experiment, is
true. Because this is an experiment and it's en-US only, I've hardcoded some
strings. Bug 1692518 has info on the experiment, and bug 1693345 has a
discussion about hardcoding strings.
The checkbox controls the new pref `browser.urlbar.suggest.quicksuggest`. It's
similar to the other existing `browser.urlbar.suggest.*` prefs.
There's a learn-more link but we don't know the final URL yet, so I'm using
mozilla.org. There's a TODO with a bug number.
We also want to change the Search Suggestions description when the experiment is
enabled. I've hardcoded that new string, too.
The test is pretty thorough and I started writing it before the new prefs
landed, so it doesn't assume the prefs exist or which branch they're on.
Differential Revision: https://phabricator.services.mozilla.com/D105701
Introduce a new `browser.urlbar.showSearchSuggestionsFirst` boolean pref that
determines whether search suggestions are shown before general results.
This keeps the `matchBuckets` pref. I could have removed it since the only thing
we're using it for right now is to tell whether suggestions are shown first. The
reason I didn't remove it is because ultimately we do want a `matchBuckets` or
`resultBuckets` pref so we can experiment with different results compositions
using simple pref-flip studies. Hopefully bug 1676469 will land soon and we'll
replace `matchBuckets` with `resultBuckets`, but in the meantime I think we
should keep `matchBuckets` around.
This also removes some `browser.urlbar.matchBuckets` assignments in tests that
don't actually depend on it. For tests that do depend on it, I changed them so
they set `showSearchSuggestionsFirst` now.
Differential Revision: https://phabricator.services.mozilla.com/D103137
The problem is that a few sites assume that `lastIndex` is the index of the last
engine in the tree, but since bug 1657790 landed, `lastIndex` is now the index
of the last local shortcut.
Differential Revision: https://phabricator.services.mozilla.com/D100299
* Add prefs for each local search shortcut
* Remove the `update2.localOneOffs` pref since it's not necessary with the three
new prefs
* Modify preferences UI by adding a new row in the engines tree for each local
shortcut
* Add `UrlbarUtils.LOCAL_SEARCH_MODES` so we have a single place where local
search modes and their properties are defined
* Add a new test file for the preferences UI
* Modify browser_oneOffs.js to test the three new preferences
Differential Revision: https://phabricator.services.mozilla.com/D97376
This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
Using `visibility` preserves frames of the content inside the dialog,
which we rely on to print the preview `<browser>` element.
This was working before bug 1662336 mostly by chance, because we were
doing an extra clone and that happened to mostly not rely on the cloned
document being rendered.
I'd rather fix it in the front-end (by not trying to print a
`display: none` <browser>) than going back to do a separate clone,
because that can get expensive (specially with fission).
It's not super-clear to me how to best test the "print from system
dialog" case, but ideas certainly welcome.
Differential Revision: https://phabricator.services.mozilla.com/D95501
This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
Using `visibility` preserves frames of the content inside the dialog,
which we rely on to print the preview `<browser>` element.
This was working before bug 1662336 mostly by chance, because we were
doing an extra clone and that happened to mostly not rely on the cloned
document being rendered.
I'd rather fix it in the front-end (by not trying to print a
`display: none` <browser>) than going back to do a separate clone,
because that can get expensive (specially with fission).
It's not super-clear to me how to best test the "print from system
dialog" case, but ideas certainly welcome.
Differential Revision: https://phabricator.services.mozilla.com/D95501
Using `visibility` preserves frames of the content inside the dialog,
which we rely on to print the preview `<browser>` element.
This was working before bug 1662336 mostly by chance, because we were
doing an extra clone and that happened to mostly not rely on the cloned
document being rendered.
I'd rather fix it in the front-end (by not trying to print a
`display: none` <browser>) than going back to do a separate clone,
because that can get expensive (specially with fission).
It's not super-clear to me how to best test the "print from system
dialog" case, but ideas certainly welcome.
Differential Revision: https://phabricator.services.mozilla.com/D95501
