Dotted text wrongly displayed as links

VERIFIED FIXED

Status

()

--
critical
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: jay, Assigned: sspitzer)

Tracking

({regression})

Trunk
x86
All
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
Win98SE 2001101308 Sorry if if the summary is inconclusive, didn't know how else
to enter.

text, numbers, etc that are separated by a . <period> are displayed as clickable
links, example:

  links.test when mouseovered shows http://links.test
  1.2.3 shows as http://1.2.3
  C:\\ shows as a clickable link

so forth an so on.

To reproduce this, email yourself with the above text samples.
(Reporter)

Comment 1

17 years ago
Forgot to mention that this anomaly shows up in email and news postings only.
I believe this is correct behavior... we try to guess at embedded text that's
actually links....

You can turn it off with a pref, I believe.

(Reporter)

Comment 3

17 years ago
Guess ?? I really don't think that every text entry separated by a . is a guess
at at an embedded link. Think of Dewey rolling over in his grave as regards his
decimal 1.2.3.4 system !! :-D
actually, http://1.2.3.4 would actually be a completely valid url.

http://1.2.3 is not, which is why I confirmed this bug.

We don't scan for the "http://" so that if someone types www.yahoo.com in their
email it'll get picked up as a link.

Comment 5

17 years ago
Typos like forgetting a space before a new sentence is made into http:// links.
Mail-addresses are turned into http:// links. This has to be a regression, and
it ruins the product. People with older builds and 0.9.5 still see clear text
(for the typo sample) or mail-addreses as mailto: links.

See the thread "New bug with message linking" in n.p.m.mailnews for samples.

Comment 6

17 years ago
Upping severity. Being unable to spawn mailcompose by clicking mail-links in
mailnews is bad. OS: All - i'm seeing this on linux.
Severity: minor → major
Keywords: regression
OS: Windows 98 → All
(Reporter)

Comment 7

17 years ago
An email address included in the body of a rec'd email such as jay@jaygarcia.com
when mouseovered shows mailto: not http:// in latest build 2001101308 Win98SE

Comment 8

17 years ago
try jay.garcia@something.com and it's htmlized.
(Reporter)

Comment 9

17 years ago
Sure is, it's the . that does it.

Comment 10

17 years ago
*** Bug 104852 has been marked as a duplicate of this bug. ***

Comment 11

17 years ago
*** Bug 104897 has been marked as a duplicate of this bug. ***

Comment 12

17 years ago
word....word is also considered a link, an no protocol I know of ever uses more
that two .'s in a row. And if they do it's always perceded by a / or followed by
one.

as is word.word and word..word and so on.

Maybe a list of known top lever domains should be used to HTMLify the links,
that at least makes senseless links at the end af a sentence where someone
forgot to hit the spacebar history.

The same for IP addy's thoase can be checked for validity. And although it
slowsdown the scanning, it is always better than having way too many links that
serve no purpose.

Comment 13

17 years ago
Just to add to this:

x = single char
0 = num
xs = multiple char

x.x should never be a link, as it isn't possible with the current DNS namespaces.
0(.0(.0)) should never be a link, as at least 4 nums are needed for a Ip addy.
xs.x si also impossible. as top level domains are at least 2 chars

\\xs
or \\0.0.0.0 should be interpreted, but also no

\\0.0.0 or les nums

Comment 14

17 years ago
> C:\\ shows as a clickable link

Filed bug 104876, because it's a separate issue. I see that bug.

However, I don't see the bug with the dots. "ben.bucksch@beonex.com" gets linked
as mailto:, which is correct. I don't see word.word being linked.

Linking everything with c.c is definitely not intended.

Updated

17 years ago
Component: Mail Window Front End → Networking
Product: MailNews → Browser

Comment 15

17 years ago
What OS are you on?  Branch or trunk?  I see this on the trunk, winXP, October
15 build.  word.word links to http://word.word and "ben.bucksch@beonex.com" is
linked to http://ben.bucksch@beonex.com in email your last post produced.
(Reporter)

Comment 16

17 years ago
They only show linked as http:// in email and news but not in the browser.

jay.garcia@jaygarcia.com shows as http:// and not mailto: in the body of an 
email or news post but do show correctly in the browser. Word.word is not linked 
in the browser but is in mail/news.

Comment 17

17 years ago
*grumble* /latest/ is still != /latest-trunk/

I use the build from /latest/, and it didn't show the bug. The latest from
/latest-trunk/ does show the bug.
(Reporter)

Comment 18

17 years ago
The bug is present here as described. Win98SE build 2001101503 - Today's 
"latest".
*** Bug 104986 has been marked as a duplicate of this bug. ***

Comment 20

17 years ago
*** Bug 105046 has been marked as a duplicate of this bug. ***

Comment 21

17 years ago
other funny "URL"s found by Mozilla:
byopasia_graa.baggrund.gif
09.15-11.00
24.10.01
5.1.4...Det
Mx5.1.4

Comment 22

17 years ago
*** Bug 105054 has been marked as a duplicate of this bug. ***

Comment 23

17 years ago
Parsing for URL-esque text is a noble idea, but has opend up a can of worms.

Keep to auto-URLing for text strings with URL prefixes (http://, ftp:// mailto:,
etc.).  The only exception might be a contiguous string containing a "@" and "."
for mailto:.

Comment 24

17 years ago
nominating this puppy for 0.9.6.
Keywords: mozilla0.9.6

Comment 25

17 years ago
> Parsing for URL-esque text is a noble idea, but has opend up a can of worms.
> Keep to auto-URLing for text strings with URL prefixes (http://, ftp:// mailto:,
> etc.).  The only exception might be a contiguous string containing a "@" and "."
> for mailto:.

