Fixup heuristic for /foo/bar being a path is too aggressive
Reported by
tomac...@gmail.com,
May 31 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Steps to reproduce the problem: 1. Search for "/sbin/mount.vboxsf: mounting failed with the error: No such device" in the search bar What is the expected behavior? I should see the google search results for "/sbin/mount.vboxsf: mounting failed with the error: No such device" What went wrong? Chrome did not detect that the intention was to search because of the pathname component. Instead, it transliterated the search strinng into URL encoding: "file:///sbin/mount.vboxsf:%20mounting%20failed%20with%20the%20error:%20No%20such%20device" Did this work before? No Chrome version: 58.0.3029.110 Channel: stable OS Version: OS X 10.12.0 Flash Version: I don't see there as being a general use for URL encoding spaces. It might be nice for developers, but we know that 99% of users aren't going to be hand constructing URLs at all. If there are spaces in the search bar, it should be a search.
,
May 31 2017
This is actually platform-specific. On Windows, for example, "/sbin/mount.vboxsf: mounting failed with the error: No such device" searches by default. I think there's an aggressive heuristic in fixup that says /foo/bar is a path on POSIX systems. However, it seems overly aggressive here. I can't suggest a specific tweak without looking at precisely how this works today.
,
May 31 2017
I don't have a windows machine, but "C:\Windows directory" text might duplicate the behavior on Windows. "www.google.com aaa" => searches ok "https://www.google.com site not found" => searchs ok
,
May 31 2017
I think I see what could be the source problem. On Windows/Linux filesystems, you have the potential for pathnames with spaces in them. So, everything is per-se a valid path. ie. in folder "/sbin" there could be a file or folder named "mount.vboxsf: mounting failed with the error: No such device". Still, it doesn't give definitive evidence that the user is looking for a file either (its pretty rare that a user would type in a file path to the search bar IMO - there are better ways to navigate to a file like Open or drag and drop).
,
May 31 2017
Yes, in principle, this should be classified as "UNKNOWN", which is the type for "might be either a search or a nav, but was more likely intended as a search".
,
Jun 5 2017
,
Jul 19 2017
,
Jul 20
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 20
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by meh...@chromium.org
, May 31 2017