TB fails to display links in a received message as active hyperlinks.
Running TB 78.7.1 (32-bit) on Win 10. When I receive emails from a particular person, URL's in the message body are displayed as plain text not as active hyperlinks. This has been consistent over many months. These email are invitations to a zoom call and others who receive these emails do not have the same issue. When I view the emails on gmail with Firefox, the links are displayed properly as are the same when viewed on my android phone with the Gmail app. I tried safe mode, it made no difference.
When I select View -> Message body as -> Plain Text, the links are displayed correctly as active hyperlinks. When I forward one of these emails, TB adds the necessary html to make them true links. I suspect this is an oversight for this particular combination of message type. I can provide a full sanitized example, but here is an extract that I think should be a sufficient to get the necessary parameters. There are two "https" and one email address that should be displayed as active links: (Note: identifying data has been altered.)
MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2333329_1772000751.1613508279105" References: <[email protected]> X-Mailer: WebService/1.1.17712 aolwebmail Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:85.0) Gecko/20100101 Firefox/85.0 Content-Length: 2999 X-purgate-ID: tlsNG-813595/1613508285-000015E3-51AD7299/0/0 X-purgate-type: clean X-purgate-size: 3084
=_Part_2333329_1772000751.1613508279105
Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I haven't heard from Joseph about his availability, but Thursday works= for the rest of the group.=C2=A0 Here is the zoom link.=C2=A0 See you in a= couple of days.
Robert Smith is inviting you to a scheduled Zoom meeting.
Topic: Robert Smith's Zoom Meeting Time: Feb 18, 2021 03:00 PM Central Time (US and Canada)
Join Zoom Meeting https://us02web.zoom.us/j/89222598829?pwd=3DVDFxRXAzRamzL3F2S1ozOVF1QzI4dz0= 9
Meeting ID: 892 2259 8829 Passcode: 463417 One tap mobile +13126266799,,89222598829#,,,,*463417# US (Chicago) +16465588656,,89222598829#,,,,*463417# US (New York)
Dial by your location =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +1 312 626 6799 US (Chicago) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +1 646 558 8656 US (New York)
C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +1 301 715 8592 US (Washington D
C) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +1 669 900 9128 US (San Jose) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +1 253 215 8782 US (Tacoma) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +1 346 248 7799 US (Houston) Meeting ID: 892 2259 8829 Passcode: 463417 Find your local number: https://us02web.zoom.us/u/kenqe4HqyR
=20 Robert Smith [email protected]
=_Part_2333329_1772000751.1613508279105
Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
</font>
Topic: Robert Smith's Zoom Meeting
Time: Feb 18, 2021 03:00 PM Central Time (US and Canada)
Join Zoom Meeting
https://us02web.zoom.us/j/89222598829?pwd=VDFxRXAzRamzL3F2S1ozOVF1QzI4dz09
Meeting ID: 892 2259 8829
Passcode: 463417
One tap mobile
+13126266799,,89222598829#,,,,*463417# US (Chicago)
+16465588656,,89222598829#,,,,*463417# US (New York)
Dial by your location
+1 312 626 6799 US (Chicago)
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Washington DC)
+1 669 900 9128 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
Meeting ID: 892 2259 8829
Passcode: 463417
Find your local number: https://us02web.zoom.us/u/kenqe4HqyR
</font>
=_Part_2333329_1772000751.1613508279105--
All Replies (7)
The problem is with the way the message is formatted by the sender's mail program, especially it it's a mobile mail app. If the sender embedded the link in text, like this, instead of entering the URL directly, it would probably be clickable in TB in Original HTML view.
You can see the problem with the W10 Mail app: send a message from the app with a 'bare' URL, and open the message in a TB account, and see if the link is clickable.
No doubt that this could be fixed at the sender's end, but given that if none of the other five recipients have this problem, that gmail on Firefox browser does not have this problem, that gmail on Android does not have this problem and that Thunderbird in the "plain text" viewing mode does not have this problem then I think it's fair to expect that TB should handle this correctly in the normal viewing mode.
mopep said
I think it's fair to expect that TB should handle this correctly in the normal viewing mode.
Thunderbird displays what is sent. It does not scan the body of your HTML message looking for things that might be URL's and making them active. Although it does in plain text messages.
There is an outstanding enhancement request for the last eight years to do as you ask. It does not appear to have received much traction at this point. https://bugzilla.mozilla.org/show_bug.cgi?id=920560
Perhaps you might like to follow that request.
Thanks Matt for the link to the bug report. Clearly, this is a well documented issue. Not to be too argumentative, but I will invoke the consistency principle. When composing an email with TB, a URL typed in ( i.e., not using the link creation feature) will still be encoded with the "<a>" tag. So, if it's good enough for outgoing (and most of the rest of the world), then why not incoming? I definitely understand the argument against interpreting html beyond what is literally given. The display of my submission above is an example of unintended consequences when it's not clear whether html should or should not be taken literally. What Firefox displays is quite different from what I entered. Perhaps an acceptable solution would be a flag-per-email that controls URL scanning so that whatever the default, it can be change for any given email.
Izmjenjeno od strane Matt
Try looking at your email in plain text (view menu > message body as > plaintext and you will see Thunderbird can do it.
Matt, Not to be snarky, but that's exactly what I stated in the 2nd paragraph initially. Unfortunately that feature is not a per-email option. It's all or nothing. Thus, my proposed solution of a flag per email.
It scans in Plain text because there is no formatting.
HTML should have the correct formatting and therefore that formatting is used for HTML emails. Checking to see if an email has correct formatting when it comes specifically to links would be good. If the sender does not send correctly formatted emails then the issue prevails.
I suppose the arguement is that if sender does not send as a clickable link with correct formatting should Thunderbird assume that was their intention. I think there are many people sending those badly formatted links often using a phone and simply do not realise it.
I also suffer from such emails on occasion, especially if sent from a phone. It can be irritating, but a simple switch to plain text resolves that issue.
I've added a comment to the bug mentioned just to draw peoples attention to the fact it is still very a problem and asking if someone was available to finally resolve this long standing issue.