**Description**
- Add autofill functionality to UrlbarProvider Restrict Keywords.
**Acceptance Criteria**
- There are 3 restrict keywords `@history`, `@bookmarks`, and `@tabs`
- When the user types @ followed by the beginning of the search keyword: `@h`, `@hi`, `@his`, `@hist` etc. the user should be able to autofill the rest of the search by pressing tab
- The autofill should highlight the typed letters from the user, and show the entire keyword following what the user typed. For example:
- If the user typed `@hist` , autofill should highlight what the user typed and show the rest of the keyword `@history`:
**Example steps to test `@history` :**
- set `browser.urlbar.searchRestrictKeywords.featureGate` to true
- type out the full keyword and space `@history` , address bar should show results panel with history results
- type `@h` and press right arrow, shows results panel with history results
- type `@h` and press enter, shows results panel with history results
- type `@h` and press tab, does not show panel but selects the history restrict result. When the user starts typing, it will search their history and show results panel with history results
Differential Revision: https://phabricator.services.mozilla.com/D218742
The main thing this does is add a task to the Fakespot engagement telemetry test
that triggers both a Fakespot and history result and then clicks the history
result. I want to make sure the Fakespot engagement event isn't incorrectly
recorded. (I thought it might be but it's not.)
This also has a bunch of changes from http to https. Lint made me change the
URLs in the Fakespot test to https, which was a problem for the AMP result since
`QuickSuggestTestUtils.ampRemoteSettings()` uses http URLs. So I went ahead and
updated that function plus the other ones and all the places that are affected.
Depends on D217780
Differential Revision: https://phabricator.services.mozilla.com/D217887
Keep supporting the pref makes a lot of `click`, `auxclick` and `contextmenu`
event creators complicated (and look messy). So, let's delete it as soon as
possible.
Differential Revision: https://phabricator.services.mozilla.com/D217225
This patch includes:
- A new UrlbarProviderRestrictKeywords class
- Showing localized Search with Bookmarks, Search with History, Search with Tabs results after the user types @
- Add search restrict keywords to preferences UI Search Shortcuts table
- Hiding search restrict keyword behind browser.urlbar.searchRestrictKeywords.featureGate pref
Differential Revision: https://phabricator.services.mozilla.com/D213697
There are a few ways to solve this problem and I tried to take a straightforward
approach. This patch makes text highlighting less automagical and surprising. It
forces dynamic-result providers to specify highlighted text content as part of
their view updates just like all other non-highlighted text and other
properties. To trigger highlighting, the view update can include a new
`highlights` property.
Except for Fakespot, there currently aren't any providers that take advantage of
the existing automagical highlighting behavior.
Depends on D216370
Differential Revision: https://phabricator.services.mozilla.com/D217020
We no longer need to start the add-on manager before the search service starts, so init it only when it is needed for installing add-ons.
Differential Revision: https://phabricator.services.mozilla.com/D216406
This leaves out `security.insecure_connection_text.enabled` and
`security.insecure_connection_text.pbmode.enabled`, that should also be part of
ScotchBonnet, but are managed by a different component.
Differential Revision: https://phabricator.services.mozilla.com/D216181
Shifting the input field position on mousedown can easily cause unwanted text
selection. We can avoid that by delaying pageproxystate change to mouseup, and
using an attribute to postpone other display changes.
Differential Revision: https://phabricator.services.mozilla.com/D215930
Please see the bug for context. This changes how ingest works. Right now we
ingest all "default" suggestion types at once. This patch causes a suggestion
type to be ingested only when it's enabled.
Before this patch, there are two times ingest happens, on startup and when the
ingest timer fires.
With this patch, there are now a few times ingest happens:
* On startup (as before). `SuggestBackendRust` will ingest all registered and
enabled suggestion types.
* When the ingest timer fires (as before). Similar to startup, all registered
and enabled types will be ingested.
* When a suggestion type becomes enabled. I added this functionality to
`BaseFeature.update()` so that each feature gets this behavior automatically.
It's worth saying more about the startup case. On startup, all `BaseFeature`s'
initializations race each other. `SuggestBackendRust` is itself a `BaseFeature`,
so there's no guarantee it will be initialized before other `BaseFeature`s that
implement Rust suggestions. If any `BaseFeature`s are initialized before
`SuggestBackendRust`, they'll try to ingest but nothing will happen because
`SuggestBackendRust` won't be initialized yet. Once `SuggestBackendRust` is
initialized, it will ingest suggestions for all registered `BaseFeature`s that
already tried and failed to ingest. And after `SuggestBackendRust` initializes,
any `BaseFeature`s that are initialized later will be able to successfully
ingest.
Differential Revision: https://phabricator.services.mozilla.com/D216488
We need to do this now that we're creating FTS tables. I believe this
should fix the vendoring issues. The following tests were failing
before and now are succeeding on my machine:
./mach test browser/components/urlbar/tests/quicksuggest/unit
./mach test browser/components/search/test/browser/telemetry/browser_search_telemetry_sources.js
Differential Revision: https://phabricator.services.mozilla.com/D216598
