487645 - URL not clickable link in email if link broken up by quoted-printable encoding (?)

Status: RESOLVED INVALID

(Thunderbird :: Message Reader UI, defect)

Description

[Barry S. Weingart]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.53 Safari/525.19
Build Identifier: Shredder.

This is not a bug, but should be considered a major improvement for Thunderbird and I don't know where else to report this.
When an email contains text such as http://url.com/etcetc, Shredder should automatically turn this into a clickable link. Thats is simple but VERY USEFUL!
Thanks!

Reproducible: Always

Steps to Reproduce:
1.  Send a plain text email with an http://
2.
3.
Actual Results:  
make it work better.

Expected Results:  
click able link.

Comment 1

[David Ascher (:davida)]

This works now and has for a long time.  Can you give us a test case where it's not working?  Maybe specific URLs aren't detected?

Comment 2

[Wayne Mery (:wsmwk)]

afaik the only place a URL is not clickable is in display of subject

Comment 3

[David Ascher (:davida)]

Attachment: Testcase 1 (eml): multipart/alternative with quoted-printable text/html part

Confirmed w/ a test case.

Comment 4

[David Ascher (:davida)]

dmose suggests that the problem in this case is that thunderbird currently doesn't do linkification of the the text/html representation of the email because, as a multipart/alternative, the HTML version is deemed richer.  Most HTML-sending email clients would do the linkification themselves as part of the HTMLification.

We might want to consider linkifying unadorned links in HTML, but this bug is likely confined to a few email clients.

(Barry: as a strange consequence of all this, if you could configure your PDA to send plain-text emails, then your Thunderbird _would_ convert them to links).

Comment 5

[buovjaga]

Still confirmed.

Thunderbird 52.1.1 (32-bit)
Windows 7 64-bit

Comment 6

[Steve Piercy]

I have an example message where the URL is not converted to a clickable link. Note that I must obscure some details with <UUID> of the URL for privacy. I also <snip>ed out irrelevant parts.

Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_8C14_37FAD0AA.56746613"


------=_NextPart_000_8C14_37FAD0AA.56746613
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<snip>

 File Stamped Copyhttps://california.tylerhost.net/ViewDocuments.aspx?FID=
=3D<UUID>

<snip>

------=_NextPart_000_8C14_37FAD0AA.56746613
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<table width=3D"100%"><tbody><tr><td width=3D"30%"><b>File Stam=
ped Copy</b></td><td>https://california.tylerhost.net/ViewDocuments.aspx?FI=
D=3D<UUID><br>This link is active for 365 day=
s.</td></tr></tbody></table>

<snip>

------=_NextPart_000_8C14_37FAD0AA.56746613--

Comment 7

[adrien.rybarczyk]

Problem still present in Thunderbird 91.

If the part of the mail has a Content-Transfer-Encoding in quoted printable, the URLs are not converted to clickable link.

Comment 8

[newsfan]

This bug is pretty much invalid/wontfix and the summary appears to be wrong, nothing to do with quoted-printable.

In a text/plain message part, a link is displayed as clickable ("text is linkified"), regardless of CTE QP.

In a text/html part, a simple text that looks like a URL is not made clickable, the sender has to send proper HTML (with an <a> tag) to get a clickable link. I don't think going around linkifying text in a text/html part is correct, that's what HTML is for.

Basically that's what was already said in comment #4.

Comment 9

[buovjaga]

Ok, let's close.

Comment 10

[Thomas D. (:thomas8)]

Attachment: Screenshot 1: Testcase 1 in TB 91.5.1 message reader (View as HTML)

This is how David's Testcase 1 looks in TB 91.5.1 (64-bit) message reader with View > Message Body as > Original HTML.

The link does not have an <a> tag in HTML source.
Then TB does not auto-linkify the plain URL when viewing the HTML part.

--_A47641DA-36C3-523B-2CAF-C39961A8B692_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="iso-8859-1"

