Closed Bug 57891 Opened 25 years ago Closed 25 years ago

Composer eats single space between words in saving a document

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 56833
Milestone:
mozilla0.9

People

(Reporter: tao, Assigned: akkzilla)

References

Details

(Whiteboard: data loss [rtm need info] FIXED ON TRUNK, DUP OF 56833)

Attachments

(2 files)

a sample file
8.53 KB, text/html
Details
another sample file
16.70 KB, text/html
Details
Build: 2000-10-24-9-MN6. I use composer to create a blank document and then copy/paste text from a bug report. After some clean up, I click on "Browse" button to view the page. I found some spaces between words disappear. So I ran SpellChecker and correct them one by one. I save it again and browse it... the spaces are gone again....
Attached file a sample file —
multiple spaces are not preserved in an HTML file, that is part of the specification. If you want spaces between words -- you will need to do one of the following: 1. place the text you want within a PRE element, that stands for preformatted and ignores the standard whitespace rules as imposed by the spec, or 2. use the insert HTML dialog and enter   (as many as you need to get the spacing you desire)
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Summary: Composer eats white spaces in saving a document → Composer eats white spaces in saving a document
verified in 10/25 build.
Status: RESOLVED → VERIFIED
I am not referring to multiple spaces; I did mean single space. For example, "regChrome utility will" becomes "regChrome utilitywill". I had seen it happened to 2 different HTML documents.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
I am seeing this a lot using latest mn6 commercial builds. Very annoying.
Possibly a release note item?
Oh, and to clarify: I am seeing single spaces removed in between words. Not all words, but lots of them in apparently random places. I am switching to 4.x editor to avoid having to constantly re-edit to put spaces back in.
Attached file another sample file —
losing spaces when converting to html (on disk) is data loss. adding editor big-wigs to the cc list. do we go through some sort of DOM -> HTML serializer when we save?
Whiteboard: data loss
Have you tried it in the trunk? I fixed a very similar bug in the trunk, but it wasn't PDT approved so it didn't make it into the branch. See bug 54477 and bug 26093.
Disregard bugs referenced in last comment: the bug in question was bug 56833, which is fixed on the trunk.
ahh -- sorry, I took your initial report to mean multiple spaces were being removed, not single spaces between words. I am reassigning this one to jfrancis, he is working on other whitespace issues and this will probably be resolved during that work.
Assignee: beppe → jfrancis
Status: REOPENED → NEW
Target Milestone: --- → mozilla0.9
I'm running some ns6 branch bits from 10-26 right now and I can't reproduce the problem. I do beleive the problem, though. Can someone give me some *exact* steps to reproduce? Like the specific text to copy from a specific page? Did you copy text from out of a textarea in the bug report, or was it text that was already in the bug report? I'm guessing that this only happens when you copy enough text that the output system forces wrapping at save time, but I haven't been able to confirm it yet.
Joe: yes, that was the case in bug 56833 (which also doesn't have any easy-to-follow repro instructions in it). What I did was take blizzard's html source in that bug, insert it into a composer document, and switch back and forth between source and normal modes, and somewhere along the line wrapping occurred in the source and then the space disappeared (replaced by the newline). I didn't attach exact repro instructions to the bug because it seemed to be slightly different with each day's build, so you may have to fiddle a bit to get it to happen. AFAIK, it's fixed in the branch but still extant on the trunk.
Change summary field to reflect the problem... This bug is keeping me from using Composer in Seamonkey... Should we consider it RTM blocker since there is no work around?
Summary: Composer eats white spaces in saving a document → Composer eats single space between words in saving a document
there is a really easy way to reproduce this. using vi or notepad, create a file on disk like this: <html> <body> this is a test </body> </html> view it, it will say "this is a test" open that file in editor, save it. now view it again. it will say "thisisatest" marking rtm.
Keywords: rtm
cc'ing some pdt people to help assess the stop-ship nature of this bug. in mail we see it when you "save as draft".
Whiteboard: data loss → data loss [rtm need info]
Thanks for the test case. It would be really helpful if someone who is seeing the bug on a current branch build would try the patch in bug 56833, or, alternately, just see if it happens on the trunk (where the patch landed long ago) to see if this is the same bug or not.
I just checked: my test case is fixed on the trunk, but not on the branch. I just tried it on two release builds.
It seems to me this problem happens in saving HTML documents/messages that are not generated by Seamonkey only. Since it is reproducable in Message Composition, it could be seen in "reply", "reply all", and "edit message as new"... Would QA verify this?
I'm convinced this is a dup of 56833, but since this one has Seth's test case and an rtm nomination, I'll leave it open 'til PDT decides. Meanwhile, taking off Joe's list, since it has nothing to do with his stuff. Tao: Shaver seemed to indicate he saw 56833 in original messages, though he was never able to give instructions on how to reproduce it. Cc'ing, maybe he can clarify.
Assignee: jfrancis → akkana
Whiteboard: data loss [rtm need info] → data loss [rtm need info] FIXED ON TRUNK, DUP OF 56833
Status: NEW → ASSIGNED
note to pdt, here is the fix that landed on the trunk: Index: nsHTMLContentSerializer.cpp =================================================================== The following patch seems to cure the missing space problem: RCS file: /cvsroot/mozilla/layout/base/src/nsHTMLContentSerializer.cpp,v retrieving revision 1.11 diff -r1.11 nsHTMLContentSerializer.cpp 444a445 > AppendToString(NS_LITERAL_STRING(" "), aOutputStr);
should we get this (super) reviewed first?
From bug 56833: The patch has r=jst, sr=shaver. What about [rtm+]?
Had any code/logic surrounding the patch being changed? If so, better get a fresh review first.
Don't know if it could land on RTM... I doubt it... but getting r= and sr= would help if we had a respin, and could justify taking the change.
I say r=jst for the attached patch, we've had it on the trunk for a while and there are no know problems with the patch, if there's a respin I'd say include this if possible...
actually, this is easily reproduced within Composer, you do not need to use another editor for copy paste. Just add a few lines of text in a new compose window, save it and view it in the browser. There will be words sporadically joined (2 words), bring it back into Composer, add a space at the end of the text string (to enable the save), save it and view it in the browser again (3 words are now joined). It's really odd behavior. I have not tried the trunk build.
Adding 56833 and 56921 to the dependency list. Bug 56833 mentions the need for 56921, how necessary is 56921?
Depends on: 56833, 56921
winNT 11/07 MN6 I am completely unable to reproduce this following beppe's steps. What are the steps a regular user would follow to reproduce this?
How does this depend on 56921? I don't understand why you added either of those dependancies.
OS: Windows NT → All
Please see the comment I added 2000-11-07 11:29. 56833 is only fixed on the trunk, but is currently the basis for fixing this bug. 56833 mentions the need for 56921. If that dependency is not true, nobody has made any updated comments to that effect.
56921 was just another bug noticed while investigating 56833. It's independant (a problem with the algorithm used to decide where to wrap) and isn't listed as a dependency for 56833, so shouldn't be for this either. Removing that bug from the dependency list (but leaving 56833).
No longer depends on: 56921
Marking a dup of the one that's fixed on the trunk ... no point in keeping this open, it wasn't approved for the NS6 branch. *** This bug has been marked as a duplicate of 56833 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
verified in 1/12 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: