this.searchMode can return null even if a search mode is shown
in the address bar, as the getter uses the current browser as the
context and attempts to use the state data. I try to solve this
by relying on the fact that a tab switch and invalid pageproxystate
results in restoring the search mode state.
Differential Revision: https://phabricator.services.mozilla.com/D228483
Keep using the static position as we did before. As long as we don't
have anchor positioning this seems better than whack-a-mole-ing every
possible urlbar position change.
In order to make the fullscreen animation work, make our position
computation ignore transforms, which is how anchor positioning would
behave anyways.
Differential Revision: https://phabricator.services.mozilla.com/D227758
This was a pre-existing issue that was only papered by chance.
this._toolbar is set before the early return for readonly urlbars, but
the ResizeObserver is only set up after it.
Be more explicit about when we allow breaking out of the container (and
effectively do it only for non-readonly urlbars).
Differential Revision: https://phabricator.services.mozilla.com/D227760
The static position of these boxes is not great to depend upon, see:
https://github.com/w3c/csswg-drafts/issues/9939
Right now, we are relying on the static pos to be properly set which is
going to go away, eventually, and it is bogus, because it doesn't update
if e.g. only transform changes.
Use getBoxQuads to get the content box bounds properly. Also, make
breakout position: absolute explicitly, to prevent confusion.
Differential Revision: https://phabricator.services.mozilla.com/D226932
The static position of these boxes is not great to depend upon, see:
https://github.com/w3c/csswg-drafts/issues/9939
Right now, we are relying on the static pos to be properly set which is
going to go away, eventually, and it is bogus, because it doesn't update
if e.g. only transform changes.
Use getBoxQuads to get the content box bounds properly. Also, make
breakout position: absolute explicitly, to prevent confusion.
Differential Revision: https://phabricator.services.mozilla.com/D226932
* Fix various z-index/paint order issues by making the urlbar a popover - which moves the open
urlbar to the top layer, outside the toolbox
* Adjust the urlbar position when the autohide menubar shows and hides
* Temporarily disable the browser_urlbar_keyed_search.js which needs revisiting to measure reflows under regular, non-test-specific conditions
Combines work from nsharpley and sfoster on top of emilio's original popover patch
Differential Revision: https://phabricator.services.mozilla.com/D224201
* Fix various z-index/paint order issues by making the urlbar a popover - which moves the open
urlbar to the top layer, outside the toolbox
* Adjust the urlbar position when the autohide menubar shows and hides
Combines work from nsharpley and sfoster on top of emilio's original popover patch
Differential Revision: https://phabricator.services.mozilla.com/D224201
- `urlbar.searchmode.typed`: suffixed with "keyword" for restrict keyword entries and "symbol" for symbol entries.
- `urlbar.searchmode.keywordoffer`: suffixed with "keyword" for restrict keyword entries via keywordoffer.
- Example: History search mode scalar key is `history_keyword` for restrict keyword and `history_symbol` for symbol.
Differential Revision: https://phabricator.services.mozilla.com/D223210
The main goal is to simplify the logic in setURI, and create a more easier to understand flow of operations.
It involves making Persisted Search more contained, offload some responsibilities to UrlbarSearchTermsPersistence, and store fewer state variables than the patch that was first reviewed. I also simplified code in UrlbarSearchTermsPersistence.
**How Search Terms Persist:**
**Step 1**
When the page first appears, set state for search terms persistence. First load doesn't necessarily mean no tab switch or same page load, as a user could load a browser in the background tab. In that latter case, the first "view" may occur on a tab switch and the state won't exist because `setURI` will never have been called with that browser object being selected.
Once the state has been set, the only property that could be updated is `shouldPersist`. Otherwise, don't update the state object unless a full new page load occurs.
**Step 2**
Call `shouldPersist`. This has all the logic for when search terms should persist and gets called anytime `setURI` is called.
The conditions in which we shouldn't persist:
- There's no reason to show search terms:
- The persist state is missing.
- There are no search terms extracted from the URL.
- We need to temporarily hide the search terms, such as by handleRevert
- `hideSearchTerms` is provided to setURI
- There is an user typed value and it differs from the search terms
- A single page application moved to a secondary page
- After the initial page load, there's the search mode (or lack of search mode) differs from the persist engine.
**Step 3**
Determine if we need to update `this.window.gBrowser.userTypedValue`. If we're going to persist, set `userTypedValue` to the search terms, which will keep the search mode and non-search mode state consistent. This'll also enable the ability to reuse existing logic that determines how to set `value`.
On same page loads, when switching from persist to non-persist, and search term equals the userTypedValue, then `null` the userTypedValue so that the URL shows.
**Step 4**
In the area of setURI which has logic for search mode, if we persist, ensure the search mode (or lack of search mode) is consistent with the engine. If it is, do nothing. If it isn't, either nullify the search mode or enter search mode.
Differential Revision: https://phabricator.services.mozilla.com/D224520
- `urlbar.searchmode.typed`: suffixed with "keyword" for restrict keyword entries and "symbol" for symbol entries.
- `urlbar.searchmode.keywordoffer`: suffixed with "keyword" for restrict keyword entries via keywordoffer.
- Example: History search mode scalar key is `history_keyword` for restrict keyword and `history_symbol` for symbol.
Differential Revision: https://phabricator.services.mozilla.com/D223210
- `urlbar.searchmode.typed`: suffixed with "keyword" for restrict keyword entries and "symbol" for symbol entries.
- `urlbar.searchmode.keywordoffer`: suffixed with "keyword" for restrict keyword entries via keywordoffer.
- Example: History search mode scalar key is `history_keyword` for restrict keyword and `history_symbol` for symbol.
Differential Revision: https://phabricator.services.mozilla.com/D223210
The purpose of this change is to cache persist state into an object so that in future patches, I can add other persisted search related state to it.
Differential Revision: https://phabricator.services.mozilla.com/D224122
The main purpose of this patch is to make the visibility of the revert button consistent to make it more accessible. After talking with Josh, we agreed the revert icon should always show in an `invalid` pageproxystate until `userTypedValue` differs from the search string. Doing so will make the Revert button be more predictable for keyboard users instead of hiding it when the input field is focused and then showing it again when they press tab (or not making it focusable at all).
The Go button (the right arrow button) will show up again once the user has modified the search terms. I didn't think this would be much of an issue since the Go arrow is not focusable by keyboard, it's not visible when the address bar is not focused, and "Enter" is a well known shortcut to doing the same function.
This involved checking when `persistsearchterms` was changed to `false` and removing it to instead remove `persistsearchterms` when the search terms changed. This is reflected in the new expected behavior in the tests.
One issue was adding `focus` to the revert button via CSS caused focus issues. Tabbing from the left elements (reload button) to the input would skip the input altogether and go straight to the revert button and then to the Save to Pocket button. Pressing shift + tab to try and go back from the revert button to the input would get stuck in a loop between the input field and revert button. This was fixed with `<toolbartabstop/>` . I created a hideable container to ensure the tabstop only exists when the `persistsearchterms` state is active. And the new test checks that the tab behaviour is consistent.
Lastly, because keyboard users might press the Revert button, focusing the input seemed like a logical choice, or else when the focus is lost the user would need to tab all the way back to the input to do more actions. There is also an initiative to move inline Javascript out from markup.
Differential Revision: https://phabricator.services.mozilla.com/D223423
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
