1201356 - pdf.js can't render selected characters properly

Status: REOPENED

(Firefox :: PDF Viewer, defect)

Description

[leichixian]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20150902030229

Steps to reproduce:

1. Open a pdf file, like this http://ac.els-cdn.com/S1387181115000931/1-s2.0-S1387181115000931-main.pdf?_tid=5b0a4a1e-51db-11e5-bc75-00000aab0f01&acdnat=1441244007_e7d739853593f0abb0f51ed67e0686f2
2. Select a word


Actual results:

The word you selected is not at the position pdf.js shows. You can use a dictionary software which have capture selected words function feature to confirm it. And if you use userstyles which force firefox's font it will be even worse.


Expected results:

The selected word should at the same position at where the characters are.

Comment 1

[leichixian]

On http://bbs.kafan.cn/forum.php?mod=viewthread&tid=1681393&page=64#pid35761201, a programmer told that in pdf.js there are two layers which use different fonts, one is forced to be the pdf files font, the transparent file (which is your "selected" words) uses firefox's font. We should let those two layers use the same font.

Comment 2

[Daniel Veditz [:dveditz]]

Can't access that pdf file, do you have one that exhibits the problem that you could attach to this bug?

Comment 3

[leichixian]

Sorry to make it inconvenient. Maybe this file can at also show the bug:http://bbs.kafan.cn/forum.php?mod=attachment&aid=MjY5MDAxMHxiNTQ4YzNlM3wxNDQxMjY0NDkzfDB8MTY4MTM5Mw%3D%3D&mobile=1

Comment 4

[leichixian]

Attachment: SevenHypnosisSecretsGuaranteedToWork-LMT.pdf

Test document

Comment 5

[Dirkjan Ochtman (:djc)]

I cannot reproduce this with your attached document. Selecting a word or phrase with the mouse pointers renders the selection bounding box correctly for (current Nightly). The only issue I see is that, if I start selecting and drag the mouse pointer to in between paragraphs, a much larger section of text will appear to be selected (from the start of the page, apparently).

Comment 6

[leichixian]

