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.

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.

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.

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.