Typing something like `* @wikipedia test` has unexpected behaviour

VERIFIED FIXED in Firefox 65



5 months ago
4 months ago


(Reporter: bruce.bugz, Assigned: adw)


(Blocks: 1 bug)

65 Branch
Firefox 65

Firefox Tracking Flags

(firefox65 verified)



(2 attachments)



5 months ago
Posted image Capture.PNG
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

Type any[1] of the special characters that filter address bar suggestions, followed by a space, followed by a search engine keyword. So something like `* @wikipedia`.


Actual results:

1. @wikipedia was highlighted when it probably shouldn't be

2. First suggestion was:
[wiki favicon] a -- Search with Wikipedia (en)
So the last character of the search engine keyword is being assumed to be part of the search query. For `* @amazon test`, I get:
[amazon favicon] n test -- Search with Amazon.com

3. If I press enter, the browser will indeed do what the first suggestion said, e.g. search Wiki for the letter A.


5 months ago
Component: Untriaged → Address Bar
sigh, we should consider search shortcuts only if the string begins with them :(
Blocks: 1496772
Ever confirmed: true
Priority: -- → P2

Comment 2

5 months ago
It looks like we've always (accidentally?) been treating "* alias query", "% alias query" etc. as a search engine alias search, and also we've always (or at least for a while) been incorrectly parsing out the query string in that case (because we're taking the substring of the trimmed original search string, which includes the restriction token).  It's more obvious now that we highlight aliases though.

I'm bumping into this while working on bug 1504847 so I think I'll go ahead and fix it now.
Assignee: nobody → adw

Comment 3

5 months ago
I'll handle the highlighting part in bug 1504847 -- i.e., not highlighting built-in @ aliases when the input doesn't start with them.

Comment 5

5 months ago
On second thought I should just fix that here too.  I think the decodeURIComponent() in the formatter is wrong and unnecessary also.
I am not totally convinced that in the "* @alias" case we should recognize the alias, I really thing the trimmed original search string should start with the @alias for it to be effective. What's the point of recognizing the alias, since the user first of all asked to limit the query to bookmarks?
What are the remaining results, if they exists? I'd expect them to be bookmarks matching the "@alias" string.
There's an edge case for "? @alias" though...
And thinking more about it, I think "? @alias" should search "@alias" in the default search engine.
Plus the added complication we are introducing when the thing is recognized as an alias but not hilighted as one. It all sounds like complication that will hit us in the future. That's why I'm suggesting that the trimmed original search string must start with @, if it doesn't then it's not an alias (or a command), it's just a plain string.

Comment 10

4 months ago
The patch isn't adding any new recognition, see comment 2.  Do you really want to fix that as part of this bug?
Flags: needinfo?(mak77)
(In reply to Drew Willcoxon :adw from comment #10)
> The patch isn't adding any new recognition, see comment 2.  Do you really
> want to fix that as part of this bug?

I don't see why we should complicate the code and behavior, just to simplify it shortly after...
Flags: needinfo?(mak77)
Attachment #9023827 - Attachment description: Bug 1504552 - Correctly handlde search engine aliases when restriction characters are present. → Bug 1504552 - Correctly handle search engine aliases and other keywords when restriction characters are present.

Comment 14

4 months ago
Pushed by dwillcoxon@mozilla.com:
Correctly handle search engine aliases and other keywords when restriction characters are present. r=mak

Comment 15

4 months ago
Last Resolved: 4 months ago
status-firefox65: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 65

Comment 16

4 months ago
I can reproduce this issue in Nightly 65.0a1 (2018-11-04) (64-bit) on Linux x86_64

I can verify that this is fixed in latest Nightly

Build ID 	20181129095546
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0
QA Whiteboard: [bugday-20181128]
I have reproduced this bug with Nightly 65.0a1 (2018-11-08) on Windows 7, 64 Bit!
This bug's fix is verified with latest Nightly!

Build ID 	20181126100057
User Agent 	Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0


Comment 18

4 months ago
As per comment 16 and comment 17, I am marking this bug as verified.
status-firefox65: fixed → verified
You need to log in before you can comment on or make changes to this bug.