<HTML><HEAD><META HTTP-EQUIV=3D'Content-Type' CONTENT=3D'text/html; charset=
=3Diso-8859-1'></HEAD><BODY><SPAN style=3D'FONT-SIZE: 10pt; FONT-FAMILY: Ar=
ial; FONT-WEIGHT:Normal;'>Read the article online at:<br><br>http://www.eng=
adgetmobile.com/2009/04/09/a/<br><br></SPAN></BODY></HTML>=

--_A47641DA-36C3-523B-2CAF-C39961A8B692_--

Comment 11

[Thomas D. (:thomas8)]

Attachment: Screenshot 1b: Testcase 1, View > Message body as > Plain text: URL does get auto-linkified

Somewhat ironically, when you view the plain text part, the URL will get linkified.

Comment 12

[Thomas D. (:thomas8)]

Attachment: Testcase 2 (eml): plain URL in HTML part does get linkified

Here's a testcase with only an HTML part, and the unadorned URL inside the HTML does get auto-linkified by TB. So is it the quoted-printable which makes testcase 1 fail?

Comment 13

[Thomas D. (:thomas8)]

Comment on attachment 371888 [details]
Testcase 1 (eml): multipart/alternative with quoted-printable text/html part

So the HTML part in testcase 1 is quoted-printable.

Comment 14

[Thomas D. (:thomas8)]

Attachment: Screenshot 2: Testcase 2 viewed as HTML, and plain URL in 7bit HTML part *does* get linkified

Testcase 2 viewed as HTML, and plain URL in 7bit HTML part does get linkified

Comment 15

[newsfan]

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

Testcase 2 viewed as HTML, and plain URL in 7bit HTML part does get linkified

In TB 91 the first line "(removed link from source manually)" does NOT get linkified. Your screenshot shows the plain text view where it DOES get linkified. This bug is really invalid and any attempts to relaunch it, bug 1751704, are doomed to fail.

HTML markup requires an <a> tag to show as link.

Also, could you please attach .eml files with MIME type text/plain so the can be viewed at BMO without downloading them.

Comment 16

[Magnus Melin [:mkmelin]]

There's no fixing it with the current linkification process we do. Potentially we could stop doing that and instead just do the linkification once we have the actual DOM to work with. The linkification is something mozilla-central are not keen on keeping anyway, so we're likely to need to address it sooner or later anyway.

Comment 17

[newsfan]

Whatever you do with mozTXTToHTMLConv in the future, hopefully you're not going to invent <a> tags in HTML where there aren't any.

Comment 18

[Magnus Melin [:mkmelin]]

Why would you not want non-linkified links linked, for viewing? It's of course possible it should be possible to pref off.

Comment 19

[newsfan]

Because there's a HTML standard which defines an <a> element to be used for a link. That <a> element can be styled with all sorts of effects using CSS, maybe the sender uses <a class="xx"> for his links, and now you add some bare links? How would you like a browser that (sometimes erroneously) invents (incorrect) links where there are none? IMHO, the HTML must be displayed exactly as it was sent and according to the standard, with no modifications. If you want to invest time into improving HTML display in TB, bring bug 1659362 and bug 1429491 to a close.

Linkifying plain text is a favor to the user. There have been plenty of bugs about linkify going wrong, so why shift this problem area to where it's not necessary, or worse, infringing the HTML standard? On other occasions you insist on following standards, even to the user's detriment, and here you're suggesting to infringe the standard for some very doubtful benefit. Sorry, I can't follow that line of thought at all, not even when being able to pref it off.

Comment 20

[newsfan]

Further to the previous comment consider this HTML (!) e-mail from your support department:

Dear Magnus,
we analyzed the sample e-mail you supplied and indeed it contains a phishing link to this attacker site www​.attacker.com hidden behind a button.
Please do NOT click the button.
Regards, Your support

(Used a trick so BMO wouldn't linkify www​.attacker.com.)

You may argue that GitHub, BMO, etc. linkify text, but that's a different story, the user entering the text is right there and can correct any unwanted/incorrect linkification.