1517140 - Notify the user we can't use a keyword that conflicts with a restriction token

Status: NEW

(Firefox :: Address Bar, defect, P5)

Description

[Molly Harris]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

I created a bookmark, with values:

NAME: "?: Search Google"
LOCATION: "https://www.google.com/search?num=30&newwindow=1&source=hp&btnK=Google+Search&q=%s"
TAGS: empty
KEYWORD: ?

I then typed:

? test search

into the address bar.


Actual results:

Results came up in the default search engine for

"? test search"


Expected results:

The Google results should've come up for

"test search"

Comment 1

[Molly Harris]

The question mark keyword is sort of built into my muscle memory -- I've used it for literally decades, and it has been a pain to break.  This may be a regression, as I know it worked in prior Firefox incarnations.  While there are workarounds, such as retraining my fingers or habits to use "g" or simply to type the query without the search keyword, that shouldn't be necessary.

Comment 2

[Molly Harris]

If keyword.enabled is set as false, but the bookmark is still as described above, searching "? test string" produces an "invalid URL" page.

Comment 3

[Gingerbread Man]

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=99df2932f5d5d0030c9132337ab117bcc4a0fc99&tochange=4ff8166e26697789c95de2b03d45893e4ba90f87

(In reply to Mike Harris from comment #0)
> Actual results:
> 
> Results came up in the default search engine

This is a consequence of ? now being used to restrict address bar matches to search suggestions only. It used to be possible to customize the restriction characters, but unfortunately bug 1376986 took that away.

(In reply to Mike Harris from comment #2)
> If keyword.enabled is set as false, but the bookmark is still as described
> above, searching "? test string" produces an "invalid URL" page.

That's to be expected with keyword.enabled = false.

Comment 4

[Molly Harris]

(In reply to Gingerbread Man from comment #3)
> https://hg.mozilla.org/integration/autoland/
> pushloghtml?fromchange=99df2932f5d5d0030c9132337ab117bcc4a0fc99&tochange=4ff8
> 166e26697789c95de2b03d45893e4ba90f87

Following a few links into this, I see that this indicates that "$" restricts searches to URLs and "?" to search suggestions.

I would advocate that if a question mark (or, for that matter, dollar sign) is explicitly used as a keyword, that it overrides this behavior -- especially since such a use would be a user's explicit intention, whereas the dollar sign and question mark doesn't seem to even be well-documented (at least not from a cursory Google search).

At the very least, a less desirable (for me at least) fallback would be for Firefox to advise users, upon attempting to use a question mark or dollar sign as a keyword, that such is not allowed.  To fail silently and simply not work is not a desirable outcome.

> > If keyword.enabled is set as false, but the bookmark is still as described
> > above, searching "? test string" produces an "invalid URL" page.
> 
> That's to be expected with keyword.enabled = false.

I don't understand.  What documentation I can find on this suggests that keyword.enabled, after keyword.url was removed, now controls sending whether, if it can't be resolved as a domain, the entered string is sent to the chosen search engine or simply fails out.  But if keyword.enabled is set as false, I would think that giving the text entered in the address bar to an explicitly defined bookmark keyword would be what happened next.

Comment 5

[Gingerbread Man]

(In reply to Mike Harris from comment #4)
> (In reply to Gingerbread Man from comment #3)
> > That's to be expected with keyword.enabled = false.
> 
> I don't understand.

To put it differently, there's no additional issue: it's still a question of the "?" bookmark keyword being ignored. With keyword.enabled = false, typing "gingerbread man" into the address bar and pressing Enter results in an "Invalid URL" error page. That's the expected result, with the bookmark keyword taken out of the equation.

Comment 6

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

This is a longstanding bug, keywords or search aliases may conflict with restriction chars, and usually restrictions chars win, because they are a specific feature of the Address Bar. This is even more important for "?" that has been used by most users from the beginning as a way to force a search even on url-looking strings ("..just add a question mark!")
Bookmark keywords and engine aliases are less critical, mostly a niche featurem the fact they can conflict with restriction chars is a known limitation, from the beginning of their existence.

What you suggest, that we tell the user that certain chars can't be used as keywords, is surely a good suggestion, that was also brought out in the past, that's not a trivial change though, and thus nobody ever found the time to do it (again, keywords are a niche feature so it gets low priority development).
Unfortunately the only solution I can give is to change conflicting keywords. Fwiw you don't really need a keyword to search on google, just use the question mark. In Firefox 65 the question mark will be stripped, so we'll send the right string to the search engine.

keyword.enabled is an hidden pref with fancy behaviors, mostly for privacy-sensitive users that don't want to send any string to search engines even by mistake. It's an overzealous protection and as such more things don't work with it.

I'll keep this open at low prio because I can't atm find the original bug about the conflict, probably it was closed as inactive.

Comment 7

[[:philipp]]

bug 1514780 also took away the possibility to use # as a first character for a keyword search.
https://support.mozilla.org/en-US/questions/1248164

Comment 9

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

I'd like to note here, that once Quantum Bar is the default implementation, we could make tokenize() async, and that would allow the tokenizer to recognize if a token is a keyword. Until then it's not possible because the old urlbar tokenizes in a synchronous context. That said, it's possible the added complexity would still overweight the benefits.

Comment 10

[Tyler Szabo]

Bug 1538050 describes a situation in which a keyword that used to be valid became invalid. As this could potentially happen again with a future change it'd be handy if whatever method is used to notify the user that a keyword isn't valid could also indicate when a bookmark already has an invalid keyword.

Possible ways multiple bookmarks with invalid keywords could make its way into bookmark metadata without going through the "Add Bookmark" workflow:

• Upgrade from old build
• Sync
• Import
• Extensions

Comment 12

[Smylers]

Apologies for the dupe: I did check Bugzilla, but all my searches had ‘bookmark’ in them, which isn't in this bug's title.

Since this is an intentional change that affects existing bookmark keywords, as a minimum please can it be put in the release notes? Thanks.

If you can detect no-longer-valid keywords at start-up and notify users (perhaps also changing them to something compliant), that would be fantastic.

The upside to this change seems to be that URL bar keyboard shortcuts no longer require the documented spaces separating the symbol that's specifying the kind of search — which also seems worth a release notes mention. As well as updating the docs: https://support.mozilla.org/en-US/kb/awesome-bar-keyboard-shortcuts

Comment 13

[Smylers]

(In reply to Marco Bonardo [::mak] from comment #6)

keyword.enabled is an hidden pref with fancy behaviors, mostly for
privacy-sensitive users that don't want to send any string to search engines
even by mistake. It's an overzealous protection and as such more things
don't work with it.

PS: In my case (I'm not the original poster) I disabled that so that attempting to visit a local network site doesn't trigger a web search. If I'm trying to go to an internal website called ‘krunch’ but type it as ‘crunch’, I want to be able to easily fix the one-character typo, not find the entire address has been replaced with an irrelevant web search. Similarly, if I'm checking whether a DNS change has gone live yet, I want an actual error page on that URL so I can periodically hit F5 on to check whether the hostname is now resolving — which again, doesn't work if F5 just refreshes a page of search results. All to do with convenience, rather than security.