140099 - attachment [CR] 2 is made into a link incorrectly

Status: RESOLVED DUPLICATE of bug 105865

(Bugzilla :: Attachments & Requests, defect)

Description

[Philip White]

Look at the second comment in bug 140055.
Mozilla created a link that spans multiple lines.

Comment 1

[Dave Miller [:justdave]]

Absolutely no way to avoid that.  If you look at your own comment 0 in this bug,
what would have happened if that had wrapped onto the next line between the word
bug and the 140055?  In that case you still would have wanted it to link, right?
 There's no way for the linking algorithm to tell that the number at the
beginning of the next line doesn't really belong to the link.

Comment 2

[Philip White]

Actually, I would never type "bug <Enter key> 1001".  If I mean it to be a
comment # or a bug #, I would put it on one line.  In fact, usually the only
time people use linebreaks in a form like this is when they start a list or a
new paragraph.  Either way, you should not assume it's a link when they use a
linebreak.

Comment 3

[Dave Miller [:justdave]]

But you aren't typing a linebreak, your browser is adding one if it happened to
wrap.  Bugzilla has no idea if you typed it on purpose or if it was wrapped by
your browser.

Comment 4

[Philip White]

Since when does any browser add CR/LF character(s) to form input?

Comment 5

[Dave Miller [:justdave]]

Since Netscape Navigator 4 and MSIE 4, when the "wrap=hard" attribute is added
to the TEXTAREA input element.  Yes this is very non-standard HTML.  See bug
11901 for our efforts to correct this.

Comment 6

[Philip White]

I see.  Thanks for providing such timely support.

Comment 7

[Philip White]

I am reopening this bug because I thought of a solution that will fix the bug
without having any side effects:
Check to see whether the line with the first part of the link is shorter than
any other line.  Here's an example of a submission:

This is line number one of my bug report.
Info from my attachment
1 [details] [diff] [review]. shows various stuff
2. shows more stuff.

In this case, we see that the first line is longer than the line with the first
part of the potential link ("attachment"), so we know that the user explicitly
pressed Enter -- the browser did not hardwrap it.  Because we know this, we know
that we should not make this into a link.

Does anyone see any problems with this setup?

Comment 8

[timeless]

counter example:
http://bugzilla.mozilla.org/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=&product=Browser&component=Preferences%3A+Backend&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=---&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&remaction=run&namedcmd=beos-checkins&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
this line is shorter than the line that preceeds it but ... see some attachment
200000 [details] [diff] [review] * 20000 = 40000000000

In the above, there's some special dispensation from silly browsers (in my case
mozilla), which allows a single word (most typically a url) to exceed the hard
wrapping limit.

you /might/ be able to rely on the longest whitespace containing line instead.

Comment 9

[Max Kanat-Alexander]

This is perhaps possible to resolve after bug 11901, I suppose.

Comment 10

[Frédéric Buclin]

*** This bug has been marked as a duplicate of 105865 ***