1604571 - PDF previewing does not transfer state correctly when moving a tab between windows for ctrl+f

Status: RESOLVED DUPLICATE of bug 1722880

(Firefox :: PDF Viewer, defect, P3)

Description

[kburchard1]

Attachment: Shaky recording of the built-in ctrl+f

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

Reproduced on both Arch Linux and Windows 10.

1. Preview a large PDF directly in Firefox. This textbook (https://neurophysics.ucsd.edu/courses/physics_120/Agarwal%20and%20Lang%20(2005)%20Foundations%20of%20Analog%20and%20Digital.pdf) has been able to reproduce the problem for me with searching for 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.

Original report: https://github.com/mozilla/pdf.js/issues/11389

Actual results:

The built-in Firefox finder pops up, and searches among currently-rendered pages in PDF.js. This results in the search results changing depending on where in the PDF you are, and no results found for a word later on in the PDF if that page has not been rendered by PDF.js yet.

Expected results:

The built-in PDF.js (not the Firefox one) should be activated on ctrl+f, allowing me to search the entire document at once (even non-rendered parts). This is the result when you don't drag the tab between windows.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Jonas Jenwald [:Snuffleupagus]]

For brevity, quoting part of https://github.com/mozilla/pdf.js/issues/11389#issuecomment-565838725 in the hope that it's useful:

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.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:bdahl, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Bob Hill]

To demonstrate one facet of the problem described in this bug:

FIRSTLY, point Firefox to the Mozilla PDF.js "online demo" at https://mozilla.github.io/pdf.js/web/viewer.html
There is a spyglass near the upper left, between the icons for "Toggle Sidebar" and "Previous Page".
Using this spyglass searches the entire PDF document. For example, searching for the text "the" results in 985 matches.
The Esc key removes the spyglass drop-down. Cool.
Ctrl-F also activates the PDF.js spyglass (and does not open the otherwise standard Firefox search bar). Cool.

SECONDLY, in another tab or window, make sure Firefox's PDF.js is enabled, and point Firefox directly to the same document again at
"blob:https://mozilla.github.io/d6a647e3-6436-400f-9e74-a875411eb09f" (the "blob:" prefix is essential!).
This time, there is no spyglass near the upper left for the PDF.js integrated text search.
Nor does Ctrl-F invoke the PDF.js integrated text search. Instead, Ctrl-F invokes the standard Firefox search bar, which however yields incorrect results: searching for the text "the" never results in the correct 985 matches, but shows some smaller number, depending on what part of, and how much of, the document is currently visible.

I invite anyone to take a few minutes to carry out the above two experiments, and to see which version they prefer.

Quite aside from personal taste and from any ideological preferences, the fact remains that the standard Firefox text search in a PDF.js document (second experiment above) yields clearly incorrect and inconsistent numbers of matches. This problem was reported in various Firefox bugs over the years, but seemingly never fixed.

It would therefore seem appropriate to:

EITHER: finally fix the standard Firefox text search to display the correct number of matches in PDF.js documents.

OR: abandon the standard Firefox text search for PDF.js documents, and re-instate the PDF.js integrated text search spyglass, so that PDF.js works just the same in Firefox as it does in the PDF.js "online demo" described in the first experiment above (which presumably is how Mozilla intends PDF.js to be implemented?).

Comment 5

[braham.snyder]

I'm now seeing this in all tabs (not merely moved tabs). Even with a completely new profile, plus a restart.

Quick example: https://github.com/mozilla/pdf.js/files/1426655/Sample.PDF.document.pdf

Does anyone have a workaround for this?

Comment 6

[Bob Hill]

Yes, I do have a workaround for this. After installing every new release of Firefox, I modify Firefox so that using Ctrl-F in a PDF always invokes PDF.js's own text search spyglass near the upper left, and never invokes the standard Firefox search bar (as proposed right at the end of comment 4 in the paragraph beginning with "OR:").

Specifically, I (admittedly very crudely) modify "PdfStreamConverter.jsm" as follows:

Standard code:

supportsIntegratedFind() {
  // Integrated find is only supported when we're not in a frame
  return this.domWindow.windowGlobalChild.browsingContext.parent === null;
}

Modified code:

supportsIntegratedFind() {
  // Integrated find is only supported when we're not in a frame
  return                                                            false;
}

(Unfortunately, I confused the whole issue throughout comment 4 by referring to PDF.js's own text search spyglass as "integrated", whereas "PdfStreamConverter.jsm" uses the term "integrated find" to refer to Firefox's standard text search.)

Comment 7

[Calixte Denizet (:calixte)]

Attachment: Bug 1604571 - Pdf.js search was not used when a pdf was in a detached tab

Listen to the SwapDocShells event in order to be able to move the listeners for the find bar in the new browser.