Searching for terms in large PDFs doesn't find all results
Categories
(Firefox :: PDF Viewer, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox83 | --- | verified |
People
(Reporter: matthias, Assigned: mcccs)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0
Steps to reproduce:
I opened a large PDF (attached), and without having scrolled (so still focused on the fist page) searched for "automatic vacuum".
Actual results:
It didn't find any results
Expected results:
It should have found at least 2 result on page 27
|
||
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
You could use mozregression to find which commit caused it, unless it is fixed in Nightly. (I can't reproduce it on my Ubuntu (Firefox Beta)) This would speed up finding the issue. (Are you both on Linux?)
I'm using Nightly regularly and this has not been fixed. Should have posted about it earlier but this issue has been going on for about 2 weeks now. I'm using Windows 10.
|
||
Comment 5•4 years ago
|
||
I can't reproduce in 81 or Nightly on Linux, FWIW.
Having the issue on Linux (debian stretch), at least with v81 (usually on beta, but not updated since release 81). Will add update when i've updated to latest beta.
Current about:config settings for search term 'pdfjs' that are highlighted:
pdfjs.enabledCache.initialized true
pdfjs.enabledCache.state false
pdfjs.migrationVersion 2
pdfjs.previousHandler.alwaysAskBeforeHandling true
I still can't reproduce it on Ubuntu with those prefs. Does the problem occur on a fresh profile? (I'm trying to reproduce so that I can use mozregression next)
Right, it doesn't occur on a fresh profile for me. This issue isn't addon-related though as I've already tried restarting with addons disabled. Wonder from where this comes from.
Right, it doesn't occur on a fresh profile for me. This issue isn't addon-related though as I've already tried restarting with addons disabled. Wonder from where this comes from.
I've traced it back to configuring 'about:preferences > Files and Applications > Applications > Portable Document Format -> Always Ask', and when the popup from 'what to do with this PDF' choosing 'open in Firefox'.
|
Assignee | |
Comment 10•4 years ago
|
||
Thank you, this is reproducible on macOS too (and is also super annoying)
I found that PdfJsParent constructor is not called if "Portable Document Format => Always Ask" I'm inspecting why
|
||
Comment 11•4 years ago
|
||
(In reply to Matthias from comment #9)
Right, it doesn't occur on a fresh profile for me. This issue isn't addon-related though as I've already tried restarting with addons disabled. Wonder from where this comes from.
I've traced it back to configuring 'about:preferences > Files and Applications > Applications > Portable Document Format -> Always Ask', and when the popup from 'what to do with this PDF' choosing 'open in Firefox'.
Indeed, choosing another action than "Always Ask", such as "Open in Nightly", solves the problem.
|
|
Assignee | |
Comment 12•4 years ago
|
||
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
||
Comment 13•4 years ago
|
||
It seems that the patch cannot land due to the following error. mccs, can you please take a look?
Details: We're sorry, Lando could not rebase your commits for you automatically. Please manually rebase your commits and try again.
hg error in cmd: hg import --no-commit -s 95 /tmp/tmp6475df01: applying /tmp/tmp6475df01
patching file toolkit/components/pdfjs/test/browser.ini
Hunk #1 FAILED at 5
1 out of 1 hunks FAILED -- saving rejects to file toolkit/components/pdfjs/test/browser.ini.rej
abort: patch failed to apply
|
|
Assignee | |
Comment 14•4 years ago
|
||
Thank you for needinfo'ing me. A rebased patch is not at D91441. Should I add a "check-in needed" tag now?
|
|
Assignee | |
Comment 15•4 years ago
|
||
- now at
|
|
||
Comment 16•4 years ago
|
||
Yes, please add a "check-in needed" tag when the patch is ready so one of the sheriffs can land it.
|
||
Comment 17•4 years ago
|
||
Pushed by cbrindusan@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4e240b88ba93 Keep pdfjs classes always enabled. r=NeilDeakin,jaws
|
||
Comment 18•4 years ago
|
||
Backed out for bc failure on browser_pdfjs_find_not_default.js
Backout link: https://hg.mozilla.org/integration/autoland/rev/4132663060a0617bccaccae86b6cde8ddab5d860
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=317669269&repo=autoland&lineNumber=2692
|
Reporter | |
Comment 19•4 years ago
|
||
mcccs, I believe this issue exists for a long time, but only recently started showing up due to Firefox now advertising to the OS that it can open PDFs: It also fails for 81, and probably dates back to 80 where the OS-default-PDF-reader configuration was introduced.
|
|
Assignee | |
Comment 20•4 years ago
|
||
@Matthias Thanks that explains why D76950, and old review introducing the faulty code, was not causing any problems until 81.
|
|
||
Comment 21•4 years ago
|
||
Pushed by ncsoregi@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/73e1bc905663 Keep pdfjs classes always enabled. r=NeilDeakin,jaws
|
|
Assignee | |
Comment 22•4 years ago
|
||
I rewrote the test so that it doesn't rely on the PDFJS find events.
|
|
||
Comment 23•4 years ago
|
||
| bugherder | ||
|
||
Updated•4 years ago
|
|
|
Assignee | |
Comment 24•4 years ago
|
||
To reproduce:
- Go to about:preferences
- Search "Applications"
- Search for "pdf"
- Set it to "always ask"
- Open the attached pdf: https://bugzilla.mozilla.org/attachment.cgi?id=9177184
- Search for "automatic vacuum"
- Expect to find 5 results
|
||
Comment 25•4 years ago
|
||
Reproduced the initial issue using old Nightly from 2020-09-22, verified that this is no longer an issue using Firefox 83.0b3 across platforms (Windows 10 64bit, macOS 11 and Ubuntu 18.04 64bit).
Description
•