Closed Bug 11901 Opened 25 years ago Closed 20 years ago

Change Bugzilla comments line-wrapping policy

Categories

(Bugzilla :: User Interface, defect, P1)

Product:
Bugzilla
Component:
User Interface
Version:
2.10
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Bugzilla 2.20

People

(Reporter: CodeMachine, Assigned: mkanat)

References

(
URL
)

Details

Attachments

(5 files, 9 obsolete files)

the screecopy in my bugzilla server
91.40 KB, image/jpeg
Details
some ideas on display time wrapping
450 bytes, text/html
Details
Version 4
17.29 KB, patch
gerv
: review+
justdave
: review+
Details | Diff | Splinter Review
a patch against bugzilla-2.20.1 thats does comment wrapping in browser
2.85 KB, patch
Details | Diff | Splinter Review
draft 2 of docs patch
804 bytes, patch
mkanat
: review+
Details | Diff | Splinter Review 
This is a request to change the way Bugzilla wraps its lines in
the comments/description field.

My understanding is that it currently uses a Netscape-only extension to force
hard breaks into the text.  This leads to everything being on one line in
browsers that don't support it, which includes Mozilla at this moment.

Is it necessary to do this?  It strikes me that this could be done server side,
which would mean standards-compliant methods could be used.  Or even better, let
the browser wrap the text, so that it will resize to the window?
Is that really a netscape-only feature?  Not working in Mozilla just sounds like
a bug in Mozilla.  Does it also not work in IE?
This was stated in bug #2442.  It was recently marked as a dupe of bug #8984
which says it is supported in IE4 - I didn't see that till just now.  Whether it
is a part of HTML 4 is a question to be asked.

But, I still feel that if there are clients that don't do this, they should
still be supported - it depends on how many there are of course.  The current
behaviour from Bugzilla is not attractive.  =)

Either way, the comment about expanding to fill the screen still applies -
running at 1024x768, I get large blobs of white space on the right side of the
screen.
I'm no HTML expert, but I gather this is because of the use of the
<PRE>...</PRE> in the HTML.  If straight HTML were used, shouldn't the comments
should soft wrap nicely?  I presume there's a reason a <PRE> was used, what is
it?

If this was done, we could also get a 100% screen width textarea (I think?),
which would be cool.
Presumably comments are PRE so as to allow for ASCII art in comments?

Both Navigator (since 2.x) and IE (since 4.x) support the WRAP attribute of
TEXTAREA, but it's not in any HTML recommendation. Unfortunately, if WRAP is not
specified, then Navigator's default behaviour is *not* to soft-wrap text when
entered. Which could be annoying. So I'd suggest this bug be RESOLVED LATER, when
all Bugzilla users are using Mozilla and this problem doesn't occur.
Actually, cancel that previous suggestion. I forgot the original point of the
bug, and that is not HTML compliance per se, but that Bugzilla should be
inserting line breaks server-side rather than client-side.
*** Bug 18141 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
This has been the most annoying bug of late. All of my comments and even some
initial reports haven't been wrapping which makes it really difficult to read
earlier posted comments/reports of mine. Sad thing is, didn't really start
cropping up until M14 builds.

tara@tequilarista.org is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara
Status: ASSIGNED → NEW
This has gotten better but still doesn't work like it should. Browse some of the 
recent posts - they appear to be double spaced. Or some will even fail to wrap 
altoghether (run of the end of the page). Horizontal scrolling is bad.
Status: NEW → ASSIGNED
One thing to be said, with the current client-side behaviour, the width
of the textarea should be 72 characters and not 80...because the comments
get emailed out without any further processing.

I've changed this in our Bugzilla installation.

the double-spacing is a problem with the Mac version of Netscape - see bug 
32000.

The failure to wordwrap (causing horizontal scrolling) is due to this bug, 
because Bugzilla's depending on a Netscape extension to do the wordwrapping on 
the client-side, and not all browsers support it.

Yes, I think we should still use a fixed-width font.
QA Contact: matty
Whiteboard: 3.0
*** Bug 29051 has been marked as a duplicate of this bug. ***
Moving to real milestones...
Whiteboard: 3.0
Target Milestone: --- → Bugzilla 3.0
Taking all Bugzilla 3.0 bugs -- congratulations to MattyT for the triage, it
really was spot on. Note: I may end up pushing some of these bugs back to 3.2,
we'll see. However, I believe all these bugs should just fall out of the 
redesign. Let's hope I'm right!

(Note: I'm also resetting the priority field to "---" so that I can retriage any
that I consider important or likely to be dropped.)
Assignee: tara → ian
Status: ASSIGNED → NEW
Component: Bugzilla → Bugzilla 3
Priority: P3 → --
I just ran into this problem posting a bugzilla comment from Opera 5.02.  
Apparently Opera shows the text as wrapped in the textarea, but doesn't send 
the soft line breaks to the server.  (Opera 5.10 behaves the same way.)
As do any other HTML-compliant browsers.  The "WRAP=HARD" parameter inside the 
<TEXTAREA> tag is a Netscape extension, and not part of the HTML Standard.

Is there a W3C-approved way to tell browsers to send textarea data with hard 
line breaks included?
Not AFAIK, and even if so, we shouldn't be doing so.  Hard line breaks suck big
time in email, and they suck big time in Bugzilla.
I thought that lots of e-mail clients expect to see line breaks.
Yes, it's too late now to fix it for text mail.  That's one of the benefits of
HTML mail, and one reason I heartily support it.  But we can fix it for
Bugzilla.
*** Bug 75987 has been marked as a duplicate of this bug. ***
This would also fix the problem of really long URLs getting wrapped and not
getting hyperlinked properly.
There are still ramarkably more linebreak problems (infinite lines) in bugs that are Mac-related. So I post this comment with iCab (pre 2.5.1) to prove that this browser is one of those having/causing problems.
Greeting, Michi
The fact that iCab has this problem is only because iCab is standards-compliant.  
This is not a problem with iCab, but a browser-dependency issue with Bugzilla.  
Bugzilla uses a non-standard HTML parameter which is (as far as I know) only 
supported by Netscape and MSIE in order to get the browser to do the line 
wrapping for it.  The solution to this is to not use that parameter and do 
server-side line wrapping.  (read the initial comment when this bug was opened, 
that's exactly what it says there. :)

In other news, I'd like to know the justification for waiting until Bugzilla 3 to 
fix this. :)  This should be a relatively easy fix, other than people bickering 
about what the wrapping policy should be. :)  I'd like to nominate this for 2.16 
unless someone has some strong arguments against it.

Dave: you know the drill -- if you want it fixed, fix it! ;-)
Assignee: ian → justdave
Component: Bugzilla 3 → Bugzilla
Whiteboard: 2.16 (?)
Target Milestone: Bugzilla 3.0 → Bugzilla 2.16
I'd be much obliged to ;)  As soon as the rush is over at Syndicomm (probably a 
week or two).
Status: NEW → ASSIGNED
*** Bug 82700 has been marked as a duplicate of this bug. ***
Priority: -- → P2
Whiteboard: 2.16 (?)
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → 2.10
Whiteboard: [content:comments]
*** Bug 101298 has been marked as a duplicate of this bug. ***
Bug 101298 is actually not about lines not being line-wrapped; it's about
a long link which is broken because it's wrapped and truncated. From my point
of view, it not a question of polivy but rather to make the wrapping correct
once it's done. I question the "duplicate"status, but this should be judged
by the module owner.
The issue has been discussed on this report and is a part of the wrapping
policy.  The current wrapping method makes it impossible to deal with URLs
properly.
Sorry, I missed that
*** Bug 102522 has been marked as a duplicate of this bug. ***
Blocks: 52060
No longer blocks: 52060
Severity: normal → blocker
Component: Creating/Changing Bugs → User Interface
Priority: P2 → P1
adding to 2.16 block list, fixing component.
Blocks: 52060
Comment on attachment 55443 [details] [diff] [review]
patch to provide display-time wrapping

Just in case anyone is curious how this works:

>+        my $quoted_text = quoteUrls(\%knownattachments, $text);
>+        $quoted_text =~ s/\n/<br>\n/gs;
>+        $quoted_text =~ s/ (?= )/&nbsp;/gs;
>+        $result .= "<TT>$quoted_text</TT>\n";

This does to the text everything that a <PRE> does, except that it doesn't disable the
browser from wrapping the lines if they're too wide to fit on the page.

first we do the html_quote on the whole thing, which is done by the quoteUrls routine,
as well as turning all the hyperlinks into real links.

Next we take all linefeeds and insert a <br> at that location to make it wrap.

After that, we take any occurance of two spaces in a row and change the first of those
two spaces into a non-breaking space entity.  This way it preserves the formatting.

Then we enclose the entire thing in a <TT> block, which tells the browser to use a
monospace font, but doesn't tell it to preserve formatting like a <PRE> does (because
we've already done that ourselves).

This patch only accounts for the display-time wrapping.  The "wrap=hard" still needs to
be removed from everywhere else.  And the dependencies on Text::Wrap in the attachment
stuff can go away now, too.

The benefits of doing it this way are:

a) it will automatically fix the display of all the old comments that are already
   lacking linefeeds
b) it will now be possible to purposely make your comments wider than 80 characters 
   if you want to, and it will still look good in everyone's browser.
Matty mentions that we might need to do something about tabs also, as well as
spaces...  is that something we need to worry about?
This patch is very nice as it stands, but you mention it will be accompanied by
the removal of wrap='hard' all over the place.

I may be misunderstanding the implications of this, but any solution to this
problem which breaks the behaviour that: 
"Someone types a comment of multiple lines into a Bugzilla comment box and hits
submit, and it turns into HTML which is in a monospace font and wrapped at 80 chars"
will be strongly opposed by me.

I do not want Bugzilla comments extending the width of my browser window,
however wide it is. This makes them much harder to skim read.

If you want to store them without linebreaks in the DB, fine - I don't care :-)
But they must be broken at 80 chars (unless there's a URL more than 80 chars
long) for display.

Gerv
It will still be in a monospace font, it will just extend to the browser width,
which will bug the bug shorter and much easier to skim read.
I disagree. When I'm skim-reading, I have a certain number of degrees of vision
on which I can pay attention. I can skim-read a current comment column without
moving my eyes or my head. If it were twice as long, that would be impossible -
I'd have to move my head for every line, and it would really slow me down.

I'm serious. Make it a user pref if you must, I don't care - but I want my
comments wrapped at 80 characters. It's like source - my brain's wired to that
width.

Gerv
I'm with Gerv.  I find it easier to keep my place in text when the lines aren't 
too long.
Gerv, are you kidding?

You sound like a Win-DOS-AOL user who never found out that he can resize his
browser window. If you feel that lines are too long for reading simply resize
your browser's window to make line length fit to your needs!

Maybe I would like reading bugzilla at 65 characters line length. Allmost each
solution that hardbreaks lines after 80 chars makes this impossible or at least
very uncomfortable.

Allmost! Don't forget: we have Mozilla, the UA with the best CSS2 support. So
there is a solution:

.posting {font-family: monospace; max-width: 76ex;} 
Like I said, I don't mind if it's a user-pref option. But I think you will annoy
a lot of people if you change this unconditionally. And I'm beginning to
understand what Trudelle means when he complains about having to write CSS to
get the old behaviour.

People spend a lot of time in Bugzilla, and have got very used to how it looks,
warts and all. We shouldn't change that without good reason - for example, the
query.cgi change is a big usability win, and is going through careful review.

Gerv
Attached patch Patch v2 (obsolete) — — Splinter Review 
This patch includes the removal of the dependencies on Text::Wrap, and all of
the wrap=hard attributes in the affected textareas.
Attachment #55443 - Attachment is obsolete: true
Depends on: 53009
Comment on attachment 58498 [details] [diff] [review]
Patch v2

As a more visual indicator that the polocy has changed, the textarea would not
wrap at all,
instead of wraping when you type your comment and then having a different wrap
once your
comment is displayed (like this textarea I'm typing in now... but maybe that
defeats the
purpose of this bug in the first place, so I won't withhold review over it :)

r=jake
Attachment #58498 - Flags: review+
Interestingly enough, my last comment demonstrates that the edit attachment
textfield (the big one if you click on "Edit As Comment") makes it look like you
can pick your own formating, but under the current policy, you can't. (which is
a recent change when attachment.cgi was "finished".
Comment on attachment 58498 [details] [diff] [review]
Patch v2

I am strongly opposed to this patch going in until it provides some way for me
to keep the display comment wrapping at 80 characters, so things still look the
way they do now.

I'm serious - this is not a whim. The change would be a major usability loss
for me, and, I believe, others.

Gerv
Attachment #58498 - Flags: review-
I'm with Gerv on this one. Testing on landfill in bug no. 274 leads me to
believe that most of the paragraphs will be a lot harder to read if I leave my
browser window maximized. And I don't think I want to be forced to make my
browser window smaller just to read bug comments. 

There is another aspect, though, that might be even more serious: There are
situations when you want to find some information in a bug, and you know you
have read the information before. The bug has gotten long, with a lot of
comments, and you scan through the comments. If the wrapping is dependent on the
browser width, it is very likely that you now have a different wrapping than you
had at the first time you were reading the information. If you are a visual
type, you won't be able to recognize the information as easy as if it appeared 
with the same wrapping as before.

Bugzilla comments are not in HTML, and I doubt it's a good idea to apply HTML
line wrapping in this case. 
Also, what seems to have been forgotten is the excellent point that people wish 
to submit comments with ASCII art in them. Unless the lines wrap at a consistent 
point, and a fixed-width font is used, this is impossible.

If we want to eliminate WRAP=HARD, then we must wrap at 80 characters on the 
server side, before storage in the DB. I.e. get the server to replicate what 
the browser now does. Only this way will everyone see all comments as the author 
intended.

Gerv
hard wrapping isn't great either.  please only hard wrap at whitespace.

ruler: 
1234567890123456789012345678901234567890123456789012345678901234567890123456789
0
url: 
http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/locale/en-US/uni
x/platformNavigationBindings.dtd
/testcase.
this comment was composed w/ nc4.78 i'll repeat it w/ other browsers if it 
turns out incorrectly.
ruler: 
12345678901234567890123456789012345678901234567890123456789012345678901234567890
url: 
http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/locale/en-US/unix/platformNavigationBindings.dtd
/testcase. this comment was composed w/ mozilla
This patch does deal with ascii art by displaying in a fixed width font using 
<tt> and changing all newlines to <br>. Perhaps if there was no wraping at all 
in the textbox so if you typed more than 80 characters without a newline your 
textbox would show you a bottom scrollbar (like I suggested in comment 46). 
That way it's obvious to the user who's typing where they're line will wrap 
(as is currently the case with the wrap=hard in supported browsers). I'm still 
not sure how to do this using valid HTML.
Timeless is right; only hard-wrapping at whitespace solves the URL truncation
problem which is part of the reason for this bug.

Jake's solution is also unacceptable; I do not wish to have to remember to press
"Enter" at the end of each of my lines when entering a Bugzilla comment in order
to be able to review it properly when I've finished typing it. 

What will happen is that people will then waste a load of time formatting their
comments and re-wrapping them in the edit box.

A multi-line text box should support multiple lines properly, in the same way as
anyone would type into a native multi-line text box. This "scroll rather than
wrap" behaviour is horrible, ugly, counter-intuitive and user-unfriendly.

Gerv
As timeless also demonstrated in comment 51, not all browsers are intelligent 
enough to not wrap a long URL when you have wrap=hard turned on.  Also 
demonstrated in comment 24 (as well as various other comments in other bugs) is 
the fact that not all browsers support wrap=hard.  And I (unintenitionally) 
demonstrated in comment 46 that Text::Wrap may wrap different that it appeared 
while it was being typed.  Text::Wrap also adds a new dependency and the min. 
version we currently require breaks other apps that were written using the 
Text::Wrap that ships with perl 5.6 (at least I think I remember Dave saying in 
IRC that he was having that problem).  And this patch is shot down because it 
allows the lines to be longer than 80 characters.

I, personally, don't think a textbox that doesn't wrap at all on its own is any 
uglier than other places where plain text is edited, but I do admit that 
editing a paragraph when the text doesn't wrap (such as using notepad or 
similar editors for HTML source) is a pain.

Currently, all possible solutions to this problem (including WONTFIX) have been 
shot down.  Perhaps we can change the comment header to provide better visual 
seperation of comments (a background color or something)?
Text::Wrap is complex, and deals with Mail and stuff IIRC. What we want is
fairly simple - wrap at the first space before 80 columns or, if none, at the
first space after 80 columns. Writing a routine to do that for an arbitrary
string of text should not be a complicated thing.

