This makes a number of changes. The main point is to fix the bug, and I did some
refactoring to accomplish that. Summary of changes:
Move submission of the `quick-suggest` ping from `UrlbarProviderQuickSuggest` to
`AdmWikipedia`.
Add `SuggestProvider.onImpression()` and `onEngagement()`.
`UrlbarProviderQuickSuggest` forwards its own impression and engagement method
calls to the methods on the appropriate Suggest features. This is how
`AdmWikipedia` knows when to submit the ping.
Add a `details` param to `UrlbarProvider.onImpression()`, just like
`onEngagement()` already has. This is necessary because
`AdmWikipedia.onImpression()` needs to know whether the result was clicked since
that info is part of the impression ping.
Replace all `SuggestFeature.handleCommand()` implementations with
`onEngagement()`.
Remove `UrlbarProviderQuickSuggest.#dismissResult()`. The only suggestion types
that relied on it were AMP and Wikipedia. I replaced it with dismissal handling
in `AdmWikipedia.onEngagement()`.
Improve the related tests in a few ways: (1) Make the ping check more rigorous
(in `assertQuickSuggestPing()` in `head.js`), (2) simplify expected ping objects
(no more `type` and `payload` properties, just the properties that are expected
in the ping), (3) make `browser_telemetry_gleanEmptyStrings.js` more rigorous,
(4) factor out a helper function to trigger commands in xpcshell tests.
Differential Revision: https://phabricator.services.mozilla.com/D233980
This makes a number of changes to support a new UI treatment for weather
suggestions in addition to the two existing treatments. Unfortunately we need
all three to experiment with, but hopefully after experimentation is done we can
remove the two existing treatments.
This patch refers to the new treatment as the "simplest" UI. The Figma is at [1]
although it doesn't reflect some details Josh and I have discussed. One of the
existing treatments is already called "simple", and this patch changes its name
to "simpler". The patch refers to the other existing treatment as "full". These
names are only informal because the Nimbus variable and fallback pref are
integers.
Because the new UI treatment is so simple, we can pretty much use the standard
rich suggestion UI for it. The existing treatments are dynamic. I say "pretty
much" because I did need to add a capability to rich suggestions,
`result.richSuggestionIconVariation`, which lets results set an `icon-variation`
attribute on their rows. Weather suggestions use it to choose the appropriate
weather icon in the CSS.
I also modified l10n string caching in a few ways to address a couple of
problems:
* I like how dynamic results can cache their strings lazily by setting
`cacheable` in their l10n objects. Standard results can only cache their
strings by adding them to `UrlbarView.#cacheL10nStrings()`. That method is
getting pretty big, and it also doesn't work well with strings that have
arguments since it's called to pre-cache strings before they're used, when
there are no arguments. So I extended `cacheable` support to all l10n objects,
not only those from dynamic results.
* Josh's spec calls for the temperature in the suggestion title to be bolded.
There's no good way to do that right now. We have highlights, but they aren't
useable for l10n strings. The simplest thing -- and what I've done before in
cases like this -- is to include `<strong>` tags in the l10n string itself.
That works except for when we have a cache hit with the l10n cache. In that
case, we set the `textContent`, which of course renders the tag literally. So
I added a `parseMarkup` option to l10n objects that says the cached string
should be set as `innerHTML` instead. Actually, for security I parse the
string into a sanitized document fragment. We could just always do this and
get rid of `parseMarkup`, but it seems wasteful since most l10n strings don't
need it.
* While addressing the previous two points, it made sense to move
`setElementL10n()` from the view to `L10nCache`. That way all these
cache-related functions are together.
Finally, Josh noticed one of the dark-mode colors in the icon SVG didn't have
enough contrast with the standard dark-mode panel background, so I updated that
to a new color he chose (from `#80808F` to `#9393A8`).
[1] https://www.figma.com/design/Hdi0oHB7trRcncyVAKZypO/accuweather-explorations?node-id=3548-15992&t=f4YUShEe5RkP2KEg-1
Differential Revision: https://phabricator.services.mozilla.com/D232703
This patch adds English restrict keyword strings to the enUS-searchFeature.ftl
file. The restrictKeywords providers return an array of keywords for their
l10nRestrictKeywords property. The first is the localized keyword, and the
second is the English keyword. If the user is in the English locale, the
providers return an array with one element: the English keyword.
Differential Revision: https://phabricator.services.mozilla.com/D230009
The method is equivalent to the `setByteStringData` method on `nsIStringInputStream`, which has been used to replace the `.data` setter in these places. There may still be callers of the `.data` getter/setter, however they aren't easy to find.
Differential Revision: https://phabricator.services.mozilla.com/D232257
The method is equivalent to the `setByteStringData` method on `nsIStringInputStream`, which has been used to replace the `.data` setter in these places. There may still be callers of the `.data` getter/setter, however they aren't easy to find.
Differential Revision: https://phabricator.services.mozilla.com/D232257
This is part 3 of 4. It removes the `"remote-settings"` source used internally
and its `rs_` counterpart in telemetry result types.
Depends on D231466
Differential Revision: https://phabricator.services.mozilla.com/D231467
This patch adds the keywords to the result title for TokenAliasEngine and
RestrictKeyword results. The TokenAliasEngine results may have more than one
keyword if the user has set a custom keyword for that engine. This can help
remind the user what keywords are available as they are typing or if they
have forgotten a keyword, they can type `@` to quickly see the list of keywords
to search with.
The result title looks like this:
For Engines:
@[keywords] - Search with [Engine]
For Restrict Keywords:
@[keyword] - Search [Restrict]
Differential Revision: https://phabricator.services.mozilla.com/D224017
This patch adds telemetry for when the user sees or interacts with restrict keyword results.
Following is an overview of the interactions that will trigger the telemetry to be recorded:
When the user types `@` and selects one of the restrict results, the scalar telemetry will be recorded:
- `urlbar.picked.restrict_keyword_tabs`
- `urlbar.picked.restrict_keyword_bookmarks`
- `urlbar.picked.restrict_keyword_history`
- `urlbar.picked.restrict_keyword_actions`
For example, we can select the tabs result in multiple ways for the telemetry to be recorded:
- type`@` and click on tabs result
- type`@` and arrow down to tabs result and press enter
- type partial keyword `@t` and press enter to autofill
- type partial keyword `@t` and press tab and then enter
When the user types `@` and **does not** select one of the restrict results, the glean abandonment will be recorded:
```
groups:
"general,general,general,general,general,general,restrict_keyword,restrict_keyword,restrict_keyword,restrict_keyword",
results:
"search_engine,search_engine,search_engine,search_engine,search_engine,search_engine,restrict_keyword_bookmarks,restrict_keyword_tabs,restrict_keyword_history,restrict_keyword_actions",
```
When the user types `@` and **does** select one of the restrict results, the glean engagement will be recorded:
```
groups:
"general,general,general,general,general,general,restrict_keyword,restrict_keyword,restrict_keyword,restrict_keyword",
results:
"search_engine,search_engine,search_engine,search_engine,search_engine,search_engine,restrict_keyword_bookmarks,restrict_keyword_tabs,restrict_keyword_history,restrict_keyword_actions",
selected_result: `restrict_keyword_${category}`,
```
For the `selected_result` in engagement telemetry, the `category` variable will be `tabs, bookmarks, history, or actions`.
Differential Revision: https://phabricator.services.mozilla.com/D222355
This replaces `UrlbarResult.exposureResultType` and `exposureResultHidden` with
a single simple value called `exposureTelemetry`. Please see the bug for the
rationale.
Other changes:
* For convenience, make `UrlbarPrefs.get("exposureResults")` return a `Set` so
consumers don't have to parse the string value.
* Simplify handling of result properties in `check_results()` (xpcshell tests)
* Add more tasks/checks to test_exposure.js
Depends on D219939
Differential Revision: https://phabricator.services.mozilla.com/D219942
**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
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
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
When the address bar adds a non typed protocol, don't show the urifixup added
protocol to the user, as https-first may upgrade it, and the whole experience
could be confusing for the user.
Differential Revision: https://phabricator.services.mozilla.com/D213443
