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
When UrlbarView [handles the help command for a result](https://searchfox.org/mozilla-central/rev/863aef60f9fa1536884252ad90cad1d8ee9d8a41/browser/components/urlbar/UrlbarView.sys.mjs#3471-3476), first it determines the
result's help URL. If `result.payload.helpUrl` is defined it uses that, and
otherwise it falls back to generating a default help URL. Either way, then it
sets `menuitem.dataset.url` to the help URL and calls `input.pickResult()`.
Before bug 1883378, `pickResult()` would similarly first check
`result.payload.helpUrl` and then fall back to `menuitem.dataset.url` when
determining the help URL to load. Bug 1883378 changed this behavior so that it
only checks `result.payload.helpUrl`. That means we break any provider that
implements the help command but doesn't define a help URL on its results, like
Yelp and MDN.
One way to fix this would be to make sure providers that implement the help
command always define a help URL on their results. I don't like that idea
because it's nice for providers to be able to rely on a default help URL that's
defined elsewhere.
Another fix would be to always use `menuitem.dataset.url` in `pickResult()` and
don't check `result.payload.helpUrl` at all. That would work for result menu
items, but it wouldn't work for other elements like buttons that don't go
through the result-menu-command path. I don't know if we currently have any such
paths but I don't want to break something else.
So instead I think we should just go back to the status quo before bug 1883378:
First check `result.payload.helpUrl` if the command is help, and then fall back
to `menuitem.dataset.url`.
Differential Revision: https://phabricator.services.mozilla.com/D208197
The toolbar height includes the top border now. It's not what we want
anyways:
* In some cases its usage was completely redundant (we can use the
default static position).
* In other cases what we want is the urlbar-container height, which
doesn't include that border. I confirmed this looks good in compact
mode (which was the reason for introducing this in bug 1580248).
So simplify the code a tiny bit and fix the flickering that got the
original version reverted.
Differential Revision: https://phabricator.services.mozilla.com/D206596
The InputHistory (adaptive) provider is not properly reporting the open tab
userContextId, thus the Muxer is unable to dedupe results properly.
This cleans up the query a little bit avoiding numeric indices and fields that
are unused later.
Differential Revision: https://phabricator.services.mozilla.com/D203012
Fixes code to properly run tests with the feature enabled.
Fixes code not considering payload.userContextId is set to -1 for private
windows.
Fixes a bug in the _openTabs Map where multiple open tabs to the same url are
not properly counted.
Differential Revision: https://phabricator.services.mozilla.com/D200036
#selectedElement may end up pointing to disconnected nodes. And so the public
.selectedElement getter.
This is how it was happening: a first call to onQueryResults adds and selects a
heuristic result. Then a second call to onQueryResults brings a new heuristic
result that requires new content (not compatible with the previous one), so the
old heuristic is emptied out, and new DOM is generated.
Because the code in onQueryResults relies on .selectedElement, at the second
invokation it thinks the selection is still valid, and doesn't select the new
heuristic. In reality .selectedElement at that time is pointing to a removed
DOM node.
The patch introduces a #rawSelectedElement and converts #selectedElement
into a getter.
Plus some minor logging improvements, and removing unused #mainContainer property.
Differential Revision: https://phabricator.services.mozilla.com/D195779