(In reply to Dirkjan Ochtman (:djc) from comment #5)
> I cannot reproduce this with your attached document. Selecting a word or
> phrase with the mouse pointers renders the selection bounding box correctly
> for (current Nightly). The only issue I see is that, if I start selecting
> and drag the mouse pointer to in between paragraphs, a much larger section
> of text will appear to be selected (from the start of the page, apparently).

Okay, If you just select word it seems right. But I've said in the first comment that you can check what you select by using a dictionary software or a userscript which can translate select word(s). Then you can see the result. I will try if it relates to firefox's locale setting. Maybe I should give you a Chinese pdf.

Comment 7

[leichixian]

Attachment: 捕获.PNG

Here I double click on "publication" to select it, but the selected zone is not at the position the word is. And if you have translate tool, you can see the word you "selected" by dragging mouse is not the word at this position.

Comment 8

[Brendan Dahl [:bdahl]]

Unable to reproduce on window 7. Can you try running firefox with a clean profile? This is likely the translate tool causing issues.

Comment 9

[leichixian]

(In reply to Brendan Dahl [:bdahl] from comment #8)
> Unable to reproduce on window 7. Can you try running firefox with a clean
> profile? This is likely the translate tool causing issues.

No, I tested with a clean profile and can confirm that it's pdf.js own fault. There are many same issues on pdf.js's github page. It has no relationship with translate tool.

Comment 10

[YF (Yang)]

I have encountered this problem many times in PDF Viewer, and I reproduce it on Fx44b4 for comment 4 while select "OBLIGATORY" and copy, I got the "OBLIGATORY LEG" to clipboard. It also appears to find and other cases, for example, if I find the "OBLIGATORY", it selected the "OBLIGAT" visually.

Comment 11

[leichixian]

Seems this problem relates to canvas in firefox. I tested pdf.js on chrome and all works okay. So I wonder if firefox deals with canvas differently with chrome.

Comment 12

[Bingqing Li]

Environment:
-----------------------
Win 7/Win 10 & Firefox 43.0.3


Steps to reproduce this issue:
----------------------------------------------
Select a word with double-clicking the left mouse button.


Additional info:
-------------------------------------
This issue is more pronounced when select a long word.


The pdf file I used:
-------------------------------------
http://www.tldp.org/LDP/abs/abs-guide.pdf

Comment 13

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.

Comment 14

[YF (Yang)]

This problem still exists in Firefox 61.0b8 64bit & 62.0a1 (2018-05-28).


https://github.com/mozilla/pdf.js/labels/4-text-selection

Comment 15

[Peter Magyari (Desktop QA)]

I know this is a very old report, but I cannot reproduce it on my end, and I'd like to close it if it doesn't occur anymore.
Have any of you guys experienced this issue on the latest Firefox versions?

Sorry for the old poke.

Comment 16

[YF (Yang)]

still exists in Firefox 95.0b11 64bit on Win10. same to comment 10.

Comment 17

[Kenan]

The bug is fixed in
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0
by:
Bug 1737299 - Update pdf.js to version 2.12.69 r=pdfjs-reviewers,calixte
Differential Revision: https://phabricator.services.mozilla.com/D129280

see mozregression:
app_name: firefox
build_date: 2021-10-27 11:05:14.002000
build_file: C:\Users\kenan.bromann.mozilla\mozregression\persist\e783412ae439-shippable--autoland--target.zip
build_type: integration
build_url: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/byvGJp_iTmiDgZ02Z8SECA/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
changeset: e783412ae4399677b30df41888617d8bac696cda
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e783412ae4399677b30df41888617d8bac696cda&tochange=95d6b5368d6fe45f646aceaa33d489d0df75f7dd
repo_name: autoland
repo_url: https://hg.mozilla.org/integration/autoland
task_id: byvGJp_iTmiDgZ02Z8SECA
Bug 1737299 - Update pdf.js to version 2.12.69 r=pdfjs-reviewers,calixte

Differential Revision: https://phabricator.services.mozilla.com/D129280

2021-12-10T21:26:47.276000: DEBUG : Did not find a branch, checking all integration branches
2021-12-10T21:26:47.278000: INFO : The bisection is done.
2021-12-10T21:26:47.279000: INFO : Stopped

Comment 18

[Daniel Bodea [:danibodea]]

I've attempted reproduction in ESR v91.4.1esr on Windows 10, Ubuntu 20.04.3 LTS and Mac OS 11.6.2 and I could only reproduce the original issue (the words being incorrectly visually selected upon double-clicking them) only on Ubuntu OS, however, I could see another problem, incapability to select words from specific paragraphs (like the first paragraph) on all 3 platforms types.

The original issue STILL OCCURS on the Ubuntu platform on ESR v91.5.0esr and Release v95.0.2.
The other issue no longer occurs in ESR v91.5.0esr on neither of the 3 platforms.

Steps:

1. load the PDF in comment 4
2. double-click the "OBLIGATORY" word from the second paragraph
   actual: only "OBLIGATOR" is visually selected (the whole word is copied, so the problem is only on the visual selection).
   expected: the whole word is selected: "OBLIGATORY".

Considering the originally reported issue is still visible in ESR v91.5.0esr and Release v95.0.2 on Ubuntu OS, I'm thinking of reopening this issue and specifying that it's Linux only. How do you want to proceed?

Comment 19

[Calixte Denizet (:calixte)]

The highlightment mismatch is due to the fact that the font used in the text layer (an invisible div containing some spans containing themselves the text of the page) has very different metrics from the one use to render the text on the canvas.
It's a recurring problem and we'll try to find a solution.
Anyway :danibodea, yes we can keep this bug open: the original issue is still there.

Comment 20

[Daniel Bodea [:danibodea]]

Reopening based on the last 2 comments. Reproducible in all channels.
I will not set it as a Linux-specific bug since it might not be specific but somehow depend on the font customization of the system.