First list level pastes with extra space

Assigned to



17 years ago
10 years ago


(Reporter: neil, Assigned: t_mutreja)


Windows 95

Firefox Tracking Flags

(Not tracked)



(1 attachment)



17 years ago
Using Build ID: 2002052402
Steps to reproduce problem:
1. Open HTML editor.
2. Start a bulleted list. Type "Test 1" and Enter.
3. Press TAB. Type "Test 2" and Enter.
4. Press TAB. Type "Test 3".
5. Select All, Copy.
6. Paste into a plain text field.

Expected results:
    * Test 1
          o Test 2
                + Test 3

Actual results:
    *  Test 1
          o Test 2
                + Test 3

Additional information:
In the process of determining the above steps, I now notice that if you replace
Step 5 with Select All, Cut, Paste, Select All, Copy it pastes correctly!

Comment 1

17 years ago
--> Myself.
Assignee: harishd → t_mutreja


17 years ago

Comment 2

17 years ago
Created attachment 89682 [details] [diff] [review]
Patch V1.0

I tested the patch with all the build test cases and quite many others that I
could think of. I'm wondering if for some reasons we really need to add a space
for the first character when nsIDocumentEncoder::OutputSelectionOnly is true
i.e. (!mStartedOutput && mFlags | nsIDocumentEncoder::OutputSelectionOnly) is

Comment 3

17 years ago
CC'ing Daniel.

Comment 4

17 years ago
Comment on attachment 89682 [details] [diff] [review]
Patch V1.0

I think I see why this was there.  This does fix the problem for lists, because
even though mStartedOutput is false, we actually have already output something
(the bullet).  But for something that doesn't have a bullet, and starts with a
space, and isn't in a pre, the space will get lost.  Try loading any page (e.g.
the start page) and select a space followed by a word, then pasting the
plaintext somewhere.  With the patch, the space gets lost.

Perhaps the solution is to output the space when we output the bullet, and set
mStartedOutput at that time, so that we won't get into this clause?  Or would
that cause problems somewhere else?
Attachment #89682 - Flags: needs-work+

Comment 5

17 years ago
In fact PlainTextSerializer is working properly and the bug seems to be in 
Composer. When a list is created by Mozilla composer, it adds a new line and 
two white spaces after every "UL" and "OL" and this keeps on increasing with 
nesting. For an HTML generated by following the steps mentioned in this bug 
i.e. through Mozilla Editor, DUMP CONTENT output is as follows:

  body@02A2A320 refcount=4<
    Text@02A3A7A0 refcount=3<\n>
    ul@02A3A6F0 refcount=3<
      Text@02A3A6A0 refcount=3<\n  >
      li@02A3A5B0 refcount=4<
        Text@02A3A560 refcount=3<test1>
      Text@02A3A470 refcount=3<\n  >
      ul@02A3A410 refcount=3<
        Text@02A3A3C0 refcount=3<\n    >
        li@02A3A320 refcount=4<
          Text@02A3A2D0 refcount=3<test2>
        Text@02A3A1E0 refcount=3<\n    >
        ul@02A3A140 refcount=3<
          Text@02A3A0F0 refcount=3<\n      >
          li@02A3A050 refcount=4<
            Text@02A3BFD0 refcount=3<test3>
            br@02A3BEA0 refcount=3<>
            Text@02A3BDF0 refcount=3<\n      >
          Text@02A3BCC0 refcount=3<\n    >
        Text@02A3BBF0 refcount=3<\n  >
      Text@02A3BB50 refcount=3<\n>
    Text@02A3A7F0 refcount=3<\n>

However if an HTML file is written with some text editor and no additional 
space / lines are added, Serializer works simply perfect. If there is some 
reason for those spaces(though it doesn't look like), we can try for some band-
aid fix.

Comment 6

17 years ago
Oh, those are the indentation spaces and I don't know how to differentiate them 
from a genuine space. Though, if the Parser bug# 15378 can be fixed to neglect 
newlines and white spaces, this bug will just go away.
Depends on: 15378
QA Contact: sujay → dom-to-text
You need to log in before you can comment on or make changes to this bug.