Text entered for a newly created bug is automatically line-wrapped. Text emtered for a subsequent comment is not. See bug 35173 for an example.
I don't see it! Much thanks to agriffis for finding the fix on the line wrap policy without screwing it up server side=)
Well, I'm looking at the source of the referenced bug and this is what I'm seeing: [...] Expected Results: Ideally, loaded a kernel, producing zillions of lines of load messages, then continued with a (stage 1) install.</pre> </div> [...] <pre>Note that "(Mandrake boot disk goes here.)" is left over from the equivalent issue on the Mandrake support boards. I cut and pasted the hardware list and forgot to remove this annotation before committing the message. <sigh> But this does remind me: The erroneous behaviour is observed when booted from either DVD drive (-ROM or -RW), for all tested failing distributions. The Gentoo (and Mandrake) media successfully install to other machines (not a bad CD image).</pre> </div> Since I typed both messages, I know that neither message included explicit linebreaks. Interestingly, the initial message is broken into lines when shown, but the follow-up is not.
pre means do not edit the code, show the code as typed in. What that means is it takes the code from the SQL database and does no code formatting, this makes ascii code and line breaks through mysql show up just as it was typed in the first time. There is a css that does the line breaks for <pre> without screwing up the server side display time. I have checked with 5 different browsers and the bug shows fixed through all of them. Let me know what browser you're using if the problem persists.
On Mozilla 1.5 [Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007]... When viewing the referenced bug, resizing the window horizontally reflows the follow-up text, but does not reflow the initial description. Neither the inital description nor the follow-up were entered with explicit linebreaks. The initial description is displayed with explicit linebreaks, but the follow-up is not. When I was viewing this bug on a (temporary) machine this weekend, using Mozilla 1.1, the initial description had fixed breaks, but the follow-up lines "ran off the right to infinity". (Meaning that the browser wasn't even reflowing them. <sigh>) If I hadn't seen this, I wouldn't have noticed, since my normal browser window width is about the same as the explicit linewidths in the initial description. (So the reflowing text looks rather like the explicitly broken text in my normal browser window.)
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 do you have a screenshot? it works fine on this end
Created attachment 21878 [details] ZIP of two BMPs showing narrow and wide view reflow.zip contains two bmps. narrow.bmp shows the end of the inital post and the entirety of the follow-up and indicates. wide.bmp shows the same material. Wide indicates that the inital posting is not being reflowed (i.e. includes explicit linebreaking) but the follow-up is. Neither the inital post nor the follow-up were input with linebreaks. I.e. they were entered as one line per paragraph.
thanks for pointing it out for me... in the past it used to go horizontally off the screen and was really quite annoying because people would scroll the screen to the right to see 400 words on one line and no line breaks. The problem with this was the browser would not do line wrap when entering in the text in the additional comments box, this was a client side problem and bugzilla admin folks would not fix. The next best fix was the css which allows us to do wrap according to browser size... The part you mentioned on the line break in the first comment is because it's stored in a different place than the later additional comments, it's not perfect but it'll have to do, sorry. By the way did you add the line breaks in your last comment?
Nope. I didn't insert explicit linebreaks. It *may* have been the form that accepted the attachment comments. I note that there are three input portals: 1) Create a new issue, 2) Comment on an issue, and 3) Make an attachment. It seems that using 1 or 3 produces (explicit) linebreaks, but 2 does not. I wonder if there's some sort of evident difference between the textboxes that soak up the comments. I'd guess not... :-/ Would it be possible to break methods 1 and 3 to use the same reflowing CSS that is used for 2? (Just throwing out ideas... Many will be bad. :-) ) Can displays of "type 2" information be forcibly broken into lines? This isn't a "fall over dead" problem. I just noticed it and thought, "this has got to be one of those things nobody notices unless their browser is doing something strange" (like not wrapping lines at all or being way too wide). Odds are I'm the only person who's noticed in quite a while... :-) I'm inclined to mark this bug as resolved, WONTFIX or CANTFIX, given what you've mentioned about the Bugzilla admin folks. This seem about right?
i removed all instances of wrap=soft which was causing the problem to wrap in some areas and not others, this is majorally a browser bug BUT with css in place we won't see the bad formatting at all, it'll just wrap according to browser size
