From Bugzilla Helper: User-Agent: Mozilla/4.7 [en] (Win98; I) BuildID: 2000112608 There are problems already mentioned regarding Composer's handling of spaces, including bugs 57891, 60274 and 60867. In addition to those reported problems, but probably related to them, is the interaction between Composer's rewriting of spaces and its mechanism for wrapping lines of HTML source. The result is that doing almost anything to the example paragraph of HTML (which Composer created) results in two anomalous spaces being added inside the paragraph. Reproducible: Always Steps to Reproduce: As shown in the file at the URL, adding a space or doing almost anything immediately causes two anomalous spaces to be added. This has been tested on Win98 and Linux. The sample file investigates in detail the problematic behaviour of the space-rewriting system when the HTML line-length-wrapping mechanism is not activated , since the line is still short. This provides a background to the abovementioned Bugzilla bugs. I propose that the trouble is in or associated with: /editor/base/nsHTMLEditRules.cpp nsHTMLEditRules::DoTextNodeWhitespace but I figure someone else is better positioned to dive in there than me. I think that the same underlying problem also caused problems in N4.x's Composer, which corrupted files according to its internal HTML line-length limiting system. I reported these in June last year. - Robin

I have added a second example file: http://gair.firstpr.com.au/public-files/mozilla-bugs/mb-comp-space-2.html which shows clearly how the whitespace rewriting stuff is causing big trouble with spaces appearing surprisingly. In this instance, a valid, but rather odd "two spaces" (actually, something much more complex - but Mozilla created it and it is valid HTML as two spaces) is pasted 7 times at the start of a paragraph, to give 14 spaces. Fine, until you do anything to change the paragraph with Mozilla! It expands to 76 spaces! Do something to the resulting paragraph and it grows even more spaces. These are extreme examples of a general malaise with Mozilla Composer - that spaces pop up when you least expect them, between words and at the start of lines.

this is a known issue and I believe there is a bug open already -- assigning to jfrancis

I have spent probably 40 hours attempting to fix what I thought was a straighforward problem. (Quite a bit was getting it compiling under Win98 - Linux was easy.) In fact, there are several mechanisms working together to give the various whitespace problems which I and no-doubt most other Composer users experience very commonly. I can't spend any more time on this. I would really appreciate it if someone on the Editor team would take a close look through this file: http://gair.firstpr.com.au/public-files/mozilla-bugs/mb-comp-space-3.html This discusses the mechanisms which seem to interact, including the AdjustWhitespace code, the file save line-wrapping code and the really pesky and dumb bug by which Composer adds spaces at the start of many lines for each save and re-read from disk cycle. I hoped that a new algorithm of rewriting whitespace would fix the trouble, but it doesn't. The algorithm may be useful and arguably better than the current one, and it is just the same as N4.x, as far as I know. The code is in the above directory and its principles and differences from the current approach are described in the above URL. As I wrote the above, the whitespace bug kept happening - extra spaces between words and at the start of lines, because by then (several saves and re-openings) Mozilla had added spaces to the start of many lines, and when AdjustWhitespace gets to them, it quite rightly turns them into spaces which mean something in HTML. (The whitespace code should accept multiple spaces as valid, since they could have come from a cut and paste from text input, or from some other source - or one of the spaces could be because the user pressed the spacebar in the middle of or next to some existing whitespace.) There is also a bug demo in that file on how to make a zombie dialog box after unsuccessfully turning a list into not a list. I am patient and keen to fix these bugs, but I can't justify putting off paying work like this. There are bugs in "View HTML Source" too. It adds <br> characters at the end each View HTML Source, with a perfectly empty file! Don't use it if if you are trying to debug what is happening inside Composer! It doesn't show the internal data structure anyway. As noted above, I believe View HTML Source can break a node into multiple nodes according to the way it wraps the text it displays. There are multiple subsystems here, not owned by the one person or even the one team. Every user of Composer has to have their work run the gauntlet of them and collectively, they make a mess. If I had a few weeks I would sort this all out. It requires a fresh look at every stage of the system, with a variety of HTML examples. The above URL gives several examples where the current system is not coping at all. It is vital that the user's whitespace input be respected. If they press the spacebar 7 times, there should be 7 spaces - no ifs and no buts. There are some fabulous things about Composer, particularly in the table department, but for now I am going back to Netscape 4.7. I look forward to the Lizard being rigorous and orthogonal in the Composer department, as I think it is becoming in others. - Robin