Or am I missing something?

Gerv
>Text::Wrap is complex, and deals with Mail and stuff IIRC. What we want is
>fairly simple - wrap at the first space before 80 columns or, if none, at the
>first space after 80 columns. Writing a routine to do that for an arbitrary
>string of text should not be a complicated thing.

Text::Wrap is simple actually, and does just what you describe (and not much
else).  Perhaps you are thinking of Text::Autoformat, which is a much more
complex formatting module especially designed for formatting mail.


I was about to add a new bug, but it isn't appropriate, I can see. There is a definite problem under 
Opera, in that it doesn't interpret the sequence &#013 correctly (from sub value_quote in 
CGI.pl). Note that this has nothing to do with wrapping policies.
*** Bug 115649 has been marked as a duplicate of this bug. ***
No longer depends on: 53009
I've fixed this in our installation of Bugzilla.

The decision was made in value_quote() to turn all variants of carriage returns
into &#13; and in quoteUrls() in globals.pl there is what I believe is an
out-of-date attempt to fix this, namely:

$text =~ s/\&#010;/\n/g;

I changed this to:

$text =~ s/\&#013;/\n/g;

and the nasty (and invalid) "&#013;"s disappear from the long descriptions.
Brent/John: that's already fixed in cvs, and has nothing to do with this bug.

See bug 82809.
Are we going to reach an agreement here? :-)
The current situation leaves the following people unhappy:

- people who want comments to span the full width of the browser.
- people who want Bugzilla to use only W3C HTML.

iCab and Opera users aren't really inconvenienced - it's just a pain for
everyone (inconsistency) that text they submit isn't wrapped. But there are very
few of them - I know I rarely see extra-long comments.

I can't easily see how any change will make less people unhappy.

Any solution should meet the following goals:
- Text in the "Additional Comments" box should wrap when you type it (as now),
rather then producing a horizontal scrollbar, in (at a minimum) NS, Moz and IE 
- Users should, by default, see the same comment behaviour - <TT>, and wrapped
at 80 chars - as now.
- ASCII art should always display correctly (as now)

It may optionally have one or more of the following features:
- standard HTML
- user preference to make comments span the full width of the browser.

If someone has a solution, let's hear it. Otherwise, we are stuck with the
status quo, and cursing the HTML 4 spec for not forseeing this problem.

Gerv
The only reason this could be a 2.16 blocker is for HTML compliance reasons.
However, it's such a big issue that I really don't think we'll produce a
solution in time, given the other bugs.

I say we should push this out.

Gerv
*** Bug 127551 has been marked as a duplicate of this bug. ***
As much as I hate to admit it, I agree. ::sigh::

If someone manages to come up with a good patch for this before we go release
candidate, we can move it back.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
> If someone has a solution, let's hear it.

As I see it, there are four choices.
1.  Rely on the submitter's browser to wrap the text. But this only works in
    non-standards-compliant browsers like Mozilla and MSIE, which is why this
    bug was filed in the first place.
2.  Wrap the text when it is received (during enter_bug.cgi and friends), before
    storing it in the database.
3.  Store the text in the database exactly as it was submitted, and wrap it only
    when it is sent out by show_bug.cgi.
4.  Rely on the reader's browser to wrap the text. But this won't work for Gerv,
    since his browser window is too wide for comfortable reading, and he lacks
    the energy to resize it. :-)

Option 3 seems the best choice, since it works for Gerv, and since it's
forwards-compatible with any of the other options if we change our minds in the
future. What am I missing?
Option 3 makes those people who want comments at window-width unhappy, unless
it's possible to turn the wrapping off with a param. It's also extra processing
- every comment that's ever printed has to go through Text::Wrap (or whatever
code we use to do the wrapping.) And it has to go through it every time, even
though the result is always the same.

Someone above suggested a CSS solution:
.posting {font-family: monospace; max-width: 80ex;} 

Does this Do The Right Thing at all, or is this also unsatisfactory?

Gerv
Blocks: 47251
Urls that are too long can be split into two urls if its longer than 80 chars
(i.e. carrying it over to the next line wouldn't be enough) - for instance
http://www.mozilla.org/ (let's pretend it is 81 chars at the "m") could be
turned into the html <a href="http://www.mozilla.org">http://www.</a><br><a
href="http://www.mozilla.org">. I think leaving it up to the user agents to
display it correctly is not a good idea since it sounds like Opera went against
the spec.

http://www.w3.org/TR/html4/struct/text.html#h-9.3.5

"By convention, visual HTML user agents wrap text lines to fit within the
available margins. Wrapping algorithms depend on the script being formatted."

Is using CSS a good idea in a cross-browser system? Remember, it is used no more
than bugzilla.mozilla.org.

What if the comments were stored without breaks in the server, and then - as mpt
mentioned, wrap on the fly, and to solve gerv's comment - there could be a Wrap
Cache in order to keep track of the most recent breaks (as many bugs are not
looked at much anymore and therefore it should only be the most commonly looked
at bugs that we worry about in terms of bogging down the server).

To make those people who like it all on one line wherever there isn't an
intentional line break happy, there can be a pref for it.

If we have to implement a "wrapping cache" in order to have the server wrap the
comments effectively, then I don't think the server should be responsible for
wrapping comments.  It would be making the system too complicated for such a
simple thing.

In addition to mpt's four suggestions in comment 67 we could:

5. Standardize on a maximum width.  Comments with lines greater than this width
that also contain white space would be rejected.  This would allow for URLs
greater than the maximum width.
by rejected i hope you mean returned to the user in a text area with suggested
wrapping so the user can resubmit.

anything else is serious dataloss since it's possible for a browser to refuse to
retain the submitted text when the user tries to go back.

personally I think we should just reformat and return it to the user for approval.  
I was thinking of just putting up an error message and have the user hit back on
the browser to re-format his comments.  Bugzilla already does this when
verifying other data (milestones, comments required, etc.).  However, I think I
like your idea better.
> personally I think we should just reformat and return it to the user for 
> approval.  

You are joking, right? This would slow people down so much...

Gerv


i'm serious, but only in response to rejecting a submission.  If you take a
route that accepts the submission, then my suggestion is void.
Blocks: 140099
My suggest for solving this problem easily would be to make 
an automatic break 
in bugzilla server (when uploading a new text) after perhapes 
90 or 100 
characters only to unformatted text and leaving normally 
formated text (or 
normally formatted lines in a mixed text) with 79 or 80 
characters per line 
untouched and to remove the wrapping in the coment box 
completly. Maybe some 
kind of exeption can be made to very long lines that does not 
contain spaces 
(like URL's). 
 
So you can easily paste a formatted text from a text editor 
or what ever into 
the box without having the trouble of breaking it again... 
 
I was using several browsers: 
 
Until some weeks I was using Opera on Windows (version 6.0.1 
and before that 
some of the ver. 5) and sometimes Internet Explorer. 
 
Now since I kicked Windows completly out of my box I'm using 
Konqueror 3.0 on 
KDE 3.0 
 
I have noticed this problem with Opera and Konqueror (not 
sure if also with 
IE). All my formatted bugreports I have written so far in 
XMMS-Bugzilla  
(http://bugs.xmms.org) where hand formatted using a text 
editor (and then I was 
pasting the text into the Bugzilla form). So this wasn't and 
still isn't very  
comfortable. 
 
I realized with Konqueror a further problem (and I think you 
will see it in this 
post again): If I write in the coment box of the bugzilla 
form or if I paste 
unformatted text it will show it in a big single line, but if 
I format it to 80  
characters per line it will make a line break again. (compare 
also comment 46 in  
this bug). This seems to be Konqueror related but I think 
it's not wrong to 
mention it here also. 
 
And I think implementing one of the ideas posted here in the 
next release would 
be very nice even if it is not everyone likes it. Cause 
searching for a better 
solution for a major ugrade can go on, users can give 
feedback to the actual way 
and it would be much more comfortable for many users 
(especially reading a bug 
report written in a single line is annoying for everyone if 
he is using 
Netscape, Mozilla, IE or whatever). 
If we insert our own line-breaks, could it be made reversible? i.e. - could some
special character be inserted to denote a server-entered line break so that its
not confused with a user-entered one? i.e. - that way people could change it
from 80 to 100 lines by going through with a script and removing all the
"special" line breaks and reformatting. Can this be done without having to parse
out the "special" line breaks when displaying? 
Has anyone looked at changing the comments block to a soft line-wrapping block 
and then running the comment through Text::Format before writing to the 
database?


This patch permits the comment form to use "soft" wrapping instead of
hard-wrapping and then actually does the wrapping inside the AppendComment
routine.  The formula for wrapping is that the first whitespace seen after 72
characters into each line is replaced by a newline.  Then, the last whitespace
farther than 72 characters from the end of each line is replaced by a newline.

This seems to do a passable job of splitting up text without breaking long
URLs.
Isn't "wrap=soft" just as non-standards-compliant as "wrap=hard"?

Gerv
I'm not sure about the standards issue with the wrapping.  The critical item for
my installation is to have lines split without ruining long URLs.  Anyone have
any suggestions for the comment box's HTML syntax?


It seems to me, since there is no standards-compliant way that anyone here knows
of to force wrapping in a textarea, we have no choice but to do it as the page
is displayed. I think that's the best way, anyway, since it gives the
opportunity to make the width as wide as we want. It would be nice, though, if
people realized that some lines were going to be shortened if they intended to
make it really long by seeing it cut in the textbox.

Hixie: Do you know of any way to wrap lines in a textbox automatically that
follows the standards?
There is officially no such way to hard-wrap text boxes before form submission.
*** Bug 153887 has been marked as a duplicate of this bug. ***
Even if a solution which wraps comments when submitting forms, it's *still* necessary to (re)wrap them when displaying them. There are currently many comments in BugZilla which uses very long lines, and they're a real PITA to read. For an example, see <URL: http://bugzilla.mozilla.org/show_bug.cgi?id=156094 >.
Or your own submission, comment 84, itself. <grin>
Blocks: 157891
bug opened in 1999/08 and not fixed in 2002?

While the discussion is going on, can't we implement some temporary
fix, like a red warning message asking users to line-break their
messages on their own or simply turn warp off? This is a really annoying
bug.
The patch in attachment 84226 [details] [diff] [review] simply lets the web browser leave the comments
unwrapped and then wraps them in perl before submission.  For anyone being 
driven nuts by this, I suggest they try it.

As for the direction of the code, I see that someone has this running on landfill,
but I do not know which patch it is.

Does anyone feel that the approach in 84266 is a bad thing to do?
Joel: your patch is to fix the problem with URLs longer than 80 chars getting
broken by the browser? I thought Mozilla, at least, Did The Right Thing in the
long URL case.

Test:
http://bugzilla.mozilla.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

Gerv
The problem is that Bugzilla uses......

 <textarea wrap="hard" name="comment" rows="10" cols="80"

Which instructs many browsers to insert newlines at unfortunate places.
The patch takes out the wrap=hard and then handles the wrapping in a more
consistant and appropriate place.


> Which instructs many browsers to insert newlines at unfortunate places.

Which browsers? Not Mozilla, certainly.

Gerv
Blocks: 163218
No longer blocks: 163218
*** Bug 167051 has been marked as a duplicate of this bug. ***
I installed Bugzilla 2.16 on my server and it works fine for me with Mozilla (currently 2002090908 on WinXP). But when I use bmo, I don't get the warping (or at least, sometime I don't (see  http://bugzilla.mozilla.org/show_bug.cgi?id=124307#c51 as one example, there are plenty others))

Did something change in 2.17 or is it something else?
I just noticed that there are two warp attributes in bmo show_bug pages:
<textarea wrap=soft wrap="hard" name="comment" rows="10" cols="80" accesskey="c"></textarea>

That doesn't sound right.

(By the way soft is missing the quotes)
I can't reproduce that b.m.o problem.  What page do you notice it on?
This page for instance, as you can see on my comment 92 and probably this comment too if I can make it long enough (ok, that should do it).
Ok, never mind, I found the problem and it's on my side. I have an anti-ads
software (proxomitron). It seems that it adds the "wrap=soft", and for some
reason, it doesn't do it on my server.

(and this comment should correctly wrap)

Sorry about that.
*** Bug 169848 has been marked as a duplicate of this bug. ***
*** Bug 171596 has been marked as a duplicate of this bug. ***
I think Bugzilla should *not* depend on the browser doing the line wrapping, as 
it does now.

Instead it should either 1) word wrap on delivery (server-side, I guess using 
<br>) or 2) let the browser word wrap (client-side).

For these reasons:

1. It should be avoided to be *depending so deeply* on non-standard HTML 
(wrap=hard).
2. Storing hard wrapped text is a bad idea. Text should be formatted when it is 
displayed, not before. This is much more flexible.
3. Some browsers break long URL's (e.g., the latest IE 6 SP 1 does) when 
wrap=hard is set. This is a problem for *all* of us, regardless of what browser 
we use, when we have to read and use the broken URL.
4. Some browsers doesn't accept the non-standard wrap=hard and thus doesn't 
word wrap, giving all of us problems reading the postings from these browsers.
5. Word wrapping on delivery or letting the browser word wrap would show all 
previous non-word-wrapped postings correctly (at least if the word wrap limit 
is 80 characters or above).
6. Copying Bugzilla comments into a word processor or e-mail or anywhere else 
would be without hard line breaks in the middle of paragraphs. And that would 
be a Good Thing, IMHO. The text will be easier to work with.
7. It should be avoided using non-standard HTML in any case (see Bug 47251) 
(this is not the same as reason 1 above).

As mentioned by Gerv in comment 63, formatting server side would make people 
who want comments to span the full width of the browser unhappy. But these 
persons are already unhappy. This extra wish should not stop us from solving 
the problem with very long lines, a problem that we *all* have - and solving it 
for all previous postings. And on top of that, going away from hard wrapping 
text in the database would make it possible to 1) make a solution for the "full 
width people" later on, and 2) make local patches to get full width wrapping 
until that.

If *server-side* hard wrapping on delivery is chosen, I think the limit should 
be at exactly 80 characters, no more, no less.

If it is less than 80 chars, the existing hard wrapped data in the Bugzilla 
databases would wrap in an ugly manner, hard to read, because previous data has 
been hard wrapped at 80 chars.

If it is more than 80 chars, say 90, we can have problems when people copy 
quotes from other comments: These quotes will be hard wrapped because they are 
copied from hard wrapped HTML. And if sometime in the future someone wants to 
display this with less that 90 chars, say 85, he can't, because it will look 
ugly. In other words: Increasing the line length is irreversible - which is 
also why we can't go below 80 chars now (using server-side wrapping).

If *client-side* wrapping is used, we won't be so dependent on what line length 
we choose. When a user copies a quote from another comment, it will be copied 
as a full, non-wrapped paragraph, regardless of how it is formatted in the 
browser, and thus it will be posted that way again. It will also be easier to 
copy part of a paragraph into a new comment; you won't have to remove the line 
breaks.

So, my conclusion and opinion is that we should:

1. drop the wrap=hard attribute (maybe replacing it with wrap=soft for 
convenience), and
2. use either
   2a. server-side wrapping at 80 chars (except for long URLs), or
   2b. client-side wrapping at 80 chars or more using CSS.

Am I missing something?
No longer blocks: 47251
Jesper: doesn't sound like you're missing anything at all.  That sounds like
exactly what the plan is.  We're just waiting for someone to finish the patch. 
I was working on it at one point, but I have other things that are priorities
right now.
*** Bug 182537 has been marked as a duplicate of this bug. ***
BTW, this problem is exhibited in Apple's Safari browser. Any Bugzilla comments
posted with Safari end up being displayed as a single non-breaking line.
I've emailed hyatt to ask him about whether Safari will support wrap=hard.

Gerv
Hyatt says:

"We do plan to support it [that is, wrap='hard' - Gerv].  Our code is just
buggy.  We do actually see the attribute, we just mess up in the implementation."

Gerv
For anyone using Opera, you should be aware that the latest version (7.03) now 
supports "wrap=hard".  Avoid earlier 7.0x releases, which have wrapping bugs.  
As reported above, version 6.xx and earlier don't support "wrap=hard" at all.

Comment #99 is spot on, and the solution for the 2.18 milestone is solutions #1
and #2a in that comment, i.e. switch wrap=hard to wrap=soft and implement
server-side wrapping to 80 characters at time of delivery.  We can then deal
with the issue of client-side wrapping at a later date.

Dave, you mentioned in comment #100 that you don't have time to work on this,
but that was a while ago.  Has anything changed?
In that case, dust off attachment 84226 [details] [diff] [review] which does exactly that but doesn't chop
URLs in half.
Attachment #84226 - Attachment description: Line wrapping patch for 2.16-ish bugzillas → Line wrapping patch for 2.16-ish bugzillas - still works for 2.17.4
Attachment #84226 - Flags: review?(myk)
> switch wrap=hard to wrap=soft and implement
> server-side wrapping to 80 characters at time of delivery. 

This changes nothing from the perception of the user, right? 

One of the primary motivations for this bug appears to be Bugzilla's standards
compliance. How does replacing wrap='hard' with wrap='soft' help that?

What the above change would do is mean we are now storing comments in the
database in unwrapped form, and have to do some (granted, not much) extra work
in displaying them. Other than that, it has no user effect, so why is it worth it?

Additionally, I feel we shouldn't set out to "fix" this bug before having a
clear idea of where we want to end up.

Gerv
>> switch wrap=hard to wrap=soft and implement
>> server-side wrapping to 80 characters at time of delivery. 
>
> This changes nothing from the perception of the user, right? 

I am not sure about that. There is quite a bit of non-wrapped text in the Bugzilla database (e.g. comment 24 in this bug), because people have entered comments using browsers that didn't support wrap="hard". If we do server-side wrapping on delivery from the server to the user, these entries will be made readable, as well as future entries like these. This is a noticeable change. 

> One of the primary motivations for this bug appears to be Bugzilla's 
> standards compliance. How does replacing wrap='hard' with wrap='soft' 
> help that?

It doesn't, but this isn't exactly the case. In my reasons in comment 99, the motivation you mention is the least important one (number 7). The top reason that I mention (the selection and rating is of course my humble opinion) is that Bugzilla *depends* on non-standard HTML for doing the wrapping now, and that is a problem.

If we use wrap="soft", Bugzilla would not depend on it. It would just be a convenience that would help users of some browsers that don't do soft wrapping by default but do understand the non-standard wrap="soft" directive. It would *not* be necessary; we could omit wrap="soft" to comply with the standard, and that would be fine with me. Bugzilla would still function fine without it. It is not the same case with the wrap="hard" attribute now; we *cannot* omit that without implementing server side wrapping.

By avoiding wrap="hard" and doing server-side wrapping on delivery to the user, we avoid *depending* on a non-standard HTML attribute, and we would be sure to avoid infinite lines in the future (and in the past).

> Additionally, I feel we shouldn't set out to "fix" this bug before 
> having a clear idea of where we want to end up.

I agree. We should really think about this before changing anything that is irreversible, to be sure we aren't missing something.

A drawback I just noticed is that text which is hard-wrapped at more than 80 characters would be distorted when hard-wrapped again to 80 characters. Comment 36 in this bug is an example of this; it seems to be hard-wrapped at about 87 characters. I have no good solution to this problem.
The missing hard wrap in my previous posting (comment 109) was *not* intended --
 but it is quite illustrating... :o) 

