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

RESOLVED DUPLICATE of bug 133016

Status

Thunderbird
Mail Window Front End
RESOLVED DUPLICATE of bug 133016
11 years ago
11 years ago

People

(Reporter: Marko Durkovic, Unassigned)

Tracking

({regression})

regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
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"
() 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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

11 years ago
OS: Linux → All
Hardware: PC → All
hmm, turns out it wfm on trunk. and, indeed, also wfm in 2.0.0.0
Version: unspecified → 2.0

Comment 3

11 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
Summary: Links (URLs) enclosed in parenthesis not parsed correctly in message window → [mozTXTToHTMLConv] Links (URLs) enclosed in parenthesis not parsed correctly in message window
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Created attachment 275231 [details]
comparison screenshot, 2.0.0.0 vs 2.0.0.6 vs trunk
Blocks: 133016
(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

11 years ago
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

11 years ago
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?
Keywords: regression
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.

Updated

11 years ago
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 133016
No longer blocks: 133016
You need to log in before you can comment on or make changes to this bug.