Closed Bug 104693 Opened 23 years ago Closed 23 years ago

Dotted text wrongly displayed as links

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jay, Assigned: sspitzer)

References

Details

(Keywords: regression)

Attachments

(1 file)

patch
784 bytes, patch
jag+mozilla
: review+
alecf
: superreview+
Details | Diff | Splinter Review 
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.
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.


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.
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.
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
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

try jay.garcia@something.com and it's htmlized.
Sure is, it's the . that does it.
*** Bug 104852 has been marked as a duplicate of this bug. ***
*** Bug 104897 has been marked as a duplicate of this bug. ***
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.
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
> 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.
Component: Mail Window Front End → Networking
Product: MailNews → Browser
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.
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.
*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.
The bug is present here as described. Win98SE build 2001101503 - Today's 
"latest".
*** Bug 104986 has been marked as a duplicate of this bug. ***
*** Bug 105046 has been marked as a duplicate of this bug. ***
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


*** Bug 105054 has been marked as a duplicate of this bug. ***
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:.

nominating this puppy for 0.9.6.
Keywords: mozilla0.9.6
> 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.

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
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

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

*** 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?
*** Bug 105217 has been marked as a duplicate of this bug. ***
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.
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
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. ***
This is evil.

CC nhotta and ftang.   Is this something to do with encoding and i18n?
Severity: major → critical
> * "+ " 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.
> "+/-" -> "±" has always been the case.

BTW: You can turn that off with the "Display Glyphs" (UI) pref.
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.

someone could try backing out my or dbaron's changes to see if it makes a
difference.
I backed out 1.47 and used 1.46 and the problem ('+' -> '±') is gone.

OK, I see.  I messed up operator precedence.
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 on attachment 53973 [details] [diff] [review]
patch

r=/me
Attachment #53973 - Flags: review+
sr=hyatt
Blocks: 105217
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
Closed: 23 years ago
Resolution: --- → FIXED
That is _so_ much better.  Thanks!
Confirming fixed on 2001101803 win32 on win2kpro-sp2
Confirming on WinME on a fresh CVS build.
Now *text* won't auto-bold as before.  Should this be reopened or another bug filed?
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.
BTW, the auto-bold regression happened between the morning build 2001101106 and
2001101510 (October 11 and 15).
new bug 105459 on the *bold* issue etc.
*** Bug 105090 has been marked as a duplicate of this bug. ***
*** Bug 106032 has been marked as a duplicate of this bug. ***
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.
Thanks, I'll verify it later in the week when I take a trunk build again.
A similar problem was reported as bug 105975.
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.

Attachment

General

Creator:
Created:
Updated:
Size: