attachment [CR] 2 is made into a link incorrectly

RESOLVED DUPLICATE of bug 105865

Status

()

Bugzilla
Attachments & Requests
--
minor
RESOLVED DUPLICATE of bug 105865
16 years ago
6 years ago

People

(Reporter: Philip White, Assigned: myk)

Tracking

Details

(URL)

(Reporter)

Description

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

Comment 2

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

Comment 4

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

Comment 6

16 years ago
I see.  Thanks for providing such timely support.
Depends on: 11901
(Reporter)

Comment 7

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

Updated

16 years ago
Component: Creating/Changing Bugs → attachment and request management

Comment 9

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

Comment 10

13 years ago

*** This bug has been marked as a duplicate of 105865 ***
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago13 years ago
Resolution: --- → DUPLICATE
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.