It was my Proxomitron HTML filter messing with the HTML. I have turned it off 
now.

Need I say that incidents like this would be avoided (and solved for past 
postings too) if server-side wrapping on delivery to the user is implemented?
Please do not make it impossible for users to enter unwrapped text.

At the moment, in some cases when I want to enter preformatted text wider than
the historic and now relatively short 80 characters (for example for diagrams),
I can go in with the document inspector, remove the wrap attribute, and type away.
it seems what we want is, in most cases, text to flow freely to the window width
(as text in HTML would if it's not in a <pre> or otherwise constrained), but in
limited cases we want to have "<pre>" behaviour, to allow very long lines, or
shorter lines for code or ascii-art or whatever.

Short of going for the kind of thing used by blogging/bulletin board systems of
having some kind of limited markup available to the commenter, or having a
checkbox that says "don't wrap this comment", I can't see anyway of getting it
right all the time.  The question is then which compromise is least bad - having
everything wrapped by the server so the user can't ever control their own lines
(screwing up if the user/browser has wrapped stuff differently already), or
relying on the user/browser to do the wrapping (screwing up if the browser
doesn't implement the non-standard tag to do the wrapping and the user doesn't
fix it).
> it seems what we want is, in most cases, text to flow freely to the window 
> width

Actually, that's not what all of us want (at least, it's not what I want, and I
don't think I'm alone.) Did you read the whole bug? :-)

Gerv
>> it seems what we want is, in most cases, text to flow freely to the window 
>> width

> Actually, that's not what all of us want

I would say that it's what a good portion of people here want. (And is what the
original reporter, I believe, requested when he filed the bug.)  From my
perspective, text should be treated just as any other HTML text, and it should
flow to the window width.  There are only two times when there should be a
possible exception to this - when you have a single "word" containing no spaces
and which extends past the width of the window, such as with a long URL (whether
this should be "forced" to wrap anyway, or left alone is debatable), and when
the client has posted something with a hard return.  (Client submitted line
breaks should be honoured.)

Now, the real problem with this bug is that there's no agreement over either the
specifics or the general problem.  (While almost nobody likes the current
behaviour, there is no concensus on what it should be changed to.)

Proposals of the server wrapping text at an arbitrary width are, I think, doomed
to failure since it presupposes that either everybody runs with a Mozilla window
of the same width or that everybody wants to see the width set to the same
thing.  (I, for example, don't want a set width - I want it to flow to the width
of whatever my browser window currently happens to be.)  Any implementation
where a set width is used would have to be controlled via an account preference
so that individuals could set behaviour to their own browsing habits and
expectations.  They could input a right margin number, or indicate that it
should be wrapped "to fit" in some fashion.

Another problem with this bug is that debate is occuring about different things
at the same time.  It would be beneficial to break the issues down into its main
points and treat them as separate (although related) items / bugs.  For
instance, make this bug JUST about setting a right-margin on text (which would
control at which point text is wrapped - a hardcoded or user-defined value (and
if so what) or the browser width.  Then open a different bug for each exception
to the rule (i.e. one bug for where/how long lines without any spaces are
wrapped, another for how clients can manually force a wrap prior to the
right-margin), setting dependencies as appropriate.  Discussion would be much
more focussed and things could progress without the endless cycle of opinions
seen so far.  This bug, as it is, is trying to do too much at one time.
> I would say that it's what a good portion of people here want. 

My assertion is that a large number of Bugzilla users would find it irritating
if comments started being the full width of the browser. I and Jesse have said
that in this bug; I'm sure there are more of us.

Usability research:
http://usability.gov/guidelines/readscan.html
suggests that between 55 and 100 characters is optimal for a width, depending on
what you are optimising for. We use 80; on a 1024x468 screen in a standard
monospace font, I'd say the full width would be about 120 characters; on larger
screens or in a proportional font, much more.

> From my
> perspective, text should be treated just as any other HTML text, and it should
> flow to the window width.

Why is that your perspective? Aesthetics, or usability?

> Another problem with this bug is that debate is occuring about different 
> things at the same time.  It would be beneficial to break the issues down into
> its main points and treat them as separate (although related) items / bugs.

I disagree; we need a unified solution to all these related issues, and so it
makes sense to discuss them together.

Gerv

> There are only two times when there should be a possible exception to this - 
> when you have a single "word" containing no spaces and which extends past the 
> width of the window, such as with a long URL (whether this should be "forced" 
> to wrap anyway, or left alone is debatable), and when the client has posted 
> something with a hard return.

The text above shouldn't be rewrapped, otherwise the ">" prefixes will get mixed
in with the text.

   +------------------------------------------------------+
   | Diagrams shouldn't be rewrapped for obvious reasons. |
   +------------------------------------------------------+

Diffs shouldn't be rewrapped, otherwise the distinction between comments and
code will be hard to make.

   data:text/plain,URIs_shouldn't_wrap_either,_nor_should_they_lose_indentation.

Note the identation at the start of the previous line. It shouldn't be lost. In
fact, it is unclear to me exactly how to distinguish paragraphs from text that
shouldn't be wrapped. This paragraph started with a carriage return and will end
with one, with no hard returns in the middle.

0123 This sentence will too, but had better not wrap. 45678901234567890123456789
> I disagree; we need a unified solution to all these related issues, and so it
> makes sense to discuss them together.

I don't see how there can be a unified solution. We either have bugzilla
wrapping at a fixed-width, or at window-width, or only when the user/browser
inserts a hard return. The original report was complaining about the third, you
and Jesse don't like the second, and Hixie points out good reasons for rejecting
the first.

Unless one can have bugzilla do different things with different comments (or
even different bits of different comments), I don't see how there can be a
unified solution.
> I don't see how there can be a unified solution.

Absolutely.  Hence my earlier comment.  There is no concensus here and wheels
are simply being spun without resolution.  We can debate back and forth without
any progress.

There are really only a couple of ways of resolving these individual
preferences: setting up user profile based settings (so each person can
configure the right-margin, and other wrapping issues, as they want) and split
this bug into separate issues to make it more digestible.  (Since working on /
reaching a conclusiong about each piece of the puzzle is easier than the
seemingly impossible task of deciding the whole thing all at once.)

> The text above shouldn't be rewrapped, otherwise the ">" prefixes will get 
> mixed in with the text.

Correct.  Hence, carriage returns (such as I entered when reformatting the above
to get two lines each beginning with a ">") should be honoured.

> Diagrams shouldn't be rewrapped for obvious reasons.

Same as above.  Diagrams are entered by hitting "|" (or whatever symbol)
followed by a carriage return - which should not be ignored.

I don't think that anybody here really objects to carriage returns being
honoured - do they?  The real question is what to do with paragraphs of text.

> Diffs shouldn't be rewrapped

This one is problematic.  I see no easy way of accomodating this.  Unless there
is some mechanism of enclosing each line of the diff in a <don't reformat this>
type of directive.  But, that aside, a diff is (textually speaking) no different
than any other series of lines of text.  I think it would be a mistake to start
doing conditional programming of what Bugzilla does in this sort of case.  I
*especially* think that such considerations should not be part of this bug, but
 discussed in a different bug as an exception to whatever happens here. 
>> The text above shouldn't be rewrapped, otherwise the ">" prefixes will get 
>> mixed in with the text.
>
> Correct.  Hence, carriage returns (such as I entered when reformatting the 
> above to get two lines each beginning with a ">") should be honoured.

More than honoured -- they should prevent extra ("soft") line breaks being
inserted, a la:

   > this is indented
   text that
   > wraps onto two
   lines.

Also, the above had better not get rewrapped... and it has no "|" characters.
However, this paragraph does, yet it has to be wrapped. Go figure.
Just a couple ideas:
1-For those who don't have minimal permissions, provide radio buttons to set how
new comments will be wrapped
2-For those who don't have minimal permissions, provide two "additional
comments" boxes, one to which auto-wrap or something akin to current behavior is
applied, and another in which no wrapping is applied, forcing the commenter to
decide where hard returns go, and accepting pre-formatted comments to be pasted
in and accepted as-is.
Oh, also -- don't treat diffs as special cases "to be dealt with later". A large
proportion of Bugzilla comments are diffs. It is absolutely imperative that
diffs not get harder to read  -- in fact, there are already enough problems with
diffs that are larger than reviewers' <textarea> widths causing premature
wrapping; we should probably work to fix that before we work to fix the rarer
case of people using browsers with poor legacy attribute support.

I think adding radio buttons or whatever to control this is a bad idea. Most of
our users won't have a clue what they are about and will just get confused.
Solving UI problems by adding preferences is just moving the decision from the
experts (the programmers who understand the issue) to the users (who are highly
unlikely to understand, or care about, the problem).
> Solving UI problems by adding preferences is just moving the decision from the
> experts (the programmers who understand the issue) to the users

Yes, but the problem here is that the "experts" *don't* agree...
If we really can't come to an agreement, then whoever is the "owner" of Bugzilla
should just come down and make a decision.
> There is no concensus here and wheels are simply being spun without resolution.

I should point out (as I did in comment 63) that the status quo is a perfectly
valid option. The mere existence of a bug report does not mean that the issue it
concerns has to be "fixed".

In the absence of a solution which pleases all parties, why change the situation
to displease a different set of people to those who are currently displeased?

The two sets of people who are displeased with the status quo are:

1) HTML purists
2) People who want comments wrapped at full window width.

To the first group - hard cheese. And, given that the usability evidence
suggests that Bugzilla is more usable when comments are wrapped at 80 chars than
if they are the full width, I see no particular problem with saying hard cheese
to the the second group as well :-)

Gerv
The status quo hard-wraps on the way in.  That is the sole objection to the
existing patch.  If the status quo is OK, then the existing patch solves the
problem of breaking URLs and it should go in.

If we want to provide the ability for a "power-user" to get the same "benefit"
from the patch that they have by hacking with DOM inspector, we could tell the
patch to skip the wrapping if a comment starts with ^<pre>\n


> I should point out (as I did in comment 63) that the status quo is a perfectly
> valid option. The mere existence of a bug report does not mean that the issue it
> concerns has to be "fixed".

that comments posted with browsers which don't support wrap=hard are all on one
line is a problem. in fact, it's the problem that the original report focuses
on. the fact that wrap=hard is non-standard is, I think, secondary to the fact
that not all browsers support it, so it doesn't actually work in some cases.

> given that the usability evidence
> suggests that Bugzilla is more usable when comments are wrapped at 80 chars than
> if they are the full width, I see no particular problem with saying hard cheese
> to the the second group as well :-)

fine. but that fails to address the original report - the case that comments are
not wrapped at all (as in comment 109, comment 95, etc).

you can, of course, say hard cheese to that group as well (and as you've pointed
out, support for the non-standard wrap=hard has improved in Opera and Mozilla
since this bug was filed, so the problem happens less often in practice)...
> If the status quo is OK, then the existing patch solves the
> problem of breaking URLs and it should go in.

Hard-wrapping on the way in breaks URLs only on certain browsers (not Mozilla.)
Having a list of such browsers would help us in evaluating the necessity of the
patch.

Gerv
> 2) People who want comments wrapped at full window width.
> [...] more usable when comments are wrapped at 80 chars than if they are the 
> full width [...] hard cheese.

Your argument assumes that 80 characters is narrower than the window. This is
not always the case; in particular I have on several occasions recently had my
1600x1200 monitor so far from where I was sitting that I've had to increase my
font size to the point where 80 characters simply do not fit on the line. In
those cases, client-side late wrapping would actually be desirable. (When in
these situations I usually either guess at the last few words of each line,
scroll horizontally for each line, or quickly add in a temporary stylesheet with
"pre { white-space: -moz-pre-wrap; }" in it.)


Frankly I think that browsers that do not support wrap="hard", BUT show the text
wrapped in the text editor window, are broken. Given their rarity, I do not
think it is unreasonable to say that the bug is not with Bugzilla but with the
UAs in question. (Note that I am not advocating that these UAs implement a non-
standard attribute; I am advocating that they show what they are going to send,
i.e., they shouldn't wrap in their editors either, thus making it clear to their
users that if they want wrapping they have to do it themselves.)
(a user's perspective)

Everything worked fine until developers started using Mac OS X.  Whereas 
before, all bugs' comments were wrapped at 80 cols, Mac OS X users' comments 
now appear on a single long line.  Bugs with that problem are a pain in the 
neck.  To read the comments, you must use the browser's horizontal scrollbar.  
These comments are easy to miss when scrolling because their visual strength is 
reduced, and it is impossible to use only the mouse wheel to read a bug's 
entire set of comments.

I would disagree with the assertion that there is not a problem, but I would 
agree that there is probably no "perfect" solution, but I would bet that most 
Bugzilla users would benefit from comment text *always being displayed wrapped.*

If there must be a checkbox on the submit form and a column to store a "don't 
wrap this comment" flag in the longdescs table, great.

Let's go for what will satisfy 90% of the users.
Just out of interest, hat OSX browser is it that doesn't support wrap="hard"?
Gerv: 
> The two sets of people who are displeased with the status quo are:

> 1) HTML purists
> 2) People who want comments wrapped at full window width.

As Michael also mentions in comment 126, I think you forgot

3) People who don't want to use the horisontal scroll bar to read paragraphs 
that was not hard-wrapped by the browser when the user entered the comment, 
although it should have been.

I belong to group 3 -- and I guess most do? It is possible to be a member of 
more than one of these groups.


Joel Peshkin:
> we could tell the
> patch to skip the wrapping if a comment starts with ^<pre>\n

This could break existing comments, e.g. comments mentioning HTML code with 
<pre> tags, making them either meaningless or hard to understand because the 
<pre> suddenly would be missing. We have to think of all the existing comments 
in the Bugzilla databases worldwide. Hmm, not easy.