See above. Again: The URL recognizer worked well for almost 2 years now. This is
a bug. Nobody tried to make it better by looking at dotted text.

Comment 26

17 years ago
ccing dbaron,alecf,bnesse, who recently modified code which is probably relevant.
Summary: Text displayed as links that are not links → Dotted text wrongly displayed as links

Comment 27

17 years ago
I may have introduced a regression when I switched us from nsCRT::strncmp to
Compare()..but I'm not sure how as it was a pretty mechanical change. we can
just look at the logs to mozTXTToHTMLConv.cpp.. or it could have been dbaron,
who fiddled with a ?: to make my changes build on WS5.0

Comment 28

17 years ago
Most likely, the bug is in either function
mozTXTToHTMLConv::CompleteAbbreviatedURL or mozTXTToHTMLConv::ItMatchesDelimited.

I guess, it was one of the following checkins:

1.47dbaron%fas.harvard.eduOct 12 21:25 Fix Sun WS 5.0 bustage by moving
conditional deeper into expression. b=100214
1.46alecf%netscape.comOct 12 17:12 convert from nsCRT::strn?cmp to Compare() for
bug 100214 r=jag, sr=sfraser

Comment 29

17 years ago
*** Bug 105163 has been marked as a duplicate of this bug. ***
Perhaps the problem is that the Compare no longer stops after n characters, so
it compares the terminating null and finds a difference.  Could something like
that explain the problem?

Comment 31

17 years ago
*** Bug 105217 has been marked as a duplicate of this bug. ***

Comment 32

17 years ago
perhaps - we may need to review my changes - I was trying to incorporate the "n"
in strncasecmp in my conversion to Compare() by truncating strings where necessary.

Comment 33

17 years ago
An info from the bugs marked duplicates, namely bug 104852 and bug 105217, that
may or may not be really the same as this bug, but that I want to emphasize once
more:

* "+ " in mail message windows (non-HTML mail) are being converted to "+/-" glyphs.
* "]+/," becomes " ±" in mails.
also: "5+a2" becomes " ±"

This makes it impossible to use PGP via the clipboard. Dogfood!
*** Bug 105251 has been marked as a duplicate of this bug. ***
Component: Networking → Mail Window Front End
Product: Browser → MailNews

Comment 35

17 years ago
By the way, if anyone cares about that txt to HTML converting stuff, please give
a look at bug 91615
That bug is about wrong conversion of power of numbers on mail display. 
*** Bug 105304 has been marked as a duplicate of this bug. ***

Comment 37

17 years ago
This is evil.

CC nhotta and ftang.   Is this something to do with encoding and i18n?
Severity: major → critical

Comment 38

17 years ago
> * "+ " in mail message windows (non-HTML mail) are being converted to "+/-"
> glyphs. * "]+/," becomes " ±" in mails. also: "5+a2" becomes " ±"

"+/-" -> "±" has always been the case.
"+/-" -> "+" is a (new) dataloss bug, which might be related to this bug or bug
104876.

> This makes it impossible to use PGP via the clipboard. Dogfood!

Use View Source.

Comment 39

17 years ago
> "+/-" -> "±" has always been the case.

BTW: You can turn that off with the "Display Glyphs" (UI) pref.

Comment 40

17 years ago
It doesn't seems to be i18n at least not charset conversion. If this is charset
conversion then it could be seen on browser too.

Comment 41

17 years ago
someone could try backing out my or dbaron's changes to see if it makes a
difference.

Comment 42

17 years ago
I backed out 1.47 and used 1.46 and the problem ('+' -> '±') is gone.
OK, I see.  I messed up operator precedence.

Comment 44

17 years ago
bzbarsky, please leave the bug in Networking, where is belongs (because that's
where the code is).
Component: Mail Window Front End → Networking
Product: MailNews → Browser

Comment 46

17 years ago
Comment on attachment 53973 [details] [diff] [review]
patch

r=/me
Attachment #53973 - Flags: review+

Comment 47

17 years ago
sr=hyatt

Updated

17 years ago
Blocks: 105217

Comment 48

17 years ago
Comment on attachment 53973 [details] [diff] [review]
patch

so glad it wasn't me :)
sr=alecf
Attachment #53973 - Flags: superreview+
Checked in 2001-10-17 20:21 PDT.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 50

17 years ago
That is _so_ much better.  Thanks!

Comment 51

17 years ago
Confirming fixed on 2001101803 win32 on win2kpro-sp2

Comment 52

17 years ago
Confirming on WinME on a fresh CVS build.

Comment 53

17 years ago
Now *text* won't auto-bold as before.  Should this be reopened or another bug filed?

Comment 54

17 years ago
Please file a new bug. Note that the reason is probably fix for bug 104693 and
post the new bug number here. 

This is IMHO the proper procedure because we cannot be yet 100% sure that the
new problem is caused by the checkin for this bug.

Comment 55

17 years ago
BTW, the auto-bold regression happened between the morning build 2001101106 and
2001101510 (October 11 and 15).

Comment 56

17 years ago
new bug 105459 on the *bold* issue etc.

Comment 57

17 years ago
*** Bug 105090 has been marked as a duplicate of this bug. ***
*** Bug 106032 has been marked as a duplicate of this bug. ***

Comment 59

17 years ago
Was this bug introduced in the trunk after the 0.9.4 branch. I didn't see the
bug in branch build for 10-09 or in today's build.  Not sure if I'm missing
something in the steps to reproduce.

Comment 61

17 years ago
Thanks, I'll verify it later in the week when I take a trunk build again.

Comment 62

17 years ago
A similar problem was reported as bug 105975.

Comment 63

17 years ago
Using build 20020322 on winxp, linux and mac and the original scenario testing
in plain text compose and html compose this is fixed. Verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.