search

mozilla / pdf.js

PDF Reader in JavaScript
https://mozilla.github.io/pdf.js/
Apache License 2.0
48.64k stars 10.01k forks source link

[Bug]: display `/UF` from `/Filespec` when hovering `GoToE` links #19063

Closed ousia closed 5 hours ago

ousia commented 5 hours ago

Attach (recommended) or Link to PDF file

Already uncompressed file with /GoToE link.

Web browser and its version

firefox-132.0.1-1.fc40.x86_64

Operating system and its version

Fedora 40

PDF.js version

PDF.js: 4.7.18 [9735a840a]

Is the bug present in the latest PDF.js version?

Yes

Is a browser extension

No

Steps to reproduce the problem

  1. Open the attached PDF document.
  2. Hover the link.

What is the expected behavior?

[This is a follow-up from #18030.]

When hovering the /GoToE link /UF from /Filespec (instead of /Desc) should be displayed.

The attachment itself displays /Desc (as per https://github.com/mozilla/pdf.js/pull/18031) and this is perfectly fine.

What went wrong?

screenshot

Link to a viewer

No response

Additional context

No response

Snuffleupagus commented 5 hours ago

This was implemented that way on purpose, so that FileAttachments behave consistently regardless of where in the viewer they're used/displayed and to guarantee that the /Desc-entry is actually accessible; hence I don't really consider this a bug.

ousia commented 4 hours ago

Sorry, @Snuffleupagus, I’m afraid this forces links to be considered as embedded files themselves (which they cannot be).

Showing the description instead of the file name may confuse users on what the description is related to (the main file or any other one) and which is the actual link destination.

Sorry if I’m missing your point here, but do you really think it is reasonable to display any other information when hovering an <a> element with other than its href value?

It might end up being a security issue.

Many thanks for your help.

Snuffleupagus commented 4 hours ago

I’m afraid this forces links to be considered as embedded files themselves (which they cannot be).

Those are not really "normal" hyper-links, since clicking them simply runs JavaScript that trigger saving of the embedded file.

Sorry if I’m missing your point here, but do you really think it is reasonable to display any other information when hovering an <a> element with other than its href value?

Those never displayed a "meaningful" title for FileAttachments, since as already mentioned above the link-clicks trigger JavaScript event-handlers and thus don't (and can't) contain any useful href-value.

It might end up being a security issue.

Sorry, but how? These "links" only trigger saving of things already present in the PDF itself.

ousia commented 3 hours ago

Many thanks for your reply, @Snuffleupagus.

I’m afraid this forces links to be considered as embedded files themselves (which they cannot be).

Those are not really "normal" hyper-links, since clicking them simply runs JavaScript that trigger saving of the embedded file.

I know that they aren’t links with external destinations, but they are links nonetheless.

What I mean by this is that it might be hard for the vast majority of people to realize that the description displayed when hovering isn’t related to the link, but to its destination (an embedded PDF document, which many people may [think they] see for the first time in their lives).

Sorry if I’m missing your point here, but do you really think it is reasonable to display any other information when hovering an <a> element with other than its href value?

Those never displayed a "meaningful" title for FileAttachments, since as already mentioned above the link-clicks trigger JavaScript event-handlers and thus don't (and can't) contain any useful href-value.

Sorry, I’m afraid I meant something different. Consider the following HTML snippet:

<p>To discuss the issue follow <a href="https://github.com/mozilla/pdf.js/issues/19063">this link</a>.</p>

The user may decide if the link is a legitimate one (before clicking on it), if its href value is displayed when hovering the link (the <a> element).

If they have to click and land to the destination, it might be too late (especially when the link wasn’t a legitimate one).

It might end up being a security issue.

Sorry, but how? These "links" only trigger saving of things already present in the PDF itself.

If I can recall correctly, links in embedded PDF documents were disabled to avoid tricking users (btw, without further indication, that wouldn’t prevent copying and pasting the link in the browser [as I would do myself, thinking that the attached PDF lacks links, not that they have been disabled]).

Using the /Desc field it might be relatively easy to trick users into believe that they are going to an external PDF document, when they are actually opening an embedded file (file that shows it).

Please, consider that /GoToE links give no context for the description displayed when hovering.

This is totally different from the attachment pane, where it is clear that it should be a property from the file on the list.

Many thanks for your help.