Ian:
> Frankly I think that browsers that do not support wrap="hard", 
> BUT show the text wrapped in the text editor window, are broken.

I disagree about that. I want the text to wrap, but I do not want the browser 
to deliver it with hard line breaks to the web server.


Hmm, with all the comments this far, I cannot see any good solution any more 
that solves the problems without creating new ones. But I hope someone comes up 
with a golden, creative idea to solve all the problems at once! :o)
>> Frankly I think that browsers that do not support wrap="hard", BUT show the 
>> text wrapped in the text editor window, are broken.
> 
> I disagree about that. I want the text to wrap, but I do not want the browser
> to deliver it with hard line breaks to the web server.

This may be going off-topic, but why?
> quickly add in a temporary stylesheet with
> "pre { white-space: -moz-pre-wrap; }" in it.)

We could certainly start adding classes to the <pre> tags around comments; that
way, you could just leave the user stylesheet in.

Jesper: I belong to group 3, but I'd much rather live with that problem than
those caused by most of the "solutions" proposed.

Floating an idea: we could fix problem 3 by intelligently wrapping at 80 chars
on the way _in_ for browsers that we know don't support wrap="hard".

Gerv
There's obviously a lot of traffic on this bug (witnessing the near 30 e-mails
in my Inbox this morning) and it seems that although the status quo might be
putting up with moldy, aged cheddar, they're certainly not content nor satisfied
with it.  

The main problem is not Bugzilla.  It is browser authors that either (a) are
standards purists, and refuse to implement the wrap="" attribute; or, (b) are
too lazy to include something that the majority of other browsers support.  We
are unlikely to change the minds of the developers in either of those camps, so
complaining to them that they "break Bugzilla" isn't going to have much effect.

Forgive my patronizing, but I recall a computer science teacher who taught me
the fundamentals of programming.  The two rules he mentioned for secure, solid
programs were to be forgiving in your input, but strict and standard in your output.

Right now, we are catering to nonstandard input and penalizing browsers that do
not implement that pseudo-standard.  Users with those browsers break our system,
so it's our responsibility to change our system and make it work despite those
buggy user agents (since, as discussed above, they aren't likely to be fixed.) 
To do this, it seems our only option is to implement server-side line wrapping.

But, how do we do it?  Letting the users decide introduces more UI cruft on the
bug editing/creation pages, 

My proposal is this:

1.  Store the comment in the database without wrapping.  User-added line breaks
should be the only line breaks within the comment.
2.  When the comment is called from the database, pass it through a function
that does two things:
  a.  Look up a parameter called line_wrapping, which is either 0 or a positive
  integer (default: 80.)  If the number is 0, skip the line wrapping; the
  maintainer for this Bugzilla has coded his templates so that they wrap to the
  window.  Otherwise ...
  b.  Parse the comment so that the lines break at the specified number of
  characters and preserve the user's line breaks.  If the line contains a URL:
     1.  If the URL is longer than the x-character limit by itself, place the
     URL on its own line (break before and after.)
     2.  If the URL exceeds the x-character limit by less than the amount of 
     other text on that same line BUT is less than the x-character limit, break 
     the line after the URL and keep it on the same line that it started on.
     Continue parsing the comment as usual.
     3.  If the URL exceeds the x-character limit by more than the amount of 
     other text on that same line BUT is less than the x-character limit, break 
     the line before the URL and continue parsing the comment as usual.
3.  When returned from the function, the comment will be in the desired,
parameter-set format (either wrapping to a specific line width or wrapping to
the container element's width.)

This satisfies the wrap-to-window/containing element group by providing a
mechanism by which they can have that functionality.  It also allows those that
prefer wrapping to a specific width to do that, and to start new databases with
that rule if they so choose.

I've personally been working on this as a private customization; my company
wants HTML formatting with selected tags within bugs (though not within e-mail,
thankfully) and since it involves line wrapping necessarily, this issue was one
I was working on at the same time.  I've not had time to implement it or even
test it, but I can post the very rough draft for review if anyone wants it.
Seth: That was discussed and we established it wouldn't work. See comment 116
and comment 119.

Gerv: I would be happy to see Bugzilla perform server side preprocessing of
input if the UA is know not to support wrap="hard" (or rather, if it is not
known that it does, since we really should default to assuming lack of support).
Ian: the procedures on what should and should not be rewrapped are something
that can be worked out later.  Whether or not the URLs get wrapped at a specific
point in the line really isn't the subject of my earlier comment.  They're the
most flagrant exception, though, and just because my comment didn't address
every exception doesn't mean those could not be built in somehow.  My point is
that we can satisfy both camps by allowing maintainers (rather than users, who
usually will not know of or care about the difference) to choose their poison
with a parameter, and let template customization take care of the rest.
While processing server-side the input of known non-working agent, is at least a
step forward, I don't know if it will be enough. 

First, there are way to change the user-agent string, so some broken browser
will be recognized as working and this not cutting the lines and some working
browser would be recognized as non-working which would recut some strings.

Second, even working browser has some troubles sometimes. With the default
policy of the proxy Proxomitron for instance, the textfield gets both warp=soft
and warp=hard. Warp=soft seems to take over (or maybe it's because of the order).

Don't know what I good solution would be though but having a user preferences
solution should satisfy every body (no wrapping, wrap a window limit, wrap a x
characters) except the bugzilla developpers maybe :)
It's great to see that this bug is still alive.  I've pulled together some 
questions (paraphrased) and answers based on the last day's worth of postings 
along with my proposed solution:

> Why fix it if it isn't broken?

It *is* broken.  Some comments (from browsers that don't support wrap="hard") 
are unwrapped, while others (like lines of code or quoted sections) are wrapped 
that shouldn't be.  Also, the current system is inflexible, since it doesn't 
provide any way to change our wrapping policy in the future or accommodate 
non-traditional devices/clients (small screens, third-party clients, etc.).

> What do we want to do?

We want to fix as much broken stuff as possible, regress working stuff as little 
as possible, make it possible to change Bugzilla's wrapping policy in the future 
(f.e. letting the user agent wrap or wrapping to a different width), and support 
non-traditional devices/clients.

> Does standards compliance matter?

Yes, but not at the cost of making Bugzilla work for users.  We should choose 
standards-compliant solutions where possible because of their overall benefits, 
but standards-compliance is a secondary goal; our first priority is making 
Bugzilla as usable as possible.

> Must this bug be fixed?

No.  We can resolve it WONTFIX if we decide that there is no good solution to 
the problem.  We can resolve it INVALID if we determine that wrapping is the 
user agent's and user's responsibility.

> What if we can't agree on a solution?

Then I, as the UI component owner, will make a decision about it.

> What if I think you're wrong?

Then ask Dave Miller, the Bugzilla project owner, to override my decision.

> What if I think he's wrong?

Tough, or as the Brits say, hard cheese.  Leaving the bug open and continuing to 
argue about it and consider it when thinking about other bugs is not better than 
making a decision--even one that some people disagree with--and then moving on 
to other issues.  Whatever we choose here (including not fixing the bug at all) 
will not be the end of the world; it'll still work fine most of the time for 
most people.

> What about a preference to control wrapping behavior?

Most people don't bother with prefs, nor should they have to.  We have a 
responsibility to make informed decisions for our users, and we shouldn't 
abdicate that responsibility just because a decision is hard to make.

> What about some UI to control wrapping behavior?

UI costs time and energy for users who have to fiddle with it.  We should 
provide the minimal UI necessary to allow users to do their work and hide 
functions that will rarely be used.

> What about a tag to control wrapping behavior?

That's not a bad idea, but it can only work for the 1% case (i.e. in rare cases 
when someone doesn't want the default behavior), so it doesn't answer the 
question of what the default behavior should be.  In any case, it shouldn't be 
an HTML tag or any tag we might expect to find in a comment.

> How wide should textual content be generally?

Not too wide, according to usability studies (see comment 115), which is why the 
current behavior to wrap at 80 characters is a pretty good one.

> So what's your proposed solution?

Server-side rewrapping to 80 characters at display time (or cached for 
performance), possibly using the Text::Autoformat module or other Perl modules 
available to us (otherwise rolling our own), for the following reasons:

1. it displays text almost exactly the same as the current system, so it is 
minimally disturbing to existing users;
2. it fixes the problem of browsers that don't support wrap="hard";
3. it makes it possible for us to change our wrapping policy in the future and 
to provide content to non-traditional devices and clients.

http://search.cpan.org/author/DCONWAY/Text-Autoformat-1.10/lib/Text/Autoformat.pm

> What about paragraphs which are currently hard-wrapped to more than 80 
characters?

If possible, they should be rewrapped to 80 characters.  Otherwise they should 
be left as-is.

> What about diffs and code?

They should be detected and not rewrapped.

> What about quotes?

They should be be stripped of quote markers, rewrapped, and then have quote 
markers added back to them.

> What about diagrams?

They should be detected and not rewrapped, and we should encourage users to make 
diagrams available as attachments rather than comments.

> What about all sorts of other wierd situations?

We use wrap="hard" almost all of the time, and users almost never override that 
intentionally.  We can implement something server-side which is at least as 
smart as wrap="hard" and probably much smarter, accounting for most situations 
in which users want typical 80-character wrapping overridden.  The rest are a 
limitation of this approach but not important enough to warrant WONTFIXing this 
bug.  

> What if it's not perfect?

It's not perfect now, and it never will be.  That doesn't mean we shouldn't 
improve the situation.

> What about letting installations decide wrapping behavior?

This can happen in a separate bug once we implement a solution that makes it 
possible.  Let's keep this bug focused.

> What if it's hard?

Then we should implement any solutions that mitigate part of the problem (like 
Gerv's idea to special-case known bad browsers) until someone has the time to 
implement this.

Hixie:
> Gerv: I would be happy to see Bugzilla perform server side preprocessing of
> input if the UA is know not to support wrap="hard" (or rather, if it is not
> known that it does, since we really should default to assuming lack of support).

Assuming that running the rewrap algorithm over text already wrapped by the
browser doesn't stuff it up, then that would be fine too.

Seth:
> My point is
> that we can satisfy both camps by allowing maintainers (rather than users, who
> usually will not know of or care about the difference) to choose their poison
> with a parameter, and let template customization take care of the rest.

Except you can't; because (in the b.m.o. case most flagrantly) different users
want different things in the same installation.

Myk:

I entirely respect your right as component owner to decide about this bug - it's
definitely a UI issue. A couple of clarification questions about your plan:

- I presume it removes wrap='hard'. Do you plan to use wrap='soft', or no wrap 
  attribute?
- Which browsers do the irritating all-on-a-single-line thing, and how do 
  we stop them? (Is wrap='soft' the answer to this question?)
- Could we make the new algorithm not apply to existing comments (by using e.g.
  the comment submitted date)? Would that be desireable?
- How are diffs, code and diagrams detected? Do we use a magic <nowrap> tag,
  or some heuristic?

Gerv
>- I presume it removes wrap='hard'. Do you plan to use wrap='soft', or no wrap 
>  attribute?
>- Which browsers do the irritating all-on-a-single-line thing, and how do 
>  we stop them? (Is wrap='soft' the answer to this question?)

My plan uses wrap="soft" for browsers that recognize it (which should be about
the same list as those that recognize wrap="hard") to wrap content in browsers
that don't do it automatically (f.e. Netscape 4.x and early versions of
Mozilla).  Sorry, I don't have a good list of browsers that do all-on-one-line
even when we specify wrap="soft", but I suspect that those browsers don't
support wrap="hard", so we don't lose anything in this respect by switching.

>- Could we make the new algorithm not apply to existing comments (by using e.g.
>  the comment submitted date)? Would that be desireable?

Yeah, we could do that.  As for desirability, it depends on what we get for what
we lose.  On b.m.o, for example, applying it to all comments fixes the existing
problems with wrap="hard" and possibly a bunch of poorly wrapped quotes, while
at the same time it probably messes up some other comments.  We need to see how
good we can get the section detection before we make a decision about this.

>- How are diffs, code and diagrams detected? Do we use a magic <nowrap> tag,
> or some heuristic?

My current thinking is that we use a heuristic (i.e. section detection) in most
cases so we don't make users have to deal with it.  For those rare cases where
expert users know we won't detect their sections correctly, we can provide a tag
to specify that sections (or possibly entire comments) shouldn't be wrapped.

IE5.5 breaks URLs, to name one.

Wrap=soft causes most browsers to wrap as they display the input, but not to
insert the breaks in the data.


It should be possible to wrap text at some "usability-guideline-friendly" fraction of the full window width, within a HTML tag. It should be easy to pick this size to be within Gerv's usability constraints.

This a) requires no processing of comment text and b) will also preserve _exact_ content as typed by the commenter if desired by the reader.

This will wrap _everything_, including URL's and diffs and diagrams, but because it is done dynamically in the user's browser at the time of display, it should be trivial to either provide a means of viewing a comment un-wrapped (eg, go to any html page with table-wrapped text and copy a paragraph into notepad, suddenly it is only one line), or to make the comment viewing area resizable.

Why not just put the comment viewing area inside a frame or iframe of a width that meets Gerv's usability constraints by default? (Is there some legacy browser targetting preventing this?) Then within that frame have a table of width=100%. Text within the frame should flow to fill the frame. If the frame is left resizable then if there is a diff or diagram that is mangled by this, the viewer can resize the window.

This is also a "cheaper" way to provide per-user width preferences than having Bugzilla process every comment to a user pref.

There are downsides though, such as making it more difficult to link to a specific comment (this can be acheived by allowing direct links to the frame to add a "view full report" button or something). The frame, when created by an actual report would include a form parameter to indicate that this need not be done (eg, frame=true).

It should also be possible, using javascript (again, only if such is allowed for bugzilla) to provide a resizing mechanism for non-frame HTML elements. The default size could still be defined by owners of Bugzilla installations, and/or controlled by individual users as a preference.

Note, this comment written in IE 6.0 SP1. Earlier versions of IE exhibited the non-wrapped bug bug. If this comment doesn't wrap, then I would submit that fixes that don't deal with this well will make Bugzilla less useful as a product for the non-mozilla crowd. *g*

Regards,
Sam
Wow, you guys have been busy chitchatting in here the last couple days.  Since
my comment was requested (about 20 comments ago or so I think), I just thought I
would chime in and mention that I don't have any additional comment, because Myk
just said everything that I could have (and more) in comment 138.  My personal
preferences for how to fix it were made known earlier in the bug.
Comment on attachment 84226 [details] [diff] [review]
Line wrapping patch for 2.16-ish bugzillas - still works for 2.17.4

This is doing server-side wrapping at submission time, whereas I think what we
need is server-side wrapping at display time.
Attachment #84226 - Flags: review?(myk) → review-
I like patch 84226 (we can celebrate its birthday in a couple of days).

- Incoming comments reach the database exactly as they would with the status 
quo and a browser supporting wrap="hard"
- Incoming comments from browsers not supporting wrap="hard" get fixed, making 
it look like they do support it

This leaves nobody any unhappier, but all those people happier who don't like 
too-long lines in comments. (This includes me, by the way.)

Did I miss anything?

I would like to see the patch checked in as an intermediate solution while 
working towards a final one, for example Myk's proposed solution in comment 138.
*** Bug 218904 has been marked as a duplicate of this bug. ***
Comment on attachment 58498 [details] [diff] [review]
Patch v2

Myk,

   Look this one over.	It does exactly what you are asking for without the
problem you mention for attachment 84226 [details] [diff] [review].  Perhaps you have a suggestion to
deal with Gerv's (-)....
Attachment #58498 - Flags: review?(myk)
We just migrated 2000 defects from another product (Jitterbug) and now we have a
database full of unwrapped descriptions. The defects that we used in the testing
of the migration were wrapped, but many of the latter ones, the ones that are
still open, are not.

I have applied the patch (attchment 84226) and so future defects won't be long
(forget the 72 or 80 debate I made it 132!--learn to move your head or sit
further back from your monitor)

Any suggestions, assistance, other comments, that might help convert the 9000
odd rows in longdescs? (PS this is another reason to wrap on fetch rather than
on post).
Walter Görlitz, add this to your /css/edit_bug.css and it should wrap perfectly.

div pre {
 white-space: -moz-pre-wrap;  /* Mozilla, supported since 1999 */
 white-space: -pre-wrap;      /* Opera 4 - 6 */
 white-space: -o-pre-wrap;    /* Opera 7 */
 white-space: pre-wrap;       /* CSS3 - Text module (Candidate Recommendation)
                                 http://www.w3.org/TR/css3-text/#white-space */
 word-wrap: break-word;       /* IE 5.5+ */
}

might as well add:
   white-space: -hp-pre-wrap; /* HP printers */
...while you're at it. :-)
Should have added, migrated to 2.16.4
It looks to me as though you're on a 2.17 branch.
Because the only cascading style sheets that I see are buglist.css and
panel.css, not edit_bug.css.
Also, the title seems to imply that it is called when editing, does this include
viewing (and with the additional patch, when printing to HP printers)?

Thanks for the info though.

PS: the roadmap doesn't indicate when a) 2.18 is planned for release and b) if
this feature will be a part of it. A road map without listing distance to the
next milestone is sort of, um, useless. (sorry about the additional commentary).
The roadmap does show what features are planned for the release, and states that
the release will happen when those features are ready.  That's by no means an
indication that other features won't be included in it, just that the ones
listed need to be.  You can't give a timeline unless there's folks being paid to
ensure it's met, and all the developers are volunteers working in their spare time.
Walter said:
> learn to move your head or sit further back from your monitor

Some of the studies referenced in other comments in this bug may cause you to
change you mind. Reading text that wide (in terms of number of characters) is
harder for the user.

Gerv
Severity: blocker → major
three comments.

Frist:
I understand that long lines text can be hard to read and comprehend. That's
from a user interface standpoint, but even 70 characters are too long for that.
My primary concern was that comments were 1) being cut-off when printing and 2)
that lines that are too short when printing waste trees (sorry--I'm a tree-hugger).

Second:
We are using the 2.16.4 version with data migrated from another product. So we
have no edit_bug.css to modify. I have found that if I edit header.html.tmpl and
add the following change after 
  <head>
    <title>[% title FILTER html %]</title>
that we get the desired effect. Migrated bugs are wrapped correctly and new bugs
are not wrapped in strange places.

[%# note: the following style tags are designed to wrap long messages %]

<style>
        pre {
         white-space: -hp-pre-wrap; /* HP printers */
         white-space: -moz-pre-wrap;  /* Mozilla, supported since 1999 */
         white-space: -pre-wrap;      /* Opera 4 - 6 */
         white-space: -o-pre-wrap;    /* Opera 7 */
         white-space: pre-wrap;       /* CSS3 - Text module (Candidate
Recommendation)
                                        
http://www.w3.org/TR/css3-text/#white-space */
         word-wrap: break-word;       /* IE 5.5+ */

}
</style>


Third:
I fully understand how product releases work, open source or not. The ideal
should be that a release date should be picked to light a fire under the
owners's proverbial seats. The comment that I have been getting when I tell
people that a bug fix will be in release 2.18, they ask when is that. It is not
a good reflection on the Bugzilla project to say, well, 2.16 was released 18
months after it was announced and 2.18 hasn't been announced yet.
> The ideal should be that a release date should be picked to light a fire 
> under the owners's proverbial seats.

I can see no ideal in that. I don't think you get quality software from
stressing the programmer. 

Sorry for the kind of off-topic comment, but I couldn't let that postulate stand
alone.
Regarding the release policy discussion, please take it to mozilla-webtools.  It
doesn't belong here.  My reply to comment 155 can be found there.
Comment on attachment 58498 [details] [diff] [review]
Patch v2

This isn't at all what I've described in comment 138.  This doesn't wrap at
all, apparently, except at explicit line breaks.  I want something that *does*
wrap at 80 characters, but on the server-side at display time rather than on
the client-side on submission.
Attachment #58498 - Flags: review?(myk)
If server-side wrapping at display time is too expensive for processing on the
server, then we might want to do a server-side cache (mentioned before by me,
just adding to my description of this idea) of the comments section of
often-used bugs. Template-toolkit should make this less complicated, or perhaps
there are perl modules better suited to the task. The advantage of caching only
the comments is that if state changes can occur to Summary, etc, then as long as
they add no new comments, we don't have to refreshed the cached data.

The most oft-viewed 2% (number changeable by admin) bugs could be stored in a
cache, with an array ranking them by number (or average #) of views. When a bug
falls off the end of the array, then the cache is deleted. That way, we won't
have cache hanging around of old active bugs that are now closed.

Rankings could be done by a weighted average of views by day in the last week,
and then added to a weighted average of views by week for the last n weeks. We'd
need to keep track of which bugs have had comments added in the last day,
because those are the only bugs that would be of interest for adding to the list
of 5% most active bugs. A column in the bug would have a 1 if its cached, and a
0 if its not. When a comment is submitted of a cached bug, the cache will need
to be updated. The assumption here is that an active bug is viewed much more
than a comment is sent (since users will probably check whether their own
comment appeared correctly after submission, this is probably a logical assumption).

Earlier, it was suggested that a cache would be too much work to fix this bug,
but the advantages of having such a cache would reach beyond just this bug. The
biggest issue with the cache would be it could get in the way of future
enhancements for more user-based  customization of comments appearance.
Wrapping text is not very expensive.  It's less expensive than processing a TT
template, which we do all the time :)
Server-side caching doesn't work because different people get different comment
text depending on e.g. the groups they are in, and the groups any mentioned bugs
are in. By the time you've cached various versions, and worked out which, if
any, you can use, you might as well re-render the thing for that person.

Gerv
*** Bug 234492 has been marked as a duplicate of this bug. ***
Severity: major → critical
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
a test
:)
Depends on: 21354
I am still getting this problem with Firefox 0.9 - it really annoys some people when reporting bugs that they have to scroll left to right in order to read them, and it annoys me to have to remember to put line breaks in.  This works for every other application of text-areas I have seen on the web, so why is it STILL broken in bugzilla?  This bug has been going for five years, and reading the comments already made it seems like one that isn't that complex to fix.
DunxD: Firefox supports wrap="hard", so I don't quite know why your copy is not
wrapping lines correctly... which OS are you using?

Gerv

(In reply to comment #164)

I add a similar problem a while ago. My anti-ads proxy, proxomitron, was
responsible (see comment #96)

Ok, I am going to test with Proxomitron off, and see what happens.  If this
works, we need to find out which specific filter in Proxomitron changes "hard"
to "soft".  Then we can still use Proxomitron and Bugzilla together.  Ok, sounds
good, I am going to submit this now.
Looks like Proxomitron is the culprit.  Everyone who uses Proxomitron, make sure
you have "Wordwrap all form textboxes" unchecked.  I am posting this with
Proxomitron ON but "Wordwrap all form textboxes" OFF.  Bugzilla SHOULD work now.
 Let's see.
WFM Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7) Gecko/20040614 Firefox/0.9.
*** Bug 137016 has been marked as a duplicate of this bug. ***
Flags: approval2.16+
Flags: approval2.16+
I think I'm missing something here. The "solution" seems simple: 

1) Get rid of the non-standard "wrap=hard"
2) Replace the <pre>...</pre> tags in the output with standards compliant HTML (style=, <tt>, etc.) that forces a monospaced font.
3) Convert hard returns in the data to <br>'s on the way out.

