New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 664612 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner: ----
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Custom search engine titles are confused in the omnibox

Reported by mr.ber...@gmail.com, Nov 11 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Sofari/537.36

Steps to reproduce the problem:
1. Start a guest session
2. Go to chrome://settings/searchEngines
3. Add two search engines:
A. "Wikipedia en", "we", http://en.wikipedia.org/wiki/Special:Search?search=%s
B. "Wikipedia de", "wd", http://de.wikipedia.org/wiki/Spezial:Search?search=%s
4. In omnibox, type "wd bvb" - Note that omnibox reads "Search Wikipedia de", and you find the corresponding article in the German Wikipedia when hitting enter.
5. Clear omnibox, type "we " - Note that omnibox still reads "Search Wikipedia *de*". Hitting enter finds the correct article in the English Wikipedia.

What is the expected behavior?
"we" always yields "Search Wikipedia en"

What went wrong?
"we" sometimes yields "Search Wikipedia de"

Did this work before? N/A 

Chrome version: 53.0.2785.116  Channel: n/a
OS Version: 10.0
Flash Version: Shockwave Flash 23.0 r0

I have been seeing this for months now in stable. I cannot always reproduce this reliably, but have been able to do so multiple times now in guest sessions. I have not been able to reproduce this on Canary [56.0.2916.0 canary (64-bit)], so maybe (yet not necessarily) this has been fixed.
 
Labels: Needs-Bisect M-54
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on Win7/64 bit - Version 54.0.2840.99 m (64-bit)

Not seen on Canary [56.0.2916.0] & Beta [55.0.2883.44] builds


Comment 2 by woxxom@gmail.com, Nov 12 2016

The issue was present since Chrome 31 at least.

Bisect: 420136 (bad) - 420143 (good), 55.0.2868.0
Changelog: https://chromium.googlesource.com/chromium/src/+log/887a5866..765fbff4?pretty=fuller
Suspecting: r420142 "Remove non-md code in location bar (Views)"

Comment 3 by woxxom@gmail.com, Nov 12 2016

The bisect above shows when the issue was "fixed".

Comment 4 by hdodda@chromium.org, Nov 14 2016

Cc: hdodda@chromium.org
Owner: jww@chromium.org
Status: Assigned (was: Untriaged)
As per the changelog in comment #2, assigning it to the concerned owner .

@jww - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Review-Url: https://codereview.chromium.org/2343053002

Comment 5 by woxxom@gmail.com, Nov 14 2016

#4, er, this behavior was present since Chrome 31 (or maybe from the very beginning, I didn't test earlier builds). Bisect shows when it was fixed.

Comment 6 by hdodda@chromium.org, Nov 15 2016

Labels: -M-54 -Needs-Bisect M-55
Removing Needs-Bisect label for now, feel free to add again if bisect is required.

Thanks !
Owner: ----
Status: Untriaged (was: Assigned)
Components: -UI UI>Browser>Omnibox
Components: -UI>Browser>Omnibox UI>Browser>Omnibox>TabToSearch
Sounds a lot like bug 569770.

I'm going to mark it as Untriaged until we can see if it was truly fixed in 55.0.2868.0.

I really appreciated the repro steps.  Bug 569770 did not have as clear repro steps and I struggled (and failed) to reproduce it.
Status: Fixed (was: Untriaged)
I can confirm with those repro steps that this bug is indeed fixed, likely at the version mentioned in comment #2.  Closing.

Sign in to add a comment