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

Issue 669546 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner: ----
Closed: Dec 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Find function not working properly on Chrome for Mac

Reported by macha...@gmail.com, Nov 29 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36

Steps to reproduce the problem:
1. Install google chrome on macbook pro (attempted on three different macbook pro devices)
2. In normal or incognito mode, press cmnd+f to search within page
3. Press enter (or click down arrow in find bar) to jump to next instance of string that you searched for.

What is the expected behavior?
Upon first hitting cmnd+f on a webpage, the find bar should appear, the browser window should jump to the first instance of the queried string on the page, and find bar should display "1 of X" where X is the number of times the query appears in the text of the page.

What went wrong?
1. When I first hit cmnd+F on a webpage, the queried strings are all highlighted within the page, but the numerical indicator (e.g. "1 of 61") does not appear as it should - the righthand side of the find bar is blank. See screenshot 1. I noticed that at this point (i.e. all strings are highligted on page, but counter is blank), if I hit cmdn+f AGAIN, it will "refresh" the find bar and the numerical indicator (in this case "1 of 61") will appear as it should have originally

2. Upon hitting enter to jump to the next instance of the string on the page, the numerical indicator does not update. In screenshot 2, you can see that I have jumped to the third instance of "the" on the page, but the counter still says "1 of 61." (Similar to step 1, if I press cmnd+F AGAIN at this stage, it will correct/refresh the find bar and correctly state "3 of 61.")

3. In general, the find bar is buggy. Sometimes only a portion of the numerical indicator appears - there seems to be a CSS issue where there is white space from the left-hand side of the find bar that is incorrectly overlapping the text of the numerical indicator. I don't know how to faithfully reproduce this specific phenomenon every time, but in screenshot 3, you can see what I'm talking about (part of the numerical indicator text is cut off and it just says "of 155"). In this case, I was just searching for random strings on a large page of text until I was able to reproduce.

Did this work before? Yes Unsure - my Chrome updates automatically, and I would estimate this started 1-2 months ago

Chrome version: 54.0.2840.98  Channel: stable
OS Version: OS X 10.12.1
Flash Version: Shockwave Flash 23.0 r0

I had a unique ability to test this issue - I originally noticed it happening on two macbook pro laptops that I use frequently over the past month or so (one is a Late 2011 model, the other a Late 2012 retina model).

I had tried many times to delete all chrome browsing data, disable/delete all extensions/delete+reinstall chrome on both laptops, all with no luck.

Due to an unrelated situation, I had the opportunity to completely factory reset  the Late 2012 retina macbook pro: the startup volume was erased, and OS X was reinstalled. Upon the installing chrome, the issue persisted, both when signed in as a chrome user (all my extensions active, etc), or not signed in in (no extensions). The problem also occurs in incognito mode.

To take it a step further, there was a THIRD macbook pro (this one a Retina Late 2013), belonging to a co-worker, whose laptop was also factory reset (startup volume erased and fresh OS X install). They had never been a chrome user in the past, they do not have a chrome account, etc. When I installed chrome on this laptop to test, I get the exact same problem. On this laptop, there is not, nor has there ever been, any previous chrome history/user data, any extensions installed, and chrome user logged in, etc. The issue happens in normal and incognito mode.

I have searched extensively for this issue. Most of the results I have found come from 2+ years ago, where the typical solution offered is to disable hardware acceleration. On all three laptops (testing for all variables - deleting history, disabling extensions, etc), disabling hardware acceleration does not fix the problem.
 
screenshot1.png
809 KB View Download
screenshot2.png
815 KB View Download
screenshot3.png
556 KB View Download

Comment 1 by rsesek@chromium.org, Nov 29 2016

 Issue 669548  has been merged into this issue.

Comment 2 by meh...@chromium.org, Nov 29 2016

Components: -UI UI>Browser>FindInPage
Cc: ligim...@chromium.org
Labels: -Pri-2 M-54 Needs-Bisect Needs-Triage-M54 Pri-1
Labels: -M-54 -Needs-Bisect M-55 has-Bisect
Owner: spqc...@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on Mac 10.12.1 using chrome reported version #54.0.2840.98 but unable to reproduce the same in the latest canary #57.0.2937.0.

Reverse Bisect Information:
=====================
Good build: 55.0.2883.44
Bad Build : 55.0.2883.42

As the good and bad builds are branch builds. Hence, proving the CL from omahaproxy.

Change Log URL(Omahaproxy): 
https://chromium.googlesource.com/chromium/src/+log/55.0.2883.42..55.0.2883.44?pretty=fuller&n=10000

From the above change log suspecting below change

Review url: https://codereview.chromium.org/2479883003

spqchan@ - 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.

Thanks...!!
Cc: durga.behera@chromium.org
Labels: Needs-Feedback
Able to reproduce the issue on Macbook pro 10.12.1(retina) using 54.0.2840.98(used https://en.wikipedia.org/wiki/Language).

Note :
1) Working fine on Beta 55.0.2883.59, Dev 56.0.2924.10 & canary 57.0.2937.0.
2) Unable to reproduce the issue on Macbook air 10.11.6,Win 10 and Ubuntu 14.04 using 54.0.2840.98/99/100.

machajew@ : Could you please try the issue on Beta 55.0.2883.59 and confirm if its resolved here, as the M55 stable is going to be released soon it would be available on Stable.

Comment 6 by shrike@chromium.org, Nov 30 2016

Re: c#4, the purported good build 55.0.2883.44 comes after the purported bad build 55.0.2883.42, which would imply that the bug was fixed between .42 and .44. Hence, https://codereview.chromium.org/2479883003 would be the fix for this bug, not the cause.

FWIW, I get the part 1. of "What went wrong?" in the original report no matter which version I try, even going back to the last M53 stable.
Status: Fixed (was: Untriaged)
Marking fixed as per #6 (similar to  issue 669872 ).

Sign in to add a comment