390779 - [mozTXTToHTMLConv] Links (URLs) enclosed in parenthesis not parsed correctly in message window

Status: RESOLVED DUPLICATE of bug 133016

(Thunderbird :: Mail Window Front End, defect)

Description

[Marko Durkovic]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070605 Firefox/2.0.0.4
Build Identifier: thunderbird 2.0.0.6

Links in the form "(http://www.mozilla.org):" are not recognized correctly. In the message window/preview the link is clickable, but the "):" are recognized as part of the URL. If the ")" is e.g followed by whitespace, ";" or "," it works okay.

I've seen this error in 2.0.0.4-2.0.0.6 (MacOSX/Linux). In 2.0.0.0 the handling of links in that form was okay.

Reproducible: Always

Steps to Reproduce:
1. Compose a mail with this link "(http://www.mozilla.org):"
2. Save it to Drafts
3. Look at its preview
Actual Results:  
The blue underlined link is "http://www.mozilla.org):"

Expected Results:  
The blue underlined link should read "http://www.mozilla.org"

Comment 1

[Tuukka Tolvanen (sp3000)]

() are valid characters in urls, so using them to delimit urls is a bad idea. Read bug 133016 and bug 301363 for various edge cases; I'm not sure exactly which way it's designed to guess at the moment... To avoid the issue, use unambiguous non-url characters <http://...> to delimit urls.

Confirming (linux tbird 2.0.0.6), since the difference between the handling of
    http://www.mozilla.org): foo - link extends to :
and
    http://www.mozilla.org), foo - link extends to g
is a bit odd.

Comment 2

[Tuukka Tolvanen (sp3000)]

hmm, turns out it wfm on trunk. and, indeed, also wfm in 2.0.0.0

Comment 3

[Ben Bucksch (:BenB)]

You have to love recognition. Please were yelling and insulting a lot to get bug 133016 "fixed". Shortly after that's fixed, we have this report which asks for the exact opposite.

Comment 4

[Tuukka Tolvanen (sp3000)]

Ben, I don't follow... Patches for bug 133016 were checked in before the release of 2.0.0.0 on trunk and branch. The issue reported here seems to be a subsequent branch-only change of some sort.

Comment 5

[Tuukka Tolvanen (sp3000)]

Attachment: comparison screenshot, 2.0.0.0 vs 2.0.0.6 vs trunk

Comment 6

[Tuukka Tolvanen (sp3000)]

(In reply to comment #4)
> Patches for bug 133016 were checked in before the
> release of 2.0.0.0 on trunk and branch.

Oh, I was wrong branching-wise there, 1.77.18.1 is THUNDERBIRD_2_0_0_0_RELEASE and 1.77.18.2 is 2_0_0_4, but with that bug 133016 comment 98 explains the difference

Comment 7

[Ben Bucksch (:BenB)]

Thanks, Tuukka, for the attachment.
It shows 3 differences:
- The treatment of "):" (first line) and ")u(" differs betwen 2.0.0.6 vs. 2.0.0.0/trunk.
- The treatment of "(u)" differs between 2.0.0.0 and 2.0.0.6/trunk
- "{", "[" (last lines) differs between 2.0.0.x and trunk

In all cases, trunk is correct.

There was a bad branch check-in for bug 133016 (as you pointed out, see last comments there). Are you sure the 133016 fix went in before 2.0.0.0? If not, that would explain it.

Comment 8

[Ben Bucksch (:BenB)]

Oh, your last comment says exactly that, that my bad branch fix went in after 2.0.0.0. Yes, so what you list as 2.0.0.0 is *before* the 133016 fix, 2.0.0.6 is the bad/older 133016 fix, and trunk is the real 133016 fix.

Thus, thus bug is a branch-only regression caused by the bad, earlier patch for bug 133016 accidently checked into branch only. Shall we mark dup or use this bug to track? Or not care at all and just wait for the next bigger Thunderbird release?

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Ben, due to it was your fault and all the later work was done in bug 133016 I would consider to mark this bug as dupe of 133016 and try to get approval for the 1.8 branch there. If it's a simple patch I could imagine we could get an approval.