The only potential problem I see with this is realy odd browsers that would strip the hard returns out of the text box on submission.
Ray and/or Tosca: have you read every comment in this bug? 

For example, how does your solution preserve the wrapping of comments at 80
characters?

Gerv
>Ray and/or Tosca: have you read every comment in this bug? 

In particular, see comment 138.
Whiteboard: [content:comments] → READ COMMENT 138 BEFORE PROPOSING SOLUTION [content:comments]
(In reply to comment #171)

> 2) Replace the <pre>...</pre> tags in the output with standards compliant HTML
(style=, <tt>, etc.) that forces a monospaced font.

A monospaced font is not enough; sequences of whitespace should also be
preserved. <tt> forces a monospaced font, but collapses a sequence of spaces
into one.
An update on pre-wrap and similiar. This comment #150 method works on every
commonly used browser but konqueror (and I haven't tested Lynx):

pre {
 white-space: -moz-pre-wrap;  /* Mozilla, supported since 1999 */
 white-space: -pre-wrap;      /* Opera 4 - 6 */
 white-space: -o-pre-wrap;    /* Opera 7 */
 white-space: pre-wrap;       /* CSS3 - Text module (Candidate Recommendation)
                                 http://www.w3.org/TR/css3-text/#white-space */
 word-wrap: break-word;       /* IE 5.5+ */
}

http://bugs.kde.org/show_bug.cgi?id=26326

Why can't we wrap the text ourselves on incoming comments like comment #164? I
really don't see any reason people need to be able to enter more than 80
characters, unless its an URL or other long word. There is a rule of thumb with
online documents that you should not make them have more words than the page of
a book, because otherwise it makes them hard to read.

If they want to do something fancy, they could attach a text file...
We could also offer some bbs-like tags, like [nowrap] ... [/nowrap] and have a
checkbox (unchecked by default) that says: [] Interpret special commands
-----
Re: Comment #172:
>For example, how does your solution preserve the wrapping of comments at 80
>characters?

I don't think you'be be able to get exactly 80 characters via a pure HTML/CSS solution. Unfortunately, as far as I understand CSS2, you can only specify paragraph widths as absolute pixels, % of total width, or the same as the "inherited" width. The only way I see getting close to exactly 80 chars would be to have the paragraph widths be based on the width of the textarea, which you can specify width by characters. I feel that should be close enough. If it truly must be wrapped at 80 characters (See below), then the display routines should wrap the data on output. I'm not a Perl expert, but this is fairly trivial to do in the various C flavors, DataBASIC, etc.. Given your requirement: "Someone types a comment of multiple lines into a Bugzilla comment box and hits submit, and it turns into HTML which is in a monospace font and wrapped at 80 chars", the current implementationis only viable if somebody is using a browser that implements the non-standard "wrap=hard". First, it is a rather poor design choice to reply on things being done incorrectly and, second, I doubt the bugzilla group has the same clout that Microsoft has and forcing everybody to adopt a (currently/temporarily) common perversion of the standard isn't really going to work, especially since non-IE, non-Mozilla browsers are becoming more common.

Two other ideas that just came to me while typing is to dump each reply into a textarea with the disabled and column width properties set or to use frames and let people adjust the width of the comments independently of the . I don't know how browsers will vertically size the boxes based on the text and other folks despise frames, so these may be cures that are worse than the disease.
-----
Re: Comment # 174
>> 2) Replace the <pre>...</pre> tags in the output with standards compliant HTML
>> (style=, <tt>, etc.) that forces a monospaced font.
>
>A monospaced font is not enough; sequences of whitespace should also be
>preserved. <tt> forces a monospaced font, but collapses a sequence of spaces
>into one.

I had forgotten about that, but comment 36 addresses that by converting formatting spaces into non-breaking spaces.
-----
Re: Comment # 173
>In particular, see comment 138.

There's a lot that I agree with in there, but this whole topic exposes what I feel are the main problems with a lot of web development. I know that, to some people, this will come off as an outsider sticking their nose too far where it's not wanted, but that's not the intent.

The first is that folks want HTTP/HTML/CSS to replicate things that they are used to (not necessarily better, just what they're used to) with their old green screen/session-based/native GUI applications, or they expect HTTP/XHTML/CSS to behave like postscript/PDF/troff/a printing press/any other this is the way I want it displayed, damn the users' preferences, settings, screen size, etc. tool. There are short comings in HTML/CSS, and they should be worked around, but not at the expense of folks that actually follow the standards. Do we blindly insist on pushing and pulling a new saw across a log even though we have a chainsaw instead of a handsaw? Do we tell kids that have never seen an LP that they're going on like a broken record? Tools change, languages change, you have to adapt processes and work flows for the new tools and changes to the language.

I really feel that the "WWW" way of doing this is to let the text wrap to the window width and let people adjust their windows so the text is at the right width for them to skim  effectively. This is actually a better route than a strict 80 (or 78, or 72) characters, because some people need bigger fonts and then 80 chars would be too wide and others like tiny fonts, so 80 chars would be too narrow. Admittedly, this will take a reformatting of the info at the top of the page because too much of the info is too wide to fit in a skinny window without scroll bars.

That leads to second problem: Developers not following the standards and then blaming the end user because everything appears as the developer intended viewed in their particular version of one particular browser, on one particular OS pulled in over their LAN, so obviously there can't be a single error in their code. There are times that bleeding edge solutions are needed (and Bugzilla isn't one of them), and the right design choice is to require users to use products that are non-standards compliant, platform specific, etc. but very few projects require this. How much excess, fragile and bug-prone code exists simply to work-around bugs in other people's code that then never get fixed because everybody else has worked-around their mistakes? 

How many people grumble that Microsoft didn't follow the standard for: DHCP, CHAP, KERBEROS, etc. so everybody has to support the bug, or complain that Apple's SCSI connectors were non-standard (SCSI was oficially standardized years after Apple started shipping computers with on-board SCSI.), yet hypocritically blame the non-IE/non-Mozilla browsers for not replicating the long standing bugs/misimplementations/quirks/etc. that exist in their browser of choice? HTML 4 has been out for seven or eight years now hasn't it? Why is it the fault of the standards compliant developers and not the fault of the developers that aren't following the standards?
-----


Ray
-----
Re: Comment #172:
>For example, how does your solution preserve the wrapping of comments at 80
>characters?

I don't think you'be be able to get exactly 80 characters via a pure HTML/CSS solution. Unfortunately, as far as I understand CSS2, you can only specify paragraph widths as absolute pixels, % of total width, or the same as the "inherited" width. The only way I see getting close to exactly 80 chars would be to have the paragraph widths be based on the width of the textarea, which you can specify width by characters. I feel that should be close enough. If it truly must be wrapped at 80 characters (See below), then the display routines should wrap the data on output. I'm not a Perl expert, but this is fairly trivial to do in the various C flavors, DataBASIC, etc.. Given your requirement: "Someone types a comment of multiple lines into a Bugzilla comment box and hits submit, and it turns into HTML which is in a monospace font and wrapped at 80 chars", the current implementationis only viable if somebody is using a browser that implements the non-standard "wrap=hard". First, it is a rather poor design choice to reply on things being done incorrectly and, second, I doubt the bugzilla group has the same clout that Microsoft has and forcing everybody to adopt a (currently/temporarily) common perversion of the standard isn't really going to work, especially since non-IE, non-Mozilla browsers are becoming more common.

Two other ideas that just came to me while typing is to dump each reply into a textarea with the disabled and column width properties set or to use frames and let people adjust the width of the comments independently of the . I don't know how browsers will vertically size the boxes based on the text and other folks despise frames, so these may be cures that are worse than the disease.
-----
Re: Comment # 174
>> 2) Replace the <pre>...</pre> tags in the output with standards compliant HTML
>> (style=, <tt>, etc.) that forces a monospaced font.
>
>A monospaced font is not enough; sequences of whitespace should also be
>preserved. <tt> forces a monospaced font, but collapses a sequence of spaces
>into one.

I had forgotten about that, but comment 36 addresses that by converting formatting spaces into non-breaking spaces.
-----
Re: Comment # 173
>In particular, see comment 138.

There's a lot that I agree with in there, but this whole topic exposes what I feel are the main problems with a lot of web development. I know that, to some people, this will come off as an outsider sticking their nose too far where it's not wanted, but that's not the intent.

The first is that folks want HTTP/HTML/CSS to replicate things that they are used to (not necessarily better, just what they're used to) with their old green screen/session-based/native GUI applications, or they expect HTTP/XHTML/CSS to behave like postscript/PDF/troff/a printing press/any other this is the way I want it displayed, damn the users' preferences, settings, screen size, etc. tool. There are short comings in HTML/CSS, and they should be worked around, but not at the expense of folks that actually follow the standards. Do we blindly insist on pushing and pulling a new saw across a log even though we have a chainsaw instead of a handsaw? Do we tell kids that have never seen an LP that they're going on like a broken record? Tools change, languages change, you have to adapt processes and work flows for the new tools and changes to the language.

I really feel that the "WWW" way of doing this is to let the text wrap to the window width and let people adjust their windows so the text is at the right width for them to skim  effectively. This is actually a better route than a strict 80 (or 78, or 72) characters, because some people need bigger fonts and then 80 chars would be too wide and others like tiny fonts, so 80 chars would be too narrow. Admittedly, this will take a reformatting of the info at the top of the page because too much of the info is too wide to fit in a skinny window without scroll bars.

That leads to second problem: Developers not following the standards and then blaming the end user because everything appears as the developer intended viewed in their particular version of one particular browser, on one particular OS pulled in over their LAN, so obviously there can't be a single error in their code. There are times that bleeding edge solutions are needed (and Bugzilla isn't one of them), and the right design choice is to require users to use products that are non-standards compliant, platform specific, etc. but very few projects require this. How much excess, fragile and bug-prone code exists simply to work-around bugs in other people's code that then never get fixed because everybody else has worked-around their mistakes? 

