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
**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
My initial assumption about when to show the protocol box were not properly
accounting for the case of a disabled insecure label, and that's why the test
is failing on Beta.
If the insecure label is enabled we never want to show the protocol box, in
the other cases we almost always want to show it, unless the protocol has been
trimmed, or formatting is disabled and we're in active mixed content mode.
All of this won't matter anyway once we start shipping the insecure label by
default, and at a certain point we should remove the pref to disable it.
Differential Revision: https://phabricator.services.mozilla.com/D214581
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
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
This patch refactors the SearchService private initialized variables and how
the SearchService stores its initialization status. These changes capture whether
the SearchService has succeeded, failed or hasn't finished initialization yet.
There are also changes made to UrlbarSearchUtils on handling when SearchService
has failed to initialize or when it hasn't finished initializing yet and we wait.
In the case where the SearchService has failed on initialization, We allow
the code to continue so that it can reach UrlbarProviderPlaces. Once we
are able to reach UrlbarProviderPlaces, we can make database calls for the user's
history and bookmarks. This allows the user to interact with the addressbar and
search their history and bookmarks even if SearchService has failed to initialize.
Differential Revision: https://phabricator.services.mozilla.com/D176936
Update the urlbar text overflow direction calculation after recent scrollend
changes do not result in scrollend events fired for scrolls that do not change
the scroll position.
Depends on D160156
Differential Revision: https://phabricator.services.mozilla.com/D161846
Update the urlbar text overflow direction calculation after recent scrollend
changes do not result in scrollend events fired for scrolls that do not change
the scroll position.
Depends on D160156
Differential Revision: https://phabricator.services.mozilla.com/D161846
