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
