URL linkifying code should cross linebreaks [libmime][mozTXTToHTMLConv]

NEW
Assigned to

Status

--
enhancement
20 years ago
5 years ago

People

(Reporter: phil, Assigned: BenB)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Dependency tree / graph
Bug Flags:
blocking1.8b2 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Bug in libmime due to line-based stream processing. mozTXTToHTMLConv can do it.)

Attachments

(1 attachment)

(Reporter)

Description

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

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 1

20 years ago
Not really sure how to attack this, but I will give it a shot.

- rhp

Updated

20 years ago
Target Milestone: M6

Updated

20 years ago
Target Milestone: M6 → M7

Comment 2

20 years ago
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
(Reporter)

Comment 3

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

Updated

20 years ago
Target Milestone: M7 → M12

Comment 4

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

Updated

19 years ago
Target Milestone: M12 → M14

Updated

19 years ago
Target Milestone: M14 → M20

Comment 5

19 years ago
Unfortunately, this is non-trivial. Bumping way out.

- rhp

Updated

19 years ago
Assignee: rhp → mozilla
Status: ASSIGNED → NEW

Comment 6

19 years ago
With the rewrite that Ben Bucksch is doing, we will be able to detect across
linebreaks. Reassigning.

- rhp
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Depends on: 19251
(Assignee)

Comment 7

19 years ago
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.
(Assignee)

Updated

19 years ago
Assignee: mozilla → rhp
Status: ASSIGNED → NEW
(Assignee)

Updated

19 years ago
Depends on: 20212

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 8

19 years ago
I added comments on this subject to bug 19251.

Updated

18 years ago
Target Milestone: M20 → Future
mime=ducarroz
Assignee: rhp → ducarroz
Status: ASSIGNED → NEW
QA Contact: lchiang
(Assignee)

Comment 10

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

Updated

17 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 11

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

Comment 12

17 years ago
*** Bug 137583 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 13

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

Comment 14

16 years ago
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.

Comment 15

16 years ago
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.

Comment 16

16 years ago
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.
(Assignee)

Comment 17

16 years ago
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.
(Assignee)

Comment 18

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

Comment 19

16 years ago
see comments in bug #185032

any chance of getting this back on the front burner?

Comment 20

16 years ago
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
(Assignee)

Comment 21

16 years ago
>  | 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.

Comment 22

16 years ago
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.
(Assignee)

Comment 23

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

Comment 24

16 years ago
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.  

Comment 25

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

Comment 26

16 years ago
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.
(Assignee)

Comment 27

16 years ago
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.

Comment 28

16 years ago
Haven't heard anything from assignee on this one.  Perhaps it should revert to
NEW w/ HelpWanted keyword?
.
Assignee: ducarroz → sspitzer
Status: ASSIGNED → NEW
QA Contact: stephend

Comment 30

15 years ago
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.

Comment 31

15 years ago
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?
(Assignee)

Comment 32

15 years ago
Please discuss that elsewhere. Thanks.

Comment 33

15 years ago
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.
(Assignee)

Comment 34

15 years ago
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.

Comment 35

15 years ago
*** Bug 216525 has been marked as a duplicate of this bug. ***
Product: MailNews → Core

Updated

14 years ago
Flags: blocking1.8b2?

Updated

14 years ago
Flags: blocking1.8b2? → blocking1.8b2-

Comment 36

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

Comment 37

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

Comment 38

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

Updated

13 years ago
Assignee: sspitzer → nobody
Severity: normal → enhancement
Component: MailNews: MIME → MailNews: Backend
Priority: P3 → --
QA Contact: stephend → backend
Summary: MIME linkifying code should cross linebreaks → [mozTXTToHTMLConv] MIME linkifying code should cross linebreaks
Target Milestone: Future → ---
(Assignee)

Updated

12 years ago
Depends on: 344288
(Assignee)

Comment 39

12 years ago
Bug 344288 fixes this for the format=flowed part.

Updated

12 years ago
Duplicate of this bug: 372747

Comment 41

12 years ago
(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).
(Assignee)

Comment 42

12 years ago
> 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.

Updated

12 years ago
Duplicate of this bug: 382790
Product: Core → MailNews Core

Comment 44

10 years ago
Created attachment 352704 [details]
screenshot

Wow, bug number 5351 and still unresolved.

A screenshot showing that this is still a problem, maybe someone wakes up now?
(Assignee)

Updated

9 years ago
Duplicate of this bug: 522893
(Assignee)

Updated

6 years ago
Summary: [mozTXTToHTMLConv] MIME linkifying code should cross linebreaks → [mozTXTToHTMLConv] libmime URL linkifying code should cross linebreaks
(Assignee)

Updated

6 years ago
Summary: [mozTXTToHTMLConv] libmime URL linkifying code should cross linebreaks → URL linkifying code should cross linebreaks [libmime][mozTXTToHTMLConv]
(Assignee)

Updated

6 years ago
Whiteboard: Bug in libmime due to line-based stream processing. mozTXTToHTMLConv can do it.
Duplicate of this bug: 498139
(Assignee)

Updated

5 years ago
Blocks: 913768
(Assignee)

Updated

5 years ago
Assignee: nobody → ben.bucksch
(Assignee)

Updated

5 years ago
Component: Backend → MIME
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. :)
Duplicate of this bug: 99298
Duplicate of this bug: 107141
Duplicate of this bug: 165436
Duplicate of this bug: 174220
Duplicate of this bug: 314409
You need to log in before you can comment on or make changes to this bug.