In the patch where I ensure the correct `searchMode` is added, I didn't consider the possibility a user could return to a default SERP. Thus, if there was a search mode chiclet, it should be cleared.
Differential Revision: https://phabricator.services.mozilla.com/D223141
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
There's two main changes:
- Change `getSearchTermIfDefaultSerpUri` to enable it work for any app-provided engine.
- Show the correct Search Chicklet / Unified Search Mode Chicklet when the user loads a non-default SERP. Recall that Persisted Search is enabled in Nightly independent of Scotch Bonnet.
**Issue 1:**
`this.searchMode` is not always known or consistent with the non-default search page when `setURI` is called.
Some scenarios:
- Clear search mode, switch tab, return to the original. The absence of search mode seems acceptable because the user was potentially in the middle of modifying their search or navigating to a URL.
- Clear search mode and reload a non-default SERP.
- Switch search mode, but reload non-default SERP.
- Go back/forward in tabhistory to return to a non-default SERP.
In the latter three cases, if the search terms were to persist again, I'd expect the most accurate search mode to be present.
**Issue 2:**
`userTypedValue` has been used as an indicator for whether or not search terms should persist. However, entering search mode causes userTypedValue to have a value, so that it can be restored when switching back to the current tab and across sessions. Thus, on blur, I have a slightly more complicated check to ensure the revert button is consistent regardless of whether the engine is default or non-default.
**Issue 3:**
Lastly, it's possible for the revert button to show up when switching from tab to tab while the address bar is focused. I added an additional check in this patch since it's a small addition, but I can move it out if it overcomplicates things.
I'm not 100% confident my solution is ideal since I ended up having to add hacky awaits in `browser_UrlbarInput_searchTerms_searchMode.js` for the search mode to appear...
Differential Revision: https://phabricator.services.mozilla.com/D222846
When focusing the urlbar with the mouse we must avoid modifying or
shifting the URL to support operations like double-click or drag to select.
When focusing with the keyboard though we don't have such restrictions
and we can make editing and selection more visually coherent.
This patch is not intercepting commands on mainKeyset, because F6 and
TAB bypass all of that. We instead detect focus following a keydown,
though we must avoid untrimming on TabSelect shortcuts.
Note direct calls to .focus() without a peripheral follow the mouse
behavior, because code (external callers) and tests rely on that.
Differential Revision: https://phabricator.services.mozilla.com/D222138
This switches from the deprecated/removed jsdoc/newline-after-description rule to using the replacement jsdoc/tag-lines rule.
Differential Revision: https://phabricator.services.mozilla.com/D219512
This switches from the deprecated/removed jsdoc/newline-after-description rule to using the replacement jsdoc/tag-lines rule.
Differential Revision: https://phabricator.services.mozilla.com/D219512
**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
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
There's a timing issue where sometimes formatting happens too early on new
windows opening, so we await for the next RAF to happen.
Note there's already a test in browser_UrlbarInput_formatValue_detachedTab.js
covering this, and it's indeed failing intermittently, this may fix it.
The patch also avoids trimming when active mixed content may show a strikeout
https protocol. This is an uncommon state anyway because we block active mixed
content, and in the future we'll rely on the insecure label.
Differential Revision: https://phabricator.services.mozilla.com/D212906
Note this patch changes the urlbar behavior regarding the value put into the
input when a result is selected with the keyboard. We won't trim the value
anymore in most cases.
Trimming makes too easy for the user to transform https into http, and
in general it makes harder to predict the result after editing or copying from
the urlbar after selecting a result.
This resembles the behavior of other mainstream browsers.
The only special case where we still trim the value, is when we add http to a
schemeless user typed value, as we may be using https first, then showing
http would be confusing. Though if trimming the url may transform it into a
search, we still don't trim and accept showing a potentially confusing protocol.
Differential Revision: https://phabricator.services.mozilla.com/D212465
Untrim the address bar value when the user starts manipulating it.
This doesn't untrim on focus, because that would break double-click to select
word, and drag-select. In the future we'll evaluate untrim on focus, but we'll
need additional platform support to replicate that functionality.
The behavior is currently controlled by the feature-gate preference
`browser.urlbar.untrimOnUserInteraction.featureGate`.
Original patch by Marc Seibert.
Differential Revision: https://phabricator.services.mozilla.com/D206135
