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 184.108.40.206 system !! :-D
actually, http://220.127.116.11 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
OS: Windows 98 → All
An email address included in the body of a rec'd email such as firstname.lastname@example.org when mouseovered shows mailto: not http:// in latest build 2001101308 Win98SE
try email@example.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. "firstname.lastname@example.org" 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 "email@example.com" is linked to http://firstname.lastname@example.org in email your last post produced.
They only show linked as http:// in email and news but not in the browser. email@example.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.
> 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+
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
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.
This was trunk only.
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.