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. ***

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 .)

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.

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.

*** Bug 29051 has been marked as a duplicate of this bug. ***

Moving to real milestones...

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.)

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! ;-)

I'd be much obliged to ;) As soon as the rush is over at Syndicomm (probably a week or two).

*** Bug 82700 has been marked as a duplicate of this bug. ***

*** 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. ***

adding to 2.16 block list, fixing component.

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

This patch includes the removal of the dependencies on Text::Wrap, and all of the wrap=hard attributes in the affected textareas.

Patch v2 is live on http://landfill.tequilarista.org/bz11901/

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

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

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. ***

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.

> 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

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.

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>

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

*** 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?

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.

> 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.

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 (-)....

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

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.

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. ***

a test :)

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. ***

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.

(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

some food for thought

some food for thought too

*** Bug 167802 has been marked as a duplicate of this bug. ***

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.

In fact, I'm going to implement it.

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).

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.

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.

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.

(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.

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.

Oh, and there's a test installation at: http://landfill.bugzilla.org/bz11901v2/ Not sure if I mentioned that already.

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 Success: http://landfill.bugzilla.org/bz11901v2/show_bug.cgi?id=33#c2 http://landfill.bugzilla.org/bz11901v2/show_bug.cgi?id=1#c9 http://landfill.bugzilla.org/bz11901v2/show_bug.cgi?id=274#c1 http://landfill.bugzilla.org/bz11901v2/show_bug.cgi?id=279#c3 What the tip does, now (compared from "Success"): http://landfill.bugzilla.org/bugzilla-tip/show_bug.cgi?id=33#c2 http://landfill.bugzilla.org/bugzilla-tip/show_bug.cgi?id=1#c9

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.

(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.

(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.