Rich, look at this msg in Nova to see how linebreaks fool the linkifying code. Can we do anything about this? Subject: URL preservation on linewrap? Date: Wed, 21 Apr 1999 12:09:52 +0200 From: Gavin Brelstaff <gjb@crs4.it> Organization: CRS4 - http://www.crs4.it/Areas/bma.html Newsgroups: netscape.public.mozilla.mail-news Guys Pls confirm URLs that get line wrapped in mozilla will still be clickable. Jon Udell at news:news.devx.com/joncom was overheard to say: > Gnus works even in the case where linewrapping introduced > leading whitespace? Here's the part of RFC1738 I meant: Examples: Yes, Jim, I found it under <URL:ftp://info.cern.ch/pub/www/doc; type=d> but you can probably pick it up from <URL:ftp://ds.in ternic.net/rfc>. Note the warning in <URL:http://ds.internic. net/instructions/overview.html#WARNING>. > I guess it wouldn't be hard to piece these URLs together, > come to > think of it, but the NS and MS readers don't. > Jon Udell | <http://udell.roninhouse.com/> | 603-355-8980

Not really sure how to attack this, but I will give it a shot. - rhp

The biggest challenge with this issue is the fact that the code that does this linkifying of URL's, etc.. is all line based and has no information for previous or subsequent lines. I would have to try to impart some sort of state information for these calls to make this work. I will think about it, but it won't be done for M6. - rhp

That's cool. I think this is pretty low priority, compared to your mountain of composition backend work.

I don't think this is a must have for PR1.

Unfortunately, this is non-trivial. Bumping way out. - rhp

With the rewrite that Ben Bucksch is doing, we will be able to detect across linebreaks. Reassigning. - rhp

I think, I was a bit too fast with accepting. I wrote the new scanner with linebreaks in URLs in mind, so the scanner (which is my part) shouldn't be the problem. Of course, I can't really test it, because it is never fed with multiple line at once. This is up to the caller, which are other parts of libmime. I'm discussing with rhp, how to change/cheat libmime, but that's all I can do for that bug. However, it doesn't look good. BTW: Feeding the scanner with multiple line would make ASCII-art/ASCII-table recognition possible, too.

I added comments on this subject to bug 19251.

mime=ducarroz

*** Bug 95822 has been marked as a duplicate of this bug. ***

*** Bug 123781 has been marked as a duplicate of this bug. ***

*** Bug 137583 has been marked as a duplicate of this bug. ***

*** Bug 88753 has been marked as a duplicate of this bug. ***

Is this still on the radar for anyone? It seems like a fairly important fix for mail/news, considering most people use Outlook which wraps long URLs. Nothing has been said on this bug since January 2001. There are more duplicates than on this bug, as duplicates of other duplicates have been made. I understand Entourage on Mac unwraps long URLs.

well, it';s more an Outlook/OE problem than a mozilla issue. To be exact,this is a feature request - some extra coding to cater for the mess left behind by M$ bugs. Should M$ fix it for their users first and then fix all the copies of damaged messages out there in the universe? :) Anyway, preserving long URL during quoting of message would be nice., though.

This is not an Outlook/OE problem. RfC 1738, Appendix (Page 21) says In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may need to be added to break long URLs across lines. The whitespace should be ignored when extracting the URL. cf. the example at the description.

Confirmed with successor RFC 2396. Nobody is working on this. It would either need a rewrite of libmime or some hack, e.g. - buffer until we have an empty line. - if we found an URL, do not output that line, but buffer it, then when processing the next line, check, if there is something in the buffer, and if so, process it together with the current line. Both of it would have to be done independantly in the plaintext and f=f converters.

s/buffer until we have an empty line./buffer until we have an empty line (i.e. a whole paragraph) OR/

see comments in bug #185032 any chance of getting this back on the front burner?

In a discussion over long URL's and the handling of these in news clients, I came on following information in rfc2396 round page 33,34 | In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may | need to be added to break long URI across lines. The whitespace | should be ignored when extracting the URI. somewhat lower | Using <> angle brackets around each URI is especially recommended as | a delimiting style for URI that contain whitespace. So I understand Mozilla isn't complying with the RFC. When can a solution be expected? Bernard

