1791854 - IMAP: Each click on a link to document-internal named anchor (#fragmentID) of PDF file opens another empty tab and creates a new copy of the file on user's desktop folder - should just jump to the desired location in the PDF viewer

Status: RESOLVED FIXED

(Thunderbird :: General, defect, P2)

Description

[Alexander Dobrick]

Attachment: This is an example of a PDF-File that creates the described behaviour on my version of thunderbird on a Windows 10 64-bit system.

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36

Steps to reproduce:

• Get someone to send you an email (or just send one to yourself) with an attachement containing a PDF-File that was created with LaTeX.

Context: In PDF-Files created with LaTeX one usually has links to within the document as short-cuts to theorem, equations etc.. If one clicks them the document "jumps" to the linked location.

• Click on such a link.

I am using the current version 102.3.0 on a 64-bit Windows 10 machine.

Actual results:

• Thunderbird opens a new empty tab. If one clicks on the original tab with the PDF-File, Thunderbirds PDF-Viewer jumped to the desired location in the PDF. However, it is quite annoying that each time a new empty tab gets open up.
• Secondly, an way more troublesome, for every empty tab Thunderbird creates a copy of the entire PDF on my Desktop.

I provided a PDF-document that induced said behaviour in the attachement of this report.

Expected results:

In older versions Thunderbirds PDF-Viewer just jumped to the desired location in the PDF viewer without opening a new empty tab or creating unwanted copies of the file on the Desktop. Clearly, the old behaviour is that one would expect and actually that is also exactly what should be happen.

The bug creates no bug description because it is just creating unwanted behaviour but not an actual error.

Comment 1

[Thomas D. (:thomas8)]

Hello Alexander, thanks a lot for reporting this!

Confirming for TB 102.3.3 (64-bit), Win10, exactly as described (Latex isn't a factor here, this is just about fragment URLs).

Sancus, could this be assigned to someone asap?

Ouch! This is actually happening on IMAP for PDF attachments in TB's PDF viewer. Each click on an internal named-anchor link <a href="#jump-here"> will open a new blank tab in Thunderbird AND create a new copy of the PDF document as a file on the user's desktop [sic]. For anyone actually using jump links, this is not only extremely annoying, but will also clutter the desktop folder with dozens of useless files in no time, which is not acceptable at all.
Btw, same problem does not occur on POP.

Comment 2

[Ben Campbell]

Attachment: Bug 1791854 - Disregard URL fragment when extracting content type from URL in mime nsStreamConverter. r=mkmelin

Comment 3

[Ben Campbell]

After a whole lot of printf debugging, here's my analysis:

The URL for an attached PDF ends up something like this:
imap://bob@localhost:1143/fetch%3EUID%3E/INBOX%3E6?part=1.2&filename=tyran.pdf&type=application/pdf

The mime nsStreamConverter gets the content type from the "type=...." param. Of course the URL parsing is our typical shonky ad-hoc char*-based parsing, and just includes any trailing fragment in the content type.
So... clicking on a internal document link like:
imap://localhost:1143/fetch%3EUID%3E/INBOX%3E6?part=1.2&filename=tyran.pdf&type=application/pdf#cite.dorn08
yields a content-type of application/pdf#cite.dorn08.
Which, of course, fails miserably. I guess the display code just gives up and downloads it as a file instead.

My patch fixes this by ignoring the fragment part of the URL (but does nothing to address the underlying badness of the URL parsing).

Comment 4

[Ben Campbell]

There is still the issue of a new tab being popped up when you click on the first local hyperlink (Clicking on other local hyperlinks in the new tab works correctly - the tab just jumps to the new position in the document).

For me, I see the first tab (i.e. when I open first the attachment) with a URL like:

imap://bob@localhost:1143/fetch%3EUID%3E/INBOX%3E6?part=1.2&filename=tyran.pdf&type=application/pdf

But the URLs of the internal hyperlinks don't include the username part of the URL:

imap://localhost:1143/fetch%3EUID%3E/INBOX%3E6?part=1.2&filename=tyran.pdf&type=application/pdf#cite.dorn08

So it looks like it's being interpreted as a different document.

Comment 5

[Ben Campbell]

Oh - regarding the URL fragment issue:
As far as I can tell, the determine-the-content-type-from-the-URL code has always been broken. hg blame dates that right back to CVS days (which is where out Hg history stops).
So if it's a recent regression, the breakage happened elsewhere.
Does anyone know for sure that internal links in PDF files did actually work properly?

Comment 6

[Andrei Hajdukewycz [:sancus]]

Thomas, can you test this on 91 to answer whether this is a new or old issue? Thanks!

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/fdcb5b7d51c4
Disregard URL fragment when extracting content type from URL in mime nsStreamConverter. r=mkmelin

Comment 8

[Thomas D. (:thomas8)]

Attachment: 1791854_testcase1_attachedPDFwithNamedAnchorLinks.eml

testcase.eml with attached PDF file with named anchors (PDF from attachment 9295631 [details]).

Comment 9

[Thomas D. (:thomas8)]

(In reply to Ben Campbell from comment #5)

Does anyone know for sure that internal links in PDF files did actually work properly?

(In reply to Andrei Hajdukewycz [:sancus] from comment #6)

Thomas, can you test this on 91 to answer whether this is a new or old issue? Thanks!

Clicking on named anchor links (URI fragments) in TB 91.13.1 (32-bit), Win10 works like a charme (using testcase.pdf from attachment 9295631 [details]), so this is a recent regression.

Alice, could you find the regression range? (you can use testcase.eml from attachment 9299676 [details])

STR

• open testcase.eml from attachment 9299676 [details]
• open the attached PDF in Thunderbird's PDF viewer
• click on first footnote anchor link [1] on page 1

Actual result (e.g. in 102 where this bug occurs):

• opens a new tab
• creates a copy of the PDF on your Windows Desktop

Expected

• jump to the named anchor target in the same document, here: reference [1] in the References section on page 18
• no file copy on Desktop

Comment 10

[Thomas D. (:thomas8)]

(In reply to Thomas D. (:thomas8) from comment #9)

Clicking on named anchor links (URI fragments) in TB 91.13.1 (32-bit), Win10 works like a charme (using testcase.pdf from attachment 9295631 [details]), so this is a recent regression.

Alice, could you find the regression range? (you can use testcase.eml from attachment 9299676 [details])

STR
[snip]

Comment 11

[Alice0775 White]

Regression window:

https://hg.mozilla.org/comm-central/pushloghtml?fromchange=236e2f92f885259f760701ffac800678fe9e1728&tochange=fc424c1e930b973bb54aa9ca5043dce1284811b1
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=66db1b50931634a3daad56bf7edd42d3a39cb37b&tochange=31346aa577d363be6c1139d1a134507b93f3784f

Comment 12

[Thomas D. (:thomas8)]

(In reply to Alice0775 White from comment #11)

Regression window:

Thank you very much, Alice!

https://hg.mozilla.org/comm-central/pushloghtml?fromchange=236e2f92f885259f760701ffac800678fe9e1728&tochange=fc424c1e930b973bb54aa9ca5043dce1284811b1

^^ Nothing in comm-central which strikes the eye here...
(In reply to Andrei Hajdukewycz [:sancus] from comment #13)

Bug 1734161 looks like a strong possibility.

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=66db1b50931634a3daad56bf7edd42d3a39cb37b&tochange=31346aa577d363be6c1139d1a134507b93f3784f

^^ Lots of changes from mozilla-central... maybe bug 1766222, update of pdf.js?
Therein, maybe #14803 Add support for the /Catalog Base-URI when resolving URLs (issue 14802)?

Calixte (assignee of bug 1766222), any insights?
Something has changed which causes Thunderbird to open a new tab when #fragementURLs in a PDF are clicked, see some analysis in comment 4. (We were able to fix the "creates new files on desktop" part of this problem, along comment 3.)

Comment 13

[Andrei Hajdukewycz [:sancus]]

Bug 1734161 looks like a strong possibility.

Comment 14

[Ping Chen [:rnons] (away)]

Attachment: Bug 1791854 - Prevent opening new tab for internal link when viewing pdf. r=mkmelin

Do not handle internal imap: link in new tab.

Comment 15

[Ben Campbell]

That patch seems to fix it for me!

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/af851721c7d2
Prevent opening new tab for internal link when viewing pdf. r=BenC