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

Issue 904480 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Slow and buggy find-in-page recently

Project Member Reported by mloh@google.com, Nov 12

Issue description

Chrome Version: Google Chrome	70.0.3538.67 (Official Build) (64-bit)
Revision	9ab0cfab84ded083718d3a4ff830726efd38869f-refs/branch-heads/3538@{#1002}
OS: Linux, Mac

What steps will reproduce the problem?
(1) Visit a big webpage with a lot of text
(2) Press ctrl+F to find things in page

What is the expected result?

It should be smooth and instantly like it used to be

What happens instead?

Very slow behavior sometimes, and even often displays "0/1" which doesn't make sense. I can no longer trust it when it says no results, because sometimes if I wait 3 seconds, suddenly it will finish computing the results and show them. This makes it very hard to use chrome efficiently. 


 
Note: This is even happening on Mac OS
Description: Show this description
This is really bad and makes chrome unusable compared to before where the find-in-page was practically instant. I have to actually copy/paste the text content into a text editor to do my work reliably. More than once I have made incorrect conclusion about the text because it said no results found, only to find out later it was "0/1" which means it's still loading or something. 
Labels: Hotlist-DesktopUIConsider
Labels: Group-Toolbar
Labels: -Type-Bug Type-Bug-Regression
Labels: OS-Mac OS-Windows
I believe I also encountered this bug once on my Windows computer, so marking it as affecting windows too. 

Chrome never had this bug until about a month ago, so marking the bug as a regression. 

It would be nice if an older version of Chrome were made available for those of us who really need the find-in-page functionality to work as intended. 
Cc: dbronner@google.com
+1 for another person hitting this on Linux starting about a month ago. I see this on not-particularly-large pages (20k chars / 500 lines of text).

It's always(?) the first search on the page. After that, subsequent searches are fast. But the behavior is inconsistent in the first place, so I'm not certain of any of this.
Status: Available (was: Untriaged)
Labels: -Hotlist-DesktopUIConsider Hotlist-DesktopUITriaged
Labels: M-73 Target-73

Sign in to add a comment