This bug has been discussed on the editor newsgroup. There I posted some simple tests which show whitespace trouble with file save and View HTML source even when the file is very small. Joe Francis responded that he was rewriting the way white space is handled - abandoning the current post-edit cleanup which cannot know what was just added or deleted. This sounds like the only way to proceed. Here is a simple test which reveals a potentially related bug in copy and paste. One of the of whitespace trouble is spaces appearing at the start of lines for no good reason. Here is how to do it easily. This works with Win98 2000112908, but I think is almost certainly a cross-platform problem: Open new Composer page. Type"0000" and then Enter. Type"1111" and then Enter. Type"2222" and then Enter, Enter and Enter. Control A to select all. Control C to copy to clipboard. Down arrow to remove selection. Contol V, Control V, Control V. Now save the file. The results look good on screen and in a browser, but the file contains unwanted spaces of the type which will later cause whitespace trouble for composer. Copy and paste evidently does something to the data! <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <title>!</title> </head> <body> 0000<br> 1111<br> 2222<br> <br> <br> 0000<br> 1111<br> 2222<br> <br> <br> <br> 0000<br> 1111<br> 2222<br> <br> <br> <br> 0000<br> 1111<br> 2222<br> <br> <br> <br> <br> </body> </html> If you View HTML Source, and then save the file, then every body line above, except those with a single <br>, has an extra space added at the start. Each use of View HTML Source adds another space - you can see it on screen. Saving such a file, say with five or six spaces at the start of each line still looks OK in Composer or a browser, but if you alter a line, then the spaces are converted into visible spaces. - Robin

moz 0.9

Hi Robin, Just an update to let you know that I am making good progress on these issues. It is piss-ass hard to get this stuff right in the landscape editor lives in, but we are getting there. I have patches in bug 65557 which improve some of the problems you found. It is a work in progress and there is still a ways to go, but I thought you might be interested.

pushing off ws work to moz0.9.1 since it is not ready for prime time. Interested parties should check out bug 65557, which has the patches. We are getting pretty close here.

pulling back some bugs which may be fixed by the whitespace work.

ws work has landed. fireball of death now at end of runway.

this puppy is fixed (0n 0514 trunk). rw@firstpr.com.au, please double-verify with a latest build .Thanks!!

This bug appears to be alive and well in build 20010924. When opening a saved file, a blank space is added to the beginning of each line in the html source code. When using copy and paste, a blank space is added to the beginning of every line of pasted text except the first. A blank space will be added to a line of text if you use formatting that ends at a point that causes the html source code to wrap to the next line, unless the formatting ends at a point where there is a space anyway. Easiest way to view this part is: Steps to reproduce: 1. Open a blank composer page 2. Type in "12345678901234567890123456789012345678901234567890" 3. Highlight a section of text ending within the last 7 numbers (but not all the way to the end) 4. Click on color picker, and change color of selected text. 5. Browse the page. Actual result: A space will be added to the line at the point where the text changes back to default color (although normal view in composer does not show the space). If you look at the html source code, the line will end with </font> with the remaining numbers wrapped to the next line. Other formatting of text does the same thing, but you have to type in more text to see it since a color change tags take up more space in the html code. Reproducible: always

TucsonTester2, please open a new bug against component "DOM to text conversion".

Per request, I have opened this as a new bug against component "DOM to text conversion" Bug #101755