Look at the second comment in bug 140055. Mozilla created a link that spans multiple lines.
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.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
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.
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.
Since when does any browser add CR/LF character(s) to form input?
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.
I see. Thanks for providing such timely support.
Depends on: 11901
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?
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Component: Creating/Changing Bugs → attachment and request management
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.
This is perhaps possible to resolve after bug 11901, I suppose.
OS: other → All
Hardware: PC → All
Summary: Making bad links for attachments → attachment [CR] 2 is made into a link incorrectly
*** This bug has been marked as a duplicate of 105865 ***
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago → 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.