Pdf.js: Inconsistent word finding when using ctrl+f in Firefox built-in viewer

[kyeb]

Attach (recommended) or Link to PDF file here:

Just some notes from my linear algebra course, a standard LaTeX document, although I've had this issue with a variety of larger documents.
Lecture+notes.pdf

Configuration:

• Web browser and its version: Firefox 70.0.1
• Operating system and its version: Windows 10, Version 10.0.18363 Build 18363
• PDF.js version: built-in Firefox PDF previewer

Steps to reproduce the problem:

1. Open PDF
2. Ctrl+f for a word (in this case, I'm using "Diagonaliz")
3. Press enter repeatedly to find the next instance of the word, or click the down arrow to do the same
4. Extremely inconsistent behavior when searching through the document

What is the expected behavior?

When I use ctrl+f, it should search the entire document. The count may increase as it indexes and finds results, but should never decrease or otherwise change.

What went wrong?

Hopefully you can see in this gif, despite the strange rendering - the number of search results changes, and I honestly have no idea what it's finding and what it's not. Specifically, I've observed it going from "5 of 11 matches," count up to 10, then go to "8 of 9 matches," then "9 of 10 matches," then "7 of 7 matches," and so on.

I'm not sure if this is the place to drop this bug - let me know if it's more of a Firefox and I'm happy to move it over there. This is the only thing preventing me from using Firefox completely over Chrome - as a student, I really need ctrl+f to work perfectly when studying for my exams, and it works much better in Chrome's built-in viewer.

[Snuffleupagus]

Looking at the attached gif it seems that the "normal" browser find is somehow being triggered, rather than the PDF.js one (based on the faint colour and shape of the highlights) which is really strange.
I cannot reproduce this problem, in Firefox Nightly 73 on Windows 7, so the following is simply a couple of initial debugging steps you may want to try.

Since it looks like you've got a couple of addons installed the first step here would probably be to test in "safe mode", which temporarily disables all addons, to see if any of them are causing the problem; please see https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

It may, additionally, be useful to check that your current profile hasn't somehow become broken and thus causing this. Hence you may also want to try to reproduce this with a new profile, please see https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles

[kyeb]

Oh, that would actually make some sense as the bug - very interesting. Since this issue appears to me to be non-deterministic, is there an easy way to tell (color/shape) whether it's the normal browser find or the PDF.js one, instead of trying to get it to do this weird thing again?

[Snuffleupagus]

[...] is there an easy way to tell (color/shape) whether it's the normal browser find or the PDF.js one, instead of trying to get it to do this weird thing again?

The easiest might be to look at the x of y matches message in the findbar, since with default search options there should be 28 matches for that document for "Diagonaliz" as the search term.
Basically, opening your document at the first page and then searching for "Diagonaliz" should scroll to the first match (on page 60) and then the matches counter should (quickly) update to 1 of 28 matches when the PDF Viewer searching is being used.

If, on the other hand, the "normal" browser search runs then you'll get the erratic x of y matches as shown above, since in this case searching will only be possible for already loaded/rendered pages.

[kyeb]

I'm having trouble reproducing this now, even within my existing profile and with add-ons, but it has happened to me on multiple occasions now, often at seemingly very inopportune times. For the record, the only add-ons I have are Bitwarden, uBlock Origin, and Video Speed Controller, all extremely popular add-ons (at least, I don't think) should not interact with ctrl+f.

I'm not sure how to proceed now -- if it's not reproducible at the moment, I guess it makes sense to close the issue and I can re-open if I'm able to recreate it? It seems odd to close this issue when we know it's something that can occur, though. I'll leave it up to you.

[timvandermeij]

Yes, let's close it for now, but we'll be happy to reopen it once there are steps to reproduce. Thanks!

[kyeb]

Steps for me to reproduce this consistently on both my laptop and desktop (running Arch Linux and Windows 10, respectively):

1. Preview a PDF directly in Firefox. Since the uploaded PDF above seems to only download, not allow previewing, this textbook has also been able to reproduce the problem for me with the word "MOSFET" (or really, any large PDF that doesn't all render at once).
2. Drag the tab from one Firefox window to another.
3. Press ctrl+f in the PDF preview.

Expected behavior: the PDF.js built-in finder should pop up, allowing me to search the entire PDF.
Observed behavior: Firefox's built-in finder is shown, only searching the currently-rendered parts of the PDF.

Steps I've taken to try to fix this issue: restarting Firefox and computer, "refreshing" Firefox (which I believe rebuilds my profile from scratch).

It's quite possible this is more of a Firefox problem than a PDF.js one (or some weird interaction between the two), especially given the steps to reproduce, so let me know if it would make more sense to file or look for a bug report there.

[timvandermeij]

I can also reproduce this on Arch Linux. It looks like there is indeed a bug when transferring state to another window. I do think that this is something with the PDF.js integration in Firefox, so most likely this should be reported upstream in Bugzilla.

[Snuffleupagus]

I do think that this is something with the PDF.js integration in Firefox, so most likely this should be reported upstream in Bugzilla.

Yes, this is probably best handled in Bugzilla since it concerns the PDF.js Firefox integration code rather that the general library (i.e. the .jsm files found here).

Based on a cursory look: The problem appears to be that we're not handling browser and/or docShell swapping for the Findbar integration in https://searchfox.org/mozilla-central/source/browser/extensions/pdfjs/content/PdfjsChromeUtils.jsm, and it might be possible to use e.g. a SwapDocShells event to update the findbar listeners.

[kyeb]

I'm not familiar with Bugzilla or where the PDF.js Firefox integration code is maintained, but if somebody points me in the right direction, I'm happy to file a report in the correct place.

[timvandermeij]

You can file a bug, referencing this issue, at https://bugzilla.mozilla.org/home.

[kyeb]

Filed here.