1398567 - Can't search for b/c because the awesomebar doesn't provide a search action

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P2)

Description

[Alice0775 White]

Remove Search Bar by default in Nightly.
It takes long time to get a search results from Address Bar.
It is no problem from Search Bar.


Steps To Reproduce
1. type b/c in Address bar and hit [Enter] key

Actual Results:
It takes long time to get a search results.


Expected results:
It should not take so long

Comment 1

[Alice0775 White]

And notice, there are no Search grass icon in address bar drop down list.

Comment 2

[Alice0775 White]

s/grass/glass/

Comment 3

[Marco Bonardo [:mak]]

It is instant for me... Note that searching for b/c does a DNS roundtrip to try to resolve "b", and then when that fails it fallbacks to a search. Looks like a slow DNS problem in your network? :(
The fact is the location bar cannot know if "b" is a valid host or not.

Comment 4

[Alice0775 White]

Attachment: screenshot

See attached screenshot,
The dropdown list does not show any search glass row.
At least, this is a Bug.

Comment 5

[Marco Bonardo [:mak]]

well, it was not intended to show it, because the text contains a slash and thus it is interpreted as an url.
Surely it could be changed, but in general we need to figure out better strategies to distinguish urls from strings.

Comment 6

[Panos Astithas (he/him) [:past] (please ni?)]

Changing the title to reflect the real issue. The one-off buttons are there as one way to search, but I think we could also improve our heuristic here. Another workaround for similar cases that I use is appending a space that triggers the search action in the results.

Comment 7

[Marco Bonardo [:mak]]

another workaround we may provide in the future, with bug 1386548 it should be possible to add a question mark to force a search behavior.

Comment 8

[Alice0775 White]

It works as expected on Chrome and Edge

Comment 9

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 12

[Marco Bonardo [:mak]]

Attachment: Bug 1398567 - Invert URIFixup default behavior to search unless the string looks like a URI. r=gijs

With recent fixes that can properly identify whitelisted domains, whitelisted
domain suffixed, valid known public suffixes, and forcing to visit URI-like
strings that end with a slash, it's time to re-evaluate the URIFixup behavior.
Until now URIFixup considered everything a URI unless it had specific search
characteristics, this patch inverts that behavior.
This improves the urlbar handling of strings as a single search SAP.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/432809e79543
Invert URIFixup default behavior to search unless the string looks like a URI. r=Gijs

Comment 14

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/432809e79543

Comment 16

[Emil Ghitta, QA [:emilghitta]]

Reproduced the initial behavior from comment 0.

This issue is verified fixed using Firefox 78.0b3 (BuildId:20200604213430) on Windows 10 64bit, macOS 10.14 and Ubuntu 18.04 64bit.