New issue
Advanced search Search tips

Issue 749825 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 764635
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug-Regression



Sign in to add a comment

PDF search doesn't show found occurrences before whole document has been scanned anymore

Project Member Reported by jwer...@chromium.org, Jul 27 2017

Issue description

Chrome Version: 60.0.3112.72 (Official Build) beta (32-bit)
OS: Chrome OS 9592.66.0 (Official Build) beta-channel kevin

What steps will reproduce the problem?
(1) Open a large PDF document
(2) Press Ctrl+F
(3) Type a term that appears closely below the current page

What is the expected result?

As soon as the first occurrence of the search term is found, the viewport should jump to that occurrence. It should be possible to cycle through all the already found occurrences while the rest of the document is still being scanned.

What happens instead?

I see the total occurrence counter ("0 of <total>") counting up as more occurrences are found, but my viewport stays where it is. Pressing Enter of clicking the up/down buttons in the search box while in this state does nothing. Only after the whole document has been scanned does the viewport jump to the first occurrence (with the search box text changing to "1 of <total>").

This is a recent regression and used to work as described in "expected result" before (where you could cycle through occurrences while it's still searching... it would also wrap around when you cycled through the last *found* occurrence even though there may have still been others in later parts of the document, which was odd but possible to get used to). I work with many PDF manuals that are several thousand pages long every day, and searching through the whole thing can take close to a minute. Always having to wait for that although you know the rough area you want to find something in is a big productivity hit.
 
Is there a public PDF for testing? Is this a ChromeOS only bug? We can probably bisect more easily on other platforms.
Any large PDF will do, it doesn't seem to be specific to any document. For example, this seems to take a solid 20 seconds to search a term on my machine (of course, beefier machines will be faster): https://www.usb3.com/whitepapers/USB%203%200%20(11132008)-final.pdf

I have much larger ones, but I can't find one that is publicly hosted somewhere right now. Googlers can use https://drive.google.com/a/google.com/file/d/0Bz_cehT3Y6YsRkt0RDFqNWh5dGM/view?usp=sharing

I don't know if it also occurs on other OSes, but I would assume so.
Owner: paulmeyer@chromium.org
Status: Assigned (was: Untriaged)
Paul, I remember you fixed a search wrap bug some time ago. Please reroute if there is a better owner for this.
Labels: Needs-Bisect
This does seem like a regression, though I'm not sure how old it is. A bisect would help.
The problem seems to be in the PDF plugin code. For some reason, PDF find isn't sending the active match ordinal until after all the matches are found. It should send it when the first match is found.
Cc: paulmeyer@chromium.org
Owner: hnakashima@chromium.org
hnakashima@ can you take a look at the PDF engine code on the Chrome side see if you can figure out when we broke this?
Status: Started (was: Assigned)
I could reproduce this with builds synced back as far as March 21. It's not a new regression.
Mergedinto: 764635
Status: Duplicate (was: Started)
Duping into the newer bug as it has much more information, including the bisect range.

Sign in to add a comment