How many people grumble that Microsoft didn't follow the standard for: DHCP, CHAP, KERBEROS, etc. so everybody has to support the bug, or complain that Apple's SCSI connectors were non-standard (SCSI was oficially standardized years after Apple started shipping computers with on-board SCSI.), yet hypocritically blame the non-IE/non-Mozilla browsers for not replicating the long standing bugs/misimplementations/quirks/etc. that exist in their browser of choice? HTML 4 has been out for seven or eight years now hasn't it? Why is it the fault of the standards compliant developers and not the fault of the developers that aren't following the standards?
-----


Ray
{Whoops. I got a connection failure error. Didn't realize the post actually went through. Sorry for the dupe.}

Hey, what about word wrap via CSS: <http://www.w3.org/TR/CSS21/text.html#white-space-prop>? It supports hard wraps and soft wraps independent of whitespace compression.

Ray
> you can only specify paragraph widths as absolute pixels, % of total width, or 
> the same as the "inherited" width

We can't use pixels because of different font sizes. We can use "em". em is
based on font width, isn't it? Look at http://www.thenetdragon.net/blog/ for an
example of the usage of "em". I wanted to limit the width of the lines to the
width of a normal book page (natural best line width) regardless of font size
and resolution. From its source: 

div#centerBox {
    max-width: 45em !important; 
...



Please read comment #138, btw

white-space has been discussed. We could use the white-space attribute, but not
all browsers support it. Therefore we'd be in the same boat.

<offtopic>A joint Bugzilla account. Interesting. Good idea, though.</offtopic>
You'll find if 80 chars wide is what you are after, 

div#centerBox {
    max-width: 80ex !important; 
...

will get you really close, regardless of user settings.
The CSS3 text module should offer up something for this. I don't know if
wrap-option has all of what we need... http://www.w3.org/TR/css3-text/#wrap-option
Bug 99457.
It looks like the CSS properties are only presentational. Hixie's new Web Forms
2.0 working draft includes wrap=hard:
http://www.whatwg.org/specs/web-forms/current-work/#extensions3

Still, this bug will not go away until all commonly used browsers use Web Forms
2.0, which may take years.
All commonly used browsers support wrap=hard as per Web Forms 2.0.
Too bad that wrap=hard breaks URLs in the middle.

Life is tough. :-)

Indeed, it seems that if we wait a bit, this bug may go away. 

Perhaps the Bugzilla project developers need to have a discussion about what
weight they should give to WHATWG standards, at what stages of WHATWG's process
as outlined here: http://www.whatwg.org/charter .

Gerv
Blocks: 47251
Attached patch our server's solution (obsolete) — — Splinter Review 
some food for thought
some food for thought too
No longer blocks: 47251
*** Bug 167802 has been marked as a duplicate of this bug. ***
Attachment #163369 - Flags: review?
Comment on attachment 163369 [details] [diff] [review]
our server's solution

Unfortunately, this seems to require the user to know whether or not they want
to wrap, which isn't something I can reasonably expect the average Bugzilla
user to know.

All we really need is a simple way to do server-side, display-time wrapping
without breaking URLs.

I think that really, it could just be achieved in this way:

(1) Wrap the raw text to the user's/admin's preference.
(2) When we "linkify" the text, the "linkification" subroutine can unbreak
URLs.

Pretty simple, really.

We don't have to worry about "unwrapping" old comments, even. If we *want* to
worry about that later, in another bug, there's various algorithms around in
various editors that can do it, that we can look at.

It doesn't need to happen in the CSS; that's not the most important. It's just
important that it happen on the server-side, and the wrapping isn't hard-coded
into the DB.

That's the actual *feature* that most users *need*. It would be cool to do it
in CSS (I like CSS), but we don't need to do it.

We could even have a checkbox that says, "Don't automatically wrap my text"
when you enter a comment, and it would be set to "true" for all of the
currently existing comments, to preserve their wrap.
Attachment #163369 - Flags: review? → review-
In fact, I'm going to implement it.
Assignee: justdave → mkanat
Status: ASSIGNED → NEW
OK! Here ya go. This requires the patch on bug 279700 (which just needs to be
checked-in to CVS, at this point, by the way).
Attachment #58498 - Attachment is obsolete: true
Attachment #84226 - Attachment is obsolete: true
Attachment #163369 - Attachment is obsolete: true
Attachment #172857 - Flags: review?
Comment on attachment 172857 [details] [diff] [review]
Wrapping at display-time, perserve old wrapping, v1 (use -p1)

So basically this patch:

-> uses Text::Wrap to do the wrapping. We already use it, the patch simply
moves it from one place to another. Either we already have checksetup.pl
checking for its dependency, or it's a standard module.
-> keeps the wrapping at 80. That's ok. While others suggested to put it at 72
or something like that in order to allow quoting by email clients, I think that
should be another bug.
-> stores the attachments unwrapped in the database. That's a really neat thing
to do. In the future, this will allow us to offer, user-based, a setting
regarding the number of columns in the viewer. (if we decide it's a good thing,
of course, but the possibility exists! :) )
-> modifies the DB schema, in order to store on an additional column if the
comments were wrapped or not already. Sensible thing to do.
-> Eliminates the wrapping done in attachment.cgi-only during post time, in
order to keep the comments unwrapped in the DB.
-> implements the wrapping thing at display-time twice, once in
globals.pl::GetDescriptionAsText sub, used for emailing content, and the other
time in Template Toolkit, using an additional wrapping filter.
-> Removes the "hard" attribute from the textarea's HTML form.

Nit:

     return ($removed, $added);
 }

