Closed Bug 892406 Opened 11 years ago Closed 9 months ago

Plaintext URL with partial formatting applied (bold etc.) rendered as broken hyperlink in message reader (link target/href truncated)

Categories

(Thunderbird :: Message Reader UI, defect)

17 Branch
x86_64
Linux
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 142507

People

(Reporter: kamran.usman, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130627172038

Steps to reproduce:

I composed a new email and added some hyperlinks to the email message.

1. Add a link in the message e.g. https://www.google.com/site/foo/bar

2. Select the letter 'o' in the word 'foo' and make it bold (I pressed Ctrl+B to make it bold)

3. Send the email.

5. Go to your 'Sent Email' folder and see your email.


Actual results:

In the email you sent, the formatting (bolding of a letter) resulted in a broken link.

E.g. There should be a link like:

https://www.google.com/site/foo/bar

But I actually see a link to:

https://www.google.com/site/fo 

and the rest of the link is simply printed as plain text and is not linked in the URL


Expected results:

The reader should have printed the exact URL irrespective of what formatting I applied on the text of the link.
worksforme on TB17, winXP, correct hyperlink target, only linktext correctly formatted in outgoing message.

thesocialgeek (reporter), can you provide source of sent msg and attach here using "add an attachment" above? Remove private data (email addresses etc.) from msg source before publishing here.

How exactly did you "add the link"?
Flags: needinfo?(kamran.usman)
Oh, I see this now.

STR

1 compose msg with default settings (might need more detail here about various html preferences)
2 type "http://www.foo.com" into msg body (without adding explicit link)
3 format first "o" of "foo.com" text bold
4 send (or send later, for testing)

Actual result

(for "send later" viewed in local outbox)
broken link when viewing the outgoing message
<a class="moz-txt-link-freetext" href="http://www.fo">http://www.f</a><b>o</b>o.com

Expected result

no broken link
Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → 142507
Summary: The hyperlinks, when formatted, are not rendered correctly → [mozTXTToHTMLConv] Plaintext URL with partial formatting applied (bold etc.) rendered as broken hyperlink in message reader (link target/href truncated)
Actually (my mistake) this is probably not about mozTXTToHTMLConv because the composed/outgoing message is already HTML per bold formatting.
We need to narrow down where and how exactly this goes wrong.
I'm also surprised to see class="moz-txt-link-freetext" being transmitted in the actual message source, which seems pointless for all other receiving mailers except TB.
Summary: [mozTXTToHTMLConv] Plaintext URL with partial formatting applied (bold etc.) rendered as broken hyperlink in message reader (link target/href truncated) → Plaintext URL with partial formatting applied (bold etc.) rendered as broken hyperlink in message reader (link target/href truncated)
When you send a message as HTML, we recognize links (and structs) and put the markers in the HTML that we send out. (This is modeled after Netscape 4.5, BTW.) This is because HTML is supposed to contain all markup, and most users do not manually mark URLs, and and receiving clients will typically not have recognizers run on the HTML that is displayed, so the sending end needs to do it.

Here, struct recognition and link recognition stumble over each other.
So, yes, this is very similar to or the same as bug 142507.

The class="moz-txt-link-freetext" and similar markers are there so that the receiving client *can* know that it's a recognized link, not a manually set one. No sure if any other clients uses it, but it's polite to put that information in there and it doesn't hurt anyone. (And Thunderbird does use it in some situations.)
Severity: normal → S3
Status: NEW → RESOLVED
Closed: 9 months ago
Duplicate of bug: 142507
Flags: needinfo?(kamran.usman)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.