Text containing colon is not searchable and the tab becomes non-duplicable
Reported by
world.best.hacker.h403@gmail.com,
Oct 7
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3555.2 Safari/537.36 Steps to reproduce the problem: 1. Open the provided index.htm 2. Select text "aa:" 3. Drag the selected text into a new tab What is the expected behavior? The default search engine should be launched to search for "aa:" text. What went wrong? The default search engine is not launched. The newly opened tab has title "Untitled" and no content. The search engine lanches only when user press enter from the omnibox. Refreshing the page doesn't help. Another issue is that the newly opened tab is not duplicable. Firefox deals with this properly. It launches the default search engine and searches for the selected text. Note: the screencast provided is recorded on a machine that has no internet connection, but it is irrelevant to this issue. Also tested on a machine that has internet connection and the issue still happens. Did this work before? N/A Chrome version: 67.0.3396.87 Channel: stable OS Version: 6.3 Flash Version: /
,
Oct 8
,
Oct 17
Able to reproduce the issue on chrome reported version# 67.0.3396.87, latest stable# 70.0.3538.67 and on latest chrome# 72.0.3582.0 with sample file provided in comment# 0 using Mac 10.12.6 and Windows-10. As this issue is seen from M-60(60.0.3112.0), hence considering this issue as Non-Regression and marking it as Untriaged. Note: Issue is not seen on Ubuntu 14.04. Thanks!
,
Oct 19
,
Nov 13
Oddly, does not repro on Linux. Putting this back in the omnibox queue, as I think it's actually caused by an omnibox issue. I'm pretty sure the relevant code path is here in BrowserTabStripController::CreateNewTabWithLocation() https://cs.chromium.org/chromium/src/chrome/browser/ui/views/tabs/browser_tab_strip_controller.cc?l=342-352 and in particular has to do with how the text is getting Classify()ed. For some reason the bare "aa:" is getting the URL-what-you-typed match first, not second as it's supposed to. This reminds me of bug 560809 . CC davidbienvenu@@ in case he has any insight, as he fixed that longstanding issue. Somehow I feel like it might come down to ChromeAutocompleteSchemeClassifier::GetInputTypeForScheme() https://cs.chromium.org/chromium/src/chrome/browser/autocomplete/chrome_autocomplete_scheme_classifier.cc?type=cs&l=22-79 chrome://omnibox is, oddly, not telling me what I expect
,
Nov 15
I don't think this has to do with GetInputTypeForScheme - it returns INVALID for aa:, as long as aa: isn't a registered scheme. I think the issue is in metrics::OmniboxInputType AutocompleteInput::Parse(), here: https://cs.chromium.org/chromium/src/components/omnibox/browser/autocomplete_input.cc?rcl=7663dd03f18a4bee2abffb8d3b39e688104fd0a7&l=275 - if there is a scheme, but not a recognized one, this code returns UNKNOWN instead of QUERY. This looks to be on purpose.
,
Nov 15
Thanks for the comment. UNKNOWN should mean that we rank the what-you-typed query (search for "aa:") higher than the URL-what-you-typed (navigate to aa:) and end up doing the query after the drag. Clearly that's not happening. Needs further investigation.
,
Nov 26
manukh: This is low priority, but I think it'd be educational for you to see how this part of the code works. Feel free to grab me any time if the comments above about what's going on here aren't clear or you want to discuss how to proceed.
,
Dec 8
Pretty annoying issue, hopefully it gets addressed soon. Also seems related to https://bugs.chromium.org/p/chromium/issues/detail?id=610620
,
Dec 8
that looks like the same bug to me.
,
Dec 11
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by world.best.hacker.h403@gmail.com
, Oct 7