Editing URL-style link text of autoconverted plaintext URL does not change underlying link location (href="URL") (need error prevention)

NEW
Unassigned

Status

Thunderbird
Message Compose Window
--
minor
8 years ago
6 years ago

People

(Reporter: Christoph, Unassigned)

Tracking

({ux-error-prevention})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6.4; .NET CLR 1.1.4322; .NET CLR 1.0.3705; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1

I write a link into the body of a new message, e.g.

“www.domain.com/blablabla/blabla123.zip”

I save the message (Draft) or keep it in the Outbox.

[Is use MagicSLR.]

I reopen the message in order to edit the link.

I change e.g. “blabla123.zip” into “blabla124.zip”.

I save the message (Draft) or keep it in the Outbox.

I have a look at the unsent message. It SHOWS the link:

“www.domain.com/blablabla/blabla124.zip”

but the status line on the bottom shows the PREVIOUS URL:

“www.domain.com/blablabla/blabla123.zip”

At the receiving end my correspondence partner has the same problem: “blabla124.zip” is shown but “blabla123.zip” is the underlying URL, and the one that will be executed, both on my machine as on that of the receiver.

So the underlying URL should always be exactly the same as what is shown in the message composing window.


Reproducible: Always

Steps to Reproduce:
1.Create new message.
2. Enter an URL in the body.
3. Save the message as draft or in outbox.
4. Reopen the message and change the URL sightly.
5. Save the message as draft or in outbox.

The URL SHOWN in the message is the new one but the UNDERLYING URL (see status line) is the old URL
Actual Results:  
The edited URL is only edited at face value, the underlying URL is still the old one.

Expected Results:  
The underlying URL (in the status line) should be 100% the same as the URL shown in the message body.

See "Expected results".
(Reporter)

Comment 1

8 years ago
No further comments
This is an unfortunate result of two normally useful features working together to produce something not useful. Apparently, Thunderbird runs its post-compose-pre-send processing step (which, among other things, converts plain text URLs into actual HTML <a> links) when saving as draft (I figured this out by looking at source and Insert -> HTML). It is always possible to create a link that shows a different URL as text than what the link actually points to; the problem is that Thunderbird does not "remember" that the link was originally plain text and its href attribute should therefore (presumably) be updated when its text changes. (There seems to be a "moz-txt-link-freetext" class applied to it, but apparently the code doesn't pay attention to it.)
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All

Comment 3

7 years ago
I can confirm that this bug is still present in TB 5.0

Comment 4

7 years ago
Strictly speaking, this isn't a bug - as Nathan says, it's a 'feature' that you could understand would be useful if you want the text to say 'click here to visit my site'.

However, I think this is a valid concern when the text shown looks like a URL.

I think that if the display text for a link is a valid URL, Thunderbird should automatically convert the underlying link to match the displayed URL, as a guard against URL spoofing and human error.

As it stands, I believe it is all too easy to accidentally send someone a link that does not match the displayed URL.

Outlook Express has done this since the dark ages, and it's a feature I really appreciate.

Comment 5

6 years ago
(In reply to gary.kyle from comment #4)
> However, I think this is a valid concern when the text shown looks like a
> URL.
> As it stands, I believe it is all too easy to accidentally send someone a
> link that does not match the displayed URL.

+1 for problem analysis

> I think that if the display text for a link is a valid URL, Thunderbird
> should automatically convert the underlying link to match the displayed URL,
> as a guard against URL spoofing and human error.

I'm not sure if always forcing link locations to match their url-style link text is good one-for-all behaviour. We might break legitimate use cases of differing link text. What if I want "http://mozilla.com/.../test.html" [sic, including the dots] as link text? Should that be forced to have "http://mozilla.com/.../test.html" [sic] as link location? Probably not.

I appreciate the problem, but I think we should try to find a more intelligent solution. Even a checkbox in link properties:
[x] Automatically match link location with link text
(checked by default for URL-style link texts)
Thus, advanced users who want different URL-ish link text, can uncheck and freely define their link text.
Summary: Re-editing a URL in a message maintains previous link but shows re-edited link → Editing URL-style link text of autoconverted plaintext URL does not change underlying link location (href="URL") (need error prevention)

Updated

6 years ago
Duplicate of this bug: 604872

Updated

6 years ago
Keywords: ux-error-prevention

Comment 7

6 years ago
FTR, even forcing our editor to match URL-ish link text with link location will not effectively prevent spoofing. It would take a lot more drastic interference with user's source code to really prevent spoofing, and we can only prevent where TB is used for composing. Spoofing prevention really needs to be done on the receiving side, in the message reader, with some visual indication that URL-style link text is different from underlying URL link location. And again, just forcing the link text to match the underlying URL is probably too much interference with user's freedom of designing their links.

Comment 8

6 years ago
Bug 60341 and bugs referenced in comments thereof might have pointers to where the code for this lives.
You need to log in before you can comment on or make changes to this bug.