+sub wrap_comment ($) {
+  my ($comment) = @_;
+
+  # Use 'local', as recommended by Text::Wrap's perldoc.
+  local $Text::Wrap::columns = COMMENT_COLS;
+  # Make words that are longer than COMMENT_COLS not wrap.
+  local $Text::Wrap::huge = 'overflow';
+  # Don't mess with tabs.
+  local $Text::Wrap::unexpand = 0;
+
+  return wrap('','', $comment);
+}
+
 sub format_time {
     my ($time) = @_;

This should be 4-space idented, especially since the subs before and after it
are 4-space idented as well.

Can be fixed upon checkin.
Attachment #172857 - Flags: review? → review+
Comment on attachment 172857 [details] [diff] [review]
Wrapping at display-time, perserve old wrapping, v1 (use -p1)

I'm not quite happy with the storing in the database whether it was wrapped or
not and blindly setting that on all of the existing comments during the
upgrade.  This means all of the comments that were previously screwed up
(submitted from a browser that didn't support wrap=hard) are going to stay
screwed up.  I'd rather have the old ones fixed, since display-time wrapping
lets us do that.  That's half of the benefit of doing it that way.  This was
also one of Myk's requirements in comment 138, and I agree with him there.
Attachment #172857 - Flags: review-
Actually, no_wrap is to support having comments in the future that aren't
wrapped, by user choice.

I agree that it would be good to locate all the old unwrapped comments, but the
algorithm to do that is pretty complex.

We could provide a tool, in a bug separate from this one.
OK, the only way I'm going to buy that plan is if we get rid of the <pre> and
change every other space to &nbsp; and other magic to preserve spacing, so that
the stuff will at maximum wrap at the page width, no matter what.

It would be great if Max could talk us through the issues raised in comment 138
and tell us how his patch addresses them.

> This means all of the comments that were previously screwed up are going to 
> stay screwed up. 

That's true - however, things have not got _worse_. Requiring the initial patch
to make this thing better as well as making other things better does seem to be
an example of the complaint on the mailing list - letting the best be the enemy
of the good. 

Having said that, I think the algorithm to detect improperly-wrapped existing
comments is actually fairly simple (although it might take a while to run). You
just look for every comment for which the first eighty characters does not
contain a \n. That will get the majority of them; a more complex algorithm to
look for _any_ such run of letters > 80 would get all, I think.

> the stuff will at maximum wrap at the page width, no matter what.

One of the things I thought we'd established in the discussion (comment 115,
comment 138) is that, for readability reasons, text by default should wrap at
around the current width, and not at the page width?

Gerv

As far as detecting code and other sections that should not be wrapped, you can
use indentation. If a line of text begins with spaces, don't wrap it.

Either way, existing indented lines probably shouldn't be wrapped to anything
less than 80 chars. A lot of my comments would get horked if the code did that;
I often use indentation to format bug reports and long comments.

Per Gerv's suggestion, I'm running through this comment and explaining how my
patch addresses the issues.

Also, I could add another feature to the patch that allowed somebody to somehow
set no_wrap = 0 on a comment, thus fixing a broken wrap on certain comments. I
could also provide a tool to locate comments that need such a thing, but the
determination would probably have to be up to the admin.

Wrapping all comments that don't end at 80 chars would break long URLs and
certain attachment comments.

(In reply to comment #138)
> It *is* broken.  Some comments (from browsers that don't support wrap="hard") 
> are unwrapped, while others (like lines of code or quoted sections) are 
> wrapped that shouldn't be.

  OK, obviously, we fix this, since we no longer depend on the browser. All new
comments will be properly wrapped.

>  Also, the current system is inflexible, since it 
> doesn't provide any way to change our wrapping policy in the future or 
> accommodate  non-traditional devices/clients (small screens, third-party 
> clients, etc.).

  The patch also easily allows this, since you can change COMMENT_COLS. It also
centralizes all wrapping into one sub, so we can make COMMENT_COLS a parameter
or something else, at some point.

> We want to fix as much broken stuff as possible,

  The patch fixes broken stuff for the future, but not for the past.

> regress working stuff as little  as possible,

  Thanks to the checksetup code in the patch, we don't change the way any
current comments are displayed, so nothing should regress.

> make it possible to change Bugzilla's wrapping policy in 
> the future (f.e. letting the user agent wrap or wrapping to a different 
> width), and support non-traditional devices/clients.

  And this one's the same as I stated above.

> We should choose 
> standards-compliant solutions where possible because of their overall 
> benefits, but standards-compliance is a secondary goal; our first priority is 
> making Bugzilla as usable as possible.

  Thankfully, the patch doesn't depend on the browser at all. Standards aren't
even an issue. And it removes wrap="hard" from the textareas, which helps with
some standards.

> > Must this bug be fixed?
> 
> No.  We can resolve it WONTFIX if we decide that there is no good solution to 
> the problem.  We can resolve it INVALID if we determine that wrapping is the 
> user agent's and user's responsibility.

  I don't think we've decided that. :-)

> > What if I think he's wrong?
> 
> Tough, or as the Brits say, hard cheese.  Leaving the bug open and continuing 
> to  argue about it and consider it when thinking about other bugs is not 
> better than making a decision--even one that some people disagree with--and 
> then moving on to other issues.  Whatever we choose here (including not fixing 
> the bug at all) will not be the end of the world; it'll still work fine most 
> of the time for most people.

  I'd also like to accentuate this point. :-)

> > What about a preference to control wrapping behavior?
> 
> Most people don't bother with prefs, nor should they have to.  We have a 
> responsibility to make informed decisions for our users, and we shouldn't 
> abdicate that responsibility just because a decision is hard to make.

  That's fine -- this patch gives the users no preference.

> > What about some UI to control wrapping behavior?
> 
> UI costs time and energy for users who have to fiddle with it.  We should 
> provide the minimal UI necessary to allow users to do their work and hide 
> functions that will rarely be used.

  OK. The patch provides no UI, since it's not necessary.

> > What about a tag to control wrapping behavior?

  N/A.

> > How wide should textual content be generally?
> 
> Not too wide, according to usability studies (see comment 115), which is why 
> the current behavior to wrap at 80 characters is a pretty good one.

  Cool. Patch uses 80 characters.

> > So what's your proposed solution?
> 
> Server-side rewrapping to 80 characters at display time (or cached for 
> performance), possibly using the Text::Autoformat module or other Perl modules 
> available to us (otherwise rolling our own), for the following reasons:
> 
> 1. it displays text almost exactly the same as the current system, so it is 
> minimally disturbing to existing users;
> 2. it fixes the problem of browsers that don't support wrap="hard";
> 3. it makes it possible for us to change our wrapping policy in the future and 
> to provide content to non-traditional devices and clients.

  Well, that's what I did.

> > What about paragraphs which are currently hard-wrapped to more than 80 
> characters?
> 
> If possible, they should be rewrapped to 80 characters.  Otherwise they should 
> be left as-is.

  That's what I did (leave them as-is).

> > What about diffs and code?
> 
> They should be detected and not rewrapped.

  The patch doesn't do this. I'm not aware of any code path that would actually
allow me to determine that a comment is a diff or code, at display-time.

> > What about quotes?
> 
> They should be be stripped of quote markers, rewrapped, and then have quote 
> markers added back to them.

  I considered this -- I considered wrapping the attachment before it is
displayed in the "Edit as Comment" box. But that would actually change the
current behavior, so I figured that's another bug.

> > What about diagrams?
> 
> They should be detected and not rewrapped, and we should encourage users to 
> make diagrams available as attachments rather than comments.

  That's also ideal, but can be dealt with in another bug, if we want.

  We can also provide a "do not auto-wrap this text" check-box, if we want,
thanks to the no_wrap column.

> > What about all sorts of other wierd situations?
> 
> We use wrap="hard" almost all of the time, and users almost never override 
> that intentionally.  We can implement something server-side which is at least 
> as smart as wrap="hard" and probably much smarter, accounting for most 
> situations in which users want typical 80-character wrapping overridden.

  Yep. In fact, Text::Wrap, with the parameters I've set, is much smarter than
some browsers when it comes to wrapping, and it's at least as smart as Mozilla.

> > What if it's not perfect?
> 
> It's not perfect now, and it never will be.  That doesn't mean we shouldn't 
> improve the situation.

  Yep. It's not perfect.

> > What about letting installations decide wrapping behavior?
> 
> This can happen in a separate bug once we implement a solution that makes it 
> possible.  Let's keep this bug focused.

  And in fact, it would be easy for an admin to change COMMENT_COLS.

> > What if it's hard?
> 
> Then we should implement any solutions that mitigate part of the problem (like 
> Gerv's idea to special-case known bad browsers) until someone has the time to 
> implement this.

  OK. Well, I've mitigated the problem for the entire future of all Bugzilla, by
not pre-wrapping comments in the DB for the future.

  OK, that's that.
Status: NEW → ASSIGNED
(In reply to comment #197)
> As far as detecting code and other sections that should not be wrapped, you can
> use indentation. If a line of text begins with spaces, don't wrap it.

But now that wrap="hard" is removed, I don't think we can detect server-side
exactly how the comment was formatted in the text box client-side.

> Either way, existing indented lines probably shouldn't be wrapped to anything
> less than 80 chars. A lot of my comments would get horked if the code did 
> that;
> I often use indentation to format bug reports and long comments.

I think the idea is to leave existing comments alone, or perhaps to rewrap only
those submitted by browsers which didn't support "wrap=hard" - i.e. those with
long runs of characters without a \n.

Gerv

(In reply to comment #199)
> I think the idea is to leave existing comments alone, or perhaps to rewrap only
> those submitted by browsers which didn't support "wrap=hard" - i.e. those with
> long runs of characters without a \n.
> 
err.. long runs that are not URLs

> Wrapping all comments that don't end at 80 chars would break long URLs and
> certain attachment comments.

Not if the 80 chars contained at least one space.

My point is that, without too much difficulty, we can come up with a heuristic
which marks-for-wrapping most of the current broken comments, while not breaking
any working ones. But I assert that this is not _necessary_, either now or ever,
and that it's definitely a separate bug.

> We can also provide a "do not auto-wrap this text" check-box, if we want,
> thanks to the no_wrap column.

You can't both answer the "there should be no wrapping UI" point with "well, OK,
there is no wrapping UI", and also answer the "what about problem comment type
X?" question with "we can add wrapping UI" ;-)

Another point to note is that (as outlined in comment 140) this patch will break
Bugzilla in Netscape 4, because Netscape 4 requires "wrap=soft" in order to get
soft-wrapping. I personally don't care, and think it's about time we made a
group decision to dump NS4, but it should be noted.

With regard to the code itself, this may seem like a nit, but would it be better
to have a "wrapped" rather than a "no_wrap" column? I've always understood that
it's good practice to have boolean fields consistently in the positive sense.
This turns the field from a "display format" identifier to something which
contains metadata about the comment itself - i.e. "this is already wrapped",
rather than "don't wrap this when you display it, please".

Either way, does it also make sense in checksetup.pl to set the field default to
the no_wrap value, rather than set it to the wrap value and then set all
instances to the no_wrap value with another line of SQL?

Gerv
At its core, this bug is attempting to resolve three main conflicting
requirements, which have been articulated at various points in its history.

1) People need to be able to add text to comments which is not just a succession
of paragraphs.
2) There should be no UI for wrapping behaviour - users shouldn't have to bother
with it
3) It should be possible to produce versions of comments wrapped in different
ways, e.g. for new devices.

Up to this point, Bugzilla deals with it by ignoring requirement 3. This patch
changes things to respect requirement 3, but ignore requirement 1 (there's no
way to request that your text not be wrapped). 

If this bug is ever to be fixed, one of these requirements has to go. 

Ditch requirement 1 -> Max's patch
Ditch requirement 2 -> Max's patch with checkbox UI for wrapping control
Ditch requirement 3 -> WONTFIX

Having re-familiarised myself with all the issues here, I now think that 3
is the least important, and so we should WONTFIX this bug (at least in its more
general form). I'd also accept the compromise of ditching requirement 2. But
regardless of my opinion, would it add clarity if we discussed what to do in
terms of the three requirements above, rather than patch behaviours? Or has this
summary not captured the essence of the issue?

Gerv
'My point is that, without too much difficulty, we can come up with a heuristic
which marks-for-wrapping most of the current broken comments, while not breaking
any working ones.'

With all due respect, the fact you believe someone can come up with a reliable
heuristic doesn't mean that such a heuristic actually exists. I suspect it would
actually be pretty hard.

'You can't both answer the "there should be no wrapping UI" point with "well,
OK, there is no wrapping UI", and also answer the "what about problem comment
type X?" question with "we can add wrapping UI"'

True. And that means there needs to be a solution to getting the right setting
for "problem comment X" which doesn't involve UI - that seems to be a similar
problem to the problem of what to do with previous comments, which means finding
a reliable heuristic should indeed be part of this bug.

If adding UI isn't acceptable, and there isn't a reliable heuristic, then we're
back at 
"We can resolve it WONTFIX if we decide that there is no good solution to 
the problem."

[edit: I just mid-aired with Gerv's comment, but I think this pretty much agrees
with what he wrote]
The essence of the issue is that Bugzilla should have never stored comments
pre-wrapped, and should have always wrapped them at display-time.

We are now trying to fix that.

It would indeed be nice if we could go back in time and fix this mistake, or
write code that will do that for us, by altering the old comments.

I think if it's reasonably possible, I'll do it. In fact, I could probably do it
in checksetup with Gerv's algorithm below.

(In reply to comment #201)
> > Wrapping all comments that don't end at 80 chars would break long URLs and
> > certain attachment comments.
> 
> Not if the 80 chars contained at least one space.

  Oh, good point.

  Although I could also add code to checksetup to test that, it wouldn't catch
certain attachment comments that I don't think were wrapped. (Maybe they're
older comments, I'm not sure.)

  Aren't there some attachment comments that overflowed 80 characters with the
quoting? Or am I imagining things?

> You can't both answer the "there should be no wrapping UI" point with "well, 
> OK, there is no wrapping UI", and also answer the "what about problem comment 
> type X?" question with "we can add wrapping UI" ;-)

  Yes. At this point, there is no wrapping UI. We *could* add wrapping UI, but
that would be a different bug.

  Good point, though. I prefer a tool or checksetup code to the UI solution that
I proposed. Still, I don't think it's possible to fix our mistake of textarea
wrapping with a reasonable solution that will work for 2/3rds of installs or more.

  I also don't think that the old comments are such a significant problem that
this architectural mistake should not be fixed. In time, old comments will
disappear as bugs close.

> Another point to note is that (as outlined in comment 140) this patch will 
> break Bugzilla in Netscape 4, because Netscape 4 requires "wrap=soft" in order 
> to get soft-wrapping. I personally don't care, and think it's about time we 
> made a group decision to dump NS4, but it should be noted.

  Well, it won't entirely break NS4, right? It'll just make the textareas weird,
as I understand.

> With regard to the code itself, this may seem like a nit, but would it be 
> better to have a "wrapped" rather than a "no_wrap" column? I've always 
> understood that it's good practice to have boolean fields consistently in the 
> positive sense.

  Yeah. We could have a wrap_me column. I think you're right about booleans
being true.

> This turns the field from a "display format" identifier to something which
> contains metadata about the comment itself - i.e. "this is already wrapped",
> rather than "don't wrap this when you display it, please".

  Oh, I see what you mean... So it could be "wrapped" or "pre_wrapped." (I'd
guess "wrapped" is simpler if less clear -- do you agree?)

> Either way, does it also make sense in checksetup.pl to set the field default 
> to the no_wrap value, rather than set it to the wrap value and then set all
> instances to the no_wrap value with another line of SQL?

  The field default is for the future. The other line of SQL is for the past. It
gives me less code change to do, and it's also what really is the "default" from
there on out.
OK, I figured out how to do it in SQL in checksetup. It runs LIGHTHING fast on
landfill, too. I wonder how it would do on b.m.o.

This should catch most of the mis-wrapped comments.
Attachment #172857 - Attachment is obsolete: true
Attachment #172900 - Flags: review?(justdave)
Comment on attachment 172900 [details] [diff] [review]
Fix mis-wrapped comments, also (Patch v2) (use -p1)

And vladd, too (to do some basic "yeah, that looks good" review), if justdave
doesn't get to it, first.
Attachment #172900 - Flags: review?(vladd)
Oh, and there's a test installation at:

http://landfill.bugzilla.org/bz11901v2/

Not sure if I mentioned that already.
URL: http://landfill.bugzilla.org/bz11901/ → http://landfill.bugzilla.org/bz11901v2/
Keywords: relnote
Oh, and I know that you're going to ask (:-D ): Yes, that SUBSTRING syntax, and
that POSITION syntax are the same in MySQL and PostgreSQL, and they work on the
MySQL 3.23 installation on landfill.
Attachment #172900 - Flags: review?(vladd)
(In reply to comment #204)
> The essence of the issue is that Bugzilla should have never stored comments
> pre-wrapped, and should have always wrapped them at display-time.

Or, to put it in comment #202 terms, "Bugzilla should always have ignored
requirement 1 and respected requirement 3." I don't think that's necessarily
true - requirement 1 is pretty important IMO. A few current use cases for
requirement 1:

- The Bugzilla Helper (format=guided)
- Reviews of patches
- ASCII art
- Any other sort of laid-out or formatted text

[I apologise if my comment confused two issues - that of fixing the old
comments, and the one above about conflicting requirements. This issue
(conflicting requirements) is not a question of fixing the past, it's an issue
of what we should be doing in the future.]

Max: how important do you feel requirement 1 is?

Gerv

I've just realised that I'm working under an assumption which may not be true.

Is it true that Text::Wrap removes all existing single \n characters from the
text before rewrapping it?

As I understand it, by default (without a wrap attribute) modern browsers will
send exactly what's in the text box - i.e. any explicit \n characters will get
sent. And we'll store them in the database.

Therefore, is Text::Wrap (or some replacement for it that we wrote) preserved
all existing \n characters on new comments, as well as potentially adding new
ones at whatever the wrap width was, most of the existing use cases for
pre-wrapped text would continue to work.

Is Text::Autoformat (which, having just read the documentation, seems very cool,
and has a TT interface) the solution to this issue or any others?

Gerv

(In reply to comment #211)
> Is it true that Text::Wrap removes all existing single \n characters from the
> text before rewrapping it?

I don't think so.  It seems to preserve what you put in when adding comments
from the edit attachment page, and we're using the same code there.

Text::Wrap::fill() is a separate call to eliminate single \n characters, and I
don't believe we're using it here.
(In reply to comment #208)
> You can see that the patch fails only to fix comments that *did* wrap, but
> wrapped beyond 80 characters. It gives them a little "extra" wrap, which I
> think is OK.
> 
> Extra-wrapped:
> http://landfill.bugzilla.org/bz11901v2/show_bug.cgi?id=213#c0
> http://landfill.bugzilla.org/bz11901v2/show_bug.cgi?id=411#c0

Yeah, those aren't so bad...  they're readable without having to horizontally
scroll at least. :)   Maybe we should use 90 characters instead of 80 when
fixing up the old comments?  That'd allow for that fudge factor for the browsers
that did wrap and did it a little wide, and it should still fit on most people's
browser windows.  That's just a nit though, I'm not real concerned on it.
Comment on attachment 172900 [details] [diff] [review]
Fix mis-wrapped comments, also (Patch v2) (use -p1)

Based on the interdiff with the previous patch and the successful demo on
landfill I like this one.
Attachment #172900 - Flags: review?(justdave) → review+
Flags: approval+
(In reply to comment #210)
> Max: how important do you feel requirement 1 is?

  Well, I think that if people want to write a comment that isn't just a
succession of paragraphs, they can use an attachment. :-)

  I think it would be nice to be able to paste wide diagrams or MySQL output
into a comment, but really we should encourage people in the documentation to
use attachments if they have wide text (since they're probably trying to enter
data, which is what attachments are pretty much for).
There is an easy solution to preserving requirement 1.

Default to the assumption that the comment is just a series of paragraphs BUT
provide a mechanism to let the author of a comment signal that the comment is
preformatted. This mechanism could be 
a) A checkbox
b) First line of comment is <pre> or .pre or something similar
etc..

(In reply to comment #193)
> This means all of the comments that were previously screwed up (submitted from a browser that didn't support wrap=hard) are going to stay screwed up.

Just want to avoid confusion down the road. Somebody's going to read that and restart the, "Well they didn't use a standards compliant browser, so don't worry about them." sub-thread. The problem isn't that HTML standards compliant browsers didn't support the Netscape extension "wrap=hard", the problem is that the initial development relied on a browser-dependant feature and didn't handle wrapping server-side.
(In reply to comment #198)
> > > What about a preference to control wrapping behavior?
> > 
> > Most people don't bother with prefs, nor should they have to.  We have a 
> > responsibility to make informed decisions for our users, and we shouldn't 
> > abdicate that responsibility just because a decision is hard to make.
> 
> That's fine -- this patch gives the users no preference.

Anyone got any real issues with CREATING a user preference to control this 
(i.e. a new bug dependent on bug 98123), since it seems like the code exists to 
make it happen?


Also, for the record, I am also very much in favour of creating a UI element 
that would allow people to say, "Please put a line break *only* where I 
explicitly enter one" so that code with very long lines due to massive 
indentation (as just one example) could be left intact on the screen rather 
than wrapped and made unintelligible. That would definitely be a new bug, 
however; for the moment, though, this seems like a very good first step.


> Anyone got any real issues with CREATING a user preference to control this 

Yes. Whether a comment should be wrapped or not isn't a per-user issue so much
as it is a per-comment issue, or per-section-of-comment issue. I don't think it
should be a pref. ESPECIALLY if you set wrap="soft"; there's no practical way to
tell whether one has wrapped a particular line or not in that case, so you'll
wind up with worse wrapping problems when "I don't want comment wrapping" people
try to hand-wrap their text.

> > As far as detecting code and other sections that should not be wrapped, you
> > can use indentation. If a line of text begins with spaces, don't wrap it.
> But now that wrap="hard" is removed, I don't think we can detect server-side
> exactly how the comment was formatted in the text box client-side.

You can detect the sequence [newline][space], which is what I'm asking for.
Lines of code and indented list items and suchlike will start with hard breaks.
If you're indenting text, you don't do it by inserting spaces in a soft wrap,
you put in a hard break first. So knowing the client's soft breaks isn't an issue.
(In reply to comment #219)
> > Anyone got any real issues with CREATING a user preference to control this 
> Yes. Whether a comment should be wrapped or not isn't a per-user issue
> so much as it is a per-comment issue, or per-section-of-comment issue.
> I don't think it should be a pref.

You nearly completly misunderstood my suggestion/question, possibly because I 
wasn't as clear as I should have been.

The user pref I mentioned would control the value of COMMENT_COLS, allowing 
individul users to control the point at which they want their screens to wrap. 
People with big print could wrap sooner; people with big screens and good eyes 
could wrap later... or the Admin could override them all and not allow users to 
change their preference whatsoever. (Please read bug 98123 for discussion of 
how User Prefs are being implemented.)

My entire second paragraph was about comments whose value is lessened should 
they be wrapped incorrectly, and the need for a *per-comment override* to 
ensure that the commenter's preferences take precedence over the viewer's. (If 
this happens at all, it would be as another bug, not part of this one.)

Max said:
> Well, I think that if people want to write a comment that isn't just a
> succession of paragraphs, they can use an attachment. :-)

So all reviews of patches, for example, should be attachments? As I listed,
there are several common use cases where comments are not just a succession of
paragraphs, and we need to take them into account. 

Joel said:
> Default to the assumption that the comment is just a series of paragraphs BUT
> provide a mechanism to let the author of a comment signal that the comment is
> preformatted.

See comment #138, answers 8, 9 and 10.

Shane said:
> Anyone got any real issues with CREATING a user preference to control this 
> (i.e. a new bug dependent on bug 98123), since it seems like the code exists 
> to make it happen?

Yes - it allows users to make Bugzilla less usable for themselves without
realising that they've done so. See comment 115.

fantasai said:
> You can detect the sequence [newline][space], which is what I'm asking for.

We should investigate using Text::Autoformat instead of Text::Wrap (before we
check this in). From reading its docs, it has this capability, plus a number of
others that would be useful. And there's also a TT2 plugin for it.

Gerv

I don't see why we couldn't investigate Text::Autoformat *after* we check this in.
Can someone remind me again why we are actually changing the status quo?

The standards-compliance argument was always secondary, and WHATWG may make it
go away anyway. The only ability we would gain would be the ability to provide
comments wrapped at an arbitrary width. Has anyone got a use for that? We can
wave our hands and mumble "small devices", but these days, anything PDA-like can
display 40 column or 80 column text with no problems. And who works with a bug
system via a PDA anyway? Even PDA software developers use emulators on their
desktops.

Given that 80 columns is in the range of most usable widths (see comment 115),
IMO we actively want to prevent users messing with the column width, either when
they write the comment or when they display it. They'll just make Bugzilla less
usable for themselves, perhaps without noticing it. Giving users that option
should not be a priority, and we should certainly not be doing it at the cost of
removing useful features like the ability to just write preformatted text
without hassle, or making each user consider another piece of UI for comment
wrapping control.

We could certainly do something about the broken comments in the database, and
in the future we can special-case the browsers which don't support "wrap=hard",
but that doesn't require changing the way we submit comments now.

Gerv
Right. Any discussion about any UI should not happen in this bug, bug should
happen in some other bug. This bug is effectively closed for any further
additions at this point.
Max: if comment 224 was a reply to comment 223, then you haven't read what I'm
saying :-) My point is that currently, this patch regresses useful functionality
without adding anything that anyone has found a use case for.

So we shouldn't be committing it, unless we can either avoid regressing the
useful functionality, or come up with a compelling use case for the new abilities.

Gerv

(In reply to comment #225)
> My point is that currently, this patch regresses useful functionality
> without adding anything that anyone has found a use case for.

What exactly is it that we're regressing that's so important to you?  Reading
over your last few comments, I can't tell, so please enlighten us.
(In reply to comment #225)
> Max: if comment 224 was a reply to comment 223, then you haven't read what I'm
> saying :-) My point is that currently, this patch regresses useful functionality
> [snip]

  No, it doesn't regress useful functionality. Read the patch. Notice that all
comments were previously wrapped before inserting them into the database, and
now they are wrapped only when displayed. This is and was the case for both
normal comments and attachment comments.
Shane pointed out to me that some people might misunderstand the patch:

Text::Wrap doesn't touch any newlines that already exist in the text. If I type:

this
is some
text

In a comment, it will come out exactly that way.

If I type some really long line, it will be wrapped, as long as it has a space
in it.

Actually, the wrapping behavior of this patch is much nicer than the current
wrapping behavior, overall, because it works on all browsers and it *never*
breaks long [valid] URLs.
OK, I've been doing some testing of the use cases I was worried would break. The
good news is that some of them don't, at least not significantly :-) So I'm
feeling a bit happier.

However, two do. 

1) quoting text which happens to be already close to the full width:
http://landfill.bugzilla.org/bz11901v2/show_bug.cgi?id=2370#c7

The ideal solution would be for new text to wrap at (say) 74 chars, and for two
chars to be added to the wrapping width for every level of quoting of the
current paragraph. Alternatively, you wrap at 74 chars only if there's no \n in
the next six characters. But I'm not sure we can implement either of those, at
least not without writing our own wrapping module.

I do think we should take a moment to see if we can solve this before checkin.
The reason I say that is because once we have the current implementation, we are
going to start getting comments which involve two levels of quoting which have
unnecessary and ugly newlines in them. (I can explain what I mean here further
if it's not clear.)

2) Patch reviews.
http://landfill.bugzilla.org/bz11901v2/show_bug.cgi?id=2370#c10

Reading that review is much harder, because many of the quoted lines are now
wrapped. We can't say "well, don't write such long lines of code, then" - the
fact is, people do, and at the moment we cope well with it.

This could perhaps by fixed by comments from the patch review box automatically
being set to not be wrapped on display, but then the interspersed text wouldn't
wrap, when currently it does. (Not sure how that works...)

Any ideas?

Gerv
issue 1 in comment 229 is a red herring (see)
http://landfill.bugzilla.org/bz11901v2/show_bug.cgi?id=2370#c7
The defect is not in the wrapping code presented here but rather in the quoting
code--it makes no assumption about width and just inserts > before any line. Fix
that and you've fixed the wrapping problem.
issue 2 in comment 229 is a low-probablity problem again related to the quoting
mechanism. The quoting not the wrapping code needs to be fixed.
(In reply to comment #229)

Yeah, I did think about those two cases when writing the patch.

The interesting thing about the patch now is that we can modify the wrapping
behavior at any time that we want, now, after this patch is checked-in.

So after we check in this patch, we can deal with it in one of a few ways that I
can think of off the top of my head:

(1) Modify the quoting code to wrap things to 80 characters.
(2) Modify the wrapping code to "unwrap" quoted lines.
(3) Modify the attachment editing stuff to wrap things before you edit them.

In general, I think the best thing to do would be #1, but the others are
possible, too.


The "quoting a 77-character comment" thing happens now, anyhow.
OK, fair enough about issue #1. It's not any worse with the patch than it is now.

But, as for issue #2, I don't agree that it's a low-priority or rare problem.
Lines longer than 78 characters are pretty common in Mozilla code, for example -
in .xul and .js files, such as the ones I used for my demo.

Max's suggestion 2) would work, and perhaps solve other quoting issues too, but
is it possible to control the behaviour of Text::Wrap in this way? Suggestion 3)
doesn't solve the problem - the way to preserve readability is not to wrap the
quoted lines. Wrapping them earlier or later in the process doesn't improve matters.

Yes, we could attempt to fix it up after checkin, but that assumes that a fix
exists. And all reviews done between the initial checkin and the fix would have
this problem of being harder to read.

Gerv

Max: would you be able to take 5 minutes to install Text::Autoformat and use the
following magic recipe in place of your call to Text::Wrap?

autoformat($text, { all        => 1,
                    right      => 80, # or COMMENT_COLS
                    fill       => 0,
                    squeeze    => 0, 
                    ignore     => qr/^> /, 
                    renumber   => false,
                    widow      => 0,
                    autocentre => false });

Having read the manual carefully, I think this may do what we want - including
leaving quoted paragraphs unwrapped.

Gerv

OK, so that's a regression. You can see:

http://landfill.bugzilla.org/bugzilla-tip/show_bug.cgi?id=2323#c2

Which is how Bugzilla behaves now, which is nicer.

I'll think about this a bit.

And yeah, I'll look at that Text::Autoformat solution.
ok, clearing approval for now...  Max's experiments on landfill seem to be going
pretty good, so I'm sure he'll be spinning a new patch. :)  Text::Autoformat
looks cool so far.
Flags: approval+
Attached patch Version 3 (use Text::Autoformat) (obsolete) — — Splinter Review 
OK, yeah. This version is better. :-) I like Text::Autoformat. Thanks for the
suggestion, Gerv.

The new version does not wrap lines that start with ">". In every other way, it
*should* be the same.
Attachment #172900 - Attachment is obsolete: true
Attachment #173135 - Flags: review?(justdave)
Oh, and the test installation is still valid; it's running the latest version of
this patch.
Comment on attachment 173135 [details] [diff] [review]
Version 3 (use Text::Autoformat)

Actually, this patch is bad. Hold for a new one.
Attachment #173135 - Attachment is obsolete: true
Attachment #173135 - Flags: review?(justdave)
Attached patch Version 3.1 (obsolete) — — Splinter Review 
I also noticed that I had to fix the Linkify page.

OK, this patch works, as tested on the same landfill installation in the URL
field.
Attachment #173137 - Flags: review?(justdave)
Comment on attachment 173137 [details] [diff] [review]
Version 3.1

>@@ -1836,6 +1837,7 @@
>     work_time decimal(5,2) not null default 0,
>     thetext mediumtext,
>     isprivate tinyint not null default 0,
>+    already_wrapped tinyint not null default 0,

Nit: perhaps "iswrapped", to match "isprivate"? :-)

>+# 2005-01-29 - mkanat@kerio.com
>+if (!GetFieldDef('longdescs', 'already_wrapped')) {
>+    AddField('longdescs', 'already_wrapped', 'tinyint not null default 0');
>+    # Old, pre-wrapped comments should not be auto-wrapped
>+    $dbh->do('UPDATE longdescs SET already_wrapped = 1');
>+    # If a comment doesn't have a newline in the first 80 characters,
>+    # and it contains a space, then it's probably a mis-wrapped comment
>+    # and we should wrap it at display-time.
>+    print "Fixing old, mis-wrapped comments...\n";
>+    $dbh->do(q{UPDATE longdescs SET already_wrapped = 0
>+                WHERE POSITION('\n' IN thetext ) > 80
>+                  AND SUBSTRING(thetext FROM 1 FOR 80) LIKE '% %'});
>+}

The problem here is that POSITION returns 0 if the string is not in the text,
and so I don't think this will fix any of the comments which are completely on
one line...
http://dev.mysql.com/doc/mysql/en/string-functions.html
You could fix this, I think, by also checking for the POSITION call returning
0. (First position is position 1).

>+sub wrap_comment ($) {

Is it worth calling it "wrap"? We may use it for other things later...

>+    my ($comment) = @_;
>+    my $autoformat_options = {
>+        # Reformat all paragraphs, not just the first one.
>+        all        => 1,
>+        # Break only on spaces, and let long lines overflow.
>+        break      => break_wrap,
>+        # Columns are COMMENT_COLS wide.
>+        right      => COMMENT_COLS,
>+        # Don't reformat into perfect paragraphs, just wrap.
>+        fill       => 0,
>+        # Don't compress whitespace.
>+        squeeze    => 0,
>+        # Lines starting with ">" are not wrapped.

Paragraphs, actually.

>+        ignore     => qr/^>/,

We should probably also include a single space after the > here, to cut down on
false positives.

>+        # Don't re-arrange numbered lists.
>+        renumber   => 0,
>+        # Keep short lines at the end of paragraphs as-is.
>+        widow      => 0,
>+        # Even if a paragraph looks centered, don't "auto-center" it.
>+        autocentre => 0 };

Can we create this hash once, rather than every time we format a comment?

Gerv
(In reply to comment #241)
> (From update of attachment 173137 [details] [diff] [review] [edit])
> Nit: perhaps "iswrapped", to match "isprivate"? :-)

  Perhaps. I think "already_wrapped" is clearer as to what it actually means.

> You could fix this, I think, by also checking for the POSITION call returning
> 0. (First position is position 1).

  Cool. That should be easy to do. Good idea.

> Is it worth calling it "wrap"? We may use it for other things later...

  Well, it's a filter. Just like any filter, it should really only do one thing.
We could name it "reformat comment", I suppose, but I'd rather keep it at this
one purpose for now.

> >+        # Lines starting with ">" are not wrapped.
> 
> Paragraphs, actually.

  Hrm... Well, I don't *unwrap* paragraphs that start with ">", so I think that
might be confusing as a comment.

> >+        ignore     => qr/^>/,
> 
> We should probably also include a single space after the > here, to cut down 
> on false positives.

  Actually, you'll note that attachment comments don't have that space.

> Can we create this hash once, rather than every time we format a comment?

  Oh, good idea. :-) I'll make it an "our" variable at the top of the module.
Attached patch Version 4 — — Splinter Review 
OK, here's version 4! I made the changes that I agreed I would make in the
above comment.
Attachment #173137 - Attachment is obsolete: true
Attachment #173218 - Flags: review?(gerv)
Attachment #173137 - Flags: review?(justdave)
Comment on attachment 173218 [details] [diff] [review]
Version 4

r=gerv. :-) But you should get signoff from Dave and/or Myk on something this
potentially controversial.

Gerv
Attachment #173218 - Flags: review?(gerv) → review+
Flags: approval?
Attachment #173218 - Flags: review+
This ought to be mentioned in the non-existant end-user documentation that we
need to create ;)  (probably in the same place where it mentions how stuff gets
auto-linkified in the comments)
Flags: documentation+
Flags: approval?
Flags: approval+
Flags: documentation+ → documentation?
We have end-user documentation - Chapter 6 (currently) of the Bugzilla Guide.

