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
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