> | Using <> angle brackets around each URI is especially recommended as > | a delimiting style for URI that contain whitespace. There is special code which specifically strips whitespace in this case. It's just that we are not able to process URLs that cross several lines, for technical reasons. > When can a solution be expected? Never, unless somebody fixes this bug. I am unlikely to do so. See above for my thinking about how it could be fixed. None of the solutions are very tempting.

Ben or Jean-Francois, have you considered any of the solutions proposed in Bug 185032 comment 0 <http://bugzilla.mozilla.org/show_bug.cgi?id=185032#c0>? Specifically: "... the behavior of the action triggered by selection of the "Copy Link Location" action could be altered. In the case that the current selected text contained more than the extent of a recognized URL, this action could copy the complete selected text but stripped of linefeed characters." This would only require changes to the Copy Link Location code.

copy link location is offtopic here. this bug is only about the automatic linking of plaintext emails (not plaintext documents in the browser).

i'm not referring to the browser. copy link location is available in the context menu w/i plaintext email. if a URL has been recognized, that is. the failure of which is precisely on-topic here. the modified behavior of copy link location would serve as a workaround for the issue presented by this bug.

*** Bug 199850 has been marked as a duplicate of this bug. ***

Thought I'd mention that Pegasus eMail v4.02a has the ability for the user to highlight the multi-line URI, right click, and select "Open as Hyperlink". Maybe this is an option for this bug. Note: the Pegasus implementation isn't perfect. It doesn't like URI's that are indented for example.

IMHO, we should not work around backend bugs like this with unfortunate UI, we should fix the backend as suggested in comment 17. I just don't feel like doing it myself.

Haven't heard anything from assignee on this one. Perhaps it should revert to NEW w/ HelpWanted keyword?

.

re: comment 26 highlight the multi-line URI, right click, and select "Open as Hyperlink" would be fine. I use a simple workaround: copy & paste the URL to the location bar. To get this working you need an entry in the profile in user.js: user_pref("editor.singleLine.pasteNewlines", 3); I´m using this on win98. I don´t understand why this pref or your suggested option isn´t default, there are a lot of links in forums, which are not clickable, because of linebreaks, or forum policy.

Well, my suggested option (with thanks to Pegasus eMail and the author David Harris for implementing it and showing me how powerful it is) and the pref you use user_pref("editor.singleLine.pasteNewlines", 3); are really workarounds to a fundamental problem in the code. A question for you (that is, for Hermann), what is the diff between the default setting of the pasteNewlines of 1, and 3? For that matter, what does setting it to 2 accomplish?

Please discuss that elsewhere. Thanks.

I'm not sure why discussing a workaround to this bug, and any possible side-effects it may have should be discussed anywhere but here. At least I'm willing to work on the problem.

Because it doesn't help to resolve this bug. This is not a user forum. Short hints to workarounds are fine, discussion about it is distracting spam. Even more so such meta-discussions.

*** Bug 216525 has been marked as a duplicate of this bug. ***

*** Bug 253284 has been marked as a duplicate of this bug. ***

*** Bug 299975 has been marked as a duplicate of this bug. ***

*** Bug 339961 has been marked as a duplicate of this bug. ***

Bug 344288 fixes this for the format=flowed part.

(sorry for the last dupe -- searched for URL not link). Wanted to ensure that w3c mention was recorded: The W3C convention http://www.w3.org/Addressing/URL/5.1_Wrappers.html is to put <> around long links <http://mozilla.org>. Thunderbird doesn't recognize this convention, so, long links that start with < still wrap, making them un-clickable (and a royal pain for users that have to do multiple cut and paste).

> put <> around long links <http://mozilla.org>. > Thunderbird doesn't recognize this convention Actually, it does. There's even *special* code in mozTXTToHTMLConv for it, to cross linebreaks etc.. Read above what the code problem is.

Wow, bug number 5351 and still unresolved. A screenshot showing that this is still a problem, maybe someone wakes up now?

Ben, that's great news that you assigned yourself to fixing this bug. I'm sure you can do it, because you're an experienced coder with deep insight on the matter from your own contributions. You'll make history when you address some of these long-standing issues. Looking forward to your ideas and patches on this bug. :)