Gerv
Another five year-old bug bites the dust!

Checking in attachment.cgi;
/cvsroot/mozilla/webtools/bugzilla/attachment.cgi,v  <--  attachment.cgi
new revision: 1.68; previous revision: 1.67
done
Checking in checksetup.pl;
/cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v  <--  checksetup.pl
new revision: 1.338; previous revision: 1.337
done
Checking in globals.pl;
/cvsroot/mozilla/webtools/bugzilla/globals.pl,v  <--  globals.pl
new revision: 1.300; previous revision: 1.299
done
Checking in Bugzilla/Constants.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Constants.pm,v  <--  Constants.pm
new revision: 1.16; previous revision: 1.15
done
Checking in Bugzilla/Template.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Template.pm,v  <--  Template.pm
new revision: 1.22; previous revision: 1.21
done
Checking in Bugzilla/Util.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Util.pm,v  <--  Util.pm
new revision: 1.20; previous revision: 1.19
done
Checking in t/004template.t;
/cvsroot/mozilla/webtools/bugzilla/t/004template.t,v  <--  004template.t
new revision: 1.35; previous revision: 1.34
done
Checking in template/en/default/bug/comments.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/comments.html.tmpl,v 
 <--  comments.html.tmpl
new revision: 1.14; previous revision: 1.13
done
Checking in template/en/default/bug/edit.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v  <--
  edit.html.tmpl
new revision: 1.54; previous revision: 1.53
done
Checking in template/en/default/bug/create/create-guided.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/create-
guided.html.tmpl,v  <--  create-guided.html.tmpl
new revision: 1.22; previous revision: 1.21
done
Checking in template/en/default/bug/create/create.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/create.html.tm
pl,v  <--  create.html.tmpl
new revision: 1.42; previous revision: 1.41
done
Checking in template/en/default/list/edit-multiple.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/edit-
multiple.html.tmpl,v  <--  edit-multiple.html.tmpl
new revision: 1.23; previous revision: 1.22
done
Checking in template/en/default/pages/linked.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/pages/linked.html.tmpl,v 
 <--  linked.html.tmpl
new revision: 1.8; previous revision: 1.7
done
Checking in template/en/default/pages/linkify.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/pages/linkify.html.tmpl,v
  <--  linkify.html.tmpl
new revision: 1.5; previous revision: 1.4
done
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Whiteboard: READ COMMENT 138 BEFORE PROPOSING SOLUTION [content:comments]
Blocks: 282331
No longer blocks: 282331
This has been added to the release notes in bug 297590.
Keywords: relnote
*** Bug 308939 has been marked as a duplicate of this bug. ***
(In reply to comment #247)
> Another five year-old bug bites the dust!

I am afraid of that not at all the necessary places has this wrap been changed.
We are using Bugzilla 2.20 at our office and found the followings (from the
generated HTML output and from the template sources):

* no wrap attribute at all in "Additional Comments" when changing a bug:
  <textarea name="comment" id="comment" rows="10" cols="80"
accesskey="c"></textarea>

* "Comment on bug" when editing attachments:
 <textarea name="comment" rows="5" cols="25" wrap="soft"></textarea>

As I am a outsider I can't reopen this bug but please pay attention to this issue!
(In reply to comment #250)
> We are using Bugzilla 2.20 at our office and found the followings (from the
> generated HTML output and from the template sources):

Of course, I mean the samples from the HTML output and NOT from the templates.
Sorry.

(In reply to comment #250)
> * no wrap attribute...

  Of course there's no wrap attribute. That's the whole point of the bug. They
were all removed. Read the whole bug. :-)
Shouldn't all the "<textarea id="comment" name="comment" rows="5"
cols="80"></textarea>" have their width set to COMMENT_COLS (or to a separate
constant)?
This would demonstrate the mamimum width of a comment while typing.
(In reply to comment #96)
> Ok, never mind, I found the problem and it's on my side. I have an anti-ads
> software (proxomitron). It seems that it adds the "wrap=soft", and for some
> reason, it doesn't do it on my server.
> 
> (and this comment should correctly wrap)
> 
> Sorry about that.

I just had the same problem with Bugzilla version 2.18.3.

FYI the name of the filter to turn off in Proxoitron is "Wordwrap all form textboxes"

I see that this has been talked about for years, literally, so I'm not going to suggest any more solutions :)
(In reply to comment #253)
> Shouldn't all the "<textarea id="comment" name="comment" rows="5"
> cols="80"></textarea>" have their width set to COMMENT_COLS (or to a separate
> constant)?
> This would demonstrate the mamimum width of a comment while typing.

For a quick hack on tying the width of the field "Additional Comments" to the constant COMMENT_COLS see bug# 328089.
Bugzilla-2.20.1 recognises that wrapping should not be done by the browser.
This is good. It does it later at bug-display-time. This is good too.

BUT it does it on the server before it knows the browser width.
We get ...
use constant COMMENT_COLS => 80;
... which assumes things about the clients' resolution browser and window size.

The attached patch against Bugzilla-2.20.1 delays comment wrapping still further. Now we do it on the browser which feels nicer somehow. I scale my browser and everything re-flows as I do so. :)
David: please read the rest of this bug. That sort of wrapping was rejected for very good reasons.

Gerv
Attached patch documentation patch - draft1 (obsolete) — — Splinter Review 
I took the bits Max wrote for the release notes and adding them to the user guide. Dave mentioned in the ticket to put this by the linkifaction bit, so that's why it is in the hintsandtips section.

Thoughts?
Attachment #297448 - Flags: review?(documentation)
Comment on attachment 297448 [details] [diff] [review]
documentation patch - draft1

You don't need the historical note, just an explanation of what bugzilla does and the use of the > character, I think.
Attachment #297448 - Flags: review?(documentation) → review-
Also, if there's some sort of section on using show_bug.cgi or something about the comment or description field, the docs would belong better there.
Thanks for the quick response! That is what I was originally thinking, so here is a slimmed down version.
Attachment #297448 - Attachment is obsolete: true
Attachment #297450 - Flags: review?(documentation)
Comment on attachment 297450 [details] [diff] [review]
draft 2 of docs patch

That's fine. If there's some better section for this, that would be good.

You probably don't need to explain that it stores them unwrapped, but whatev.
Attachment #297450 - Flags: review?(documentation) → review+
tip:

Checking in docs/xml/using.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v  <--  using.xml
new revision: 1.73; previous revision: 1.72
done

3.0.3:

Checking in docs/xml/using.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v  <--  using.xml
new revision: 1.64.2.7; previous revision: 1.64.2.6
done

2.22.3:

Checking in docs/xml/using.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v  <--  using.xml
new revision: 1.37.2.23; previous revision: 1.37.2.22
done

2.20.5:

Checking in docs/xml/using.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v  <--  using.xml
new revision: 1.33.2.25; previous revision: 1.33.2.24
done
Flags: documentation?
Flags: documentation3.0+
Flags: documentation2.22+
Flags: documentation2.20+
Flags: documentation+
Just wanted to add this.  This issue has been driving me nuts on a project for over a year.  Wanted to record some 100 column log file output without wrap and just couldn't do it.  If you are still struggling with the auto wrap, here is what I changed to fix.  Very happy now!

1) diff ./template/en/default/admin/params/common.html.tmpl ./template/en/default/admin/params/common.html.tmpl.sav
43c43
<                   rows="10" cols="100">[% Param(param.name) FILTER html %]</textarea>
---
>                   rows="10" cols="80">[% Param(param.name) FILTER html %]</textarea>

2) root@office:/var/www/bugzilla# diff ./skins/standard/global.css ./skins/standard/global.css.sav
300c300
<      width: 75em;
---
>      width: 50em;

3) root@office:/var/www/bugzilla# diff ./Bugzilla/Comment.pm ./Bugzilla/Comment.pm.sav
148c148
<         # (JM disabled) $body = wrap_comment($body);
---
>         $body = wrap_comment($body);
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: