282244 - Pasting in standards mode uses quirks-mode parsing

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Boris Zbarsky [:bzbarsky]]

Testcase coming up.  Note that I thought I had fixed this in bug 106565 (since
pasting uses CreateContextualFragment, iirc), and the testcase in that bug is
still fixed, but I do see a problem with the testcase I'm going to attach....

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Any ideas what's up here?  Does editor use some other string-to-DOM method when
pasting?

Comment 3

[Kathleen :Brade]

The editor should be pulling the data off of the clipboard.  Pasting into a
textarea should be triggering this code:
http://lxr.mozilla.org/seamonkey/source/editor/libeditor/text/nsPlaintextDataTransfer.cpp#111

Is the problem with "copy" or "paste"?

bz--can you clarify what you see with your testcase?  I see a leading space but
I'm on a Mac so maybe it's different; I'm not sure.

Comment 4

[Boris Zbarsky [:bzbarsky]]

With the testcase, there should be two lines of text pasted.  I see three lines
pasted; the second of those is inside a comment in the source...

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

The problem here is that we end up calling into nsParser::Parse(const nsAString
&...) with a doctype of eDTDMode_fragment, which triggers quirks mode in the
tokenizer.

Is there a reason that the pasting code/editor didn't use
nsIParser::SetCommand() on the parser, and instead chose to use the aMode
parameter to pass this information along? If it did use SetCommand(), it could
also pass in the standards/quirks mode, which would fix this.

For reference, here is the callstack to the Parse() call.
>	gkparser.dll!nsParser::Parse(const nsAString & aSourceBuffer={...}, void *
aKey=0x00000000, const nsACString & aMimeType={...}, int aVerifyEnabled=0, int
aLastCall=1, nsDTDMode aMode=eDTDMode_fragment)  Line 1687	C++
 	gkwidget.dll!nsHTMLFormatConverter::ConvertFromHTMLToUnicode(const
nsAutoString & aFromStr={...}, nsAutoString & aToStr={...})  Line 318 + 0x33	C++
 	gkwidget.dll!nsHTMLFormatConverter::Convert(const char *
aFromDataFlavor=0x02315e24, nsISupports * aFromData=0x03a4d598, unsigned int
aDataLen=220, const char * aToDataFlavor=0x02315e14, nsISupports * *
aToData=0x0012d210, unsigned int * aDataToLen=0x0012d208)  Line 254 + 0x1a	C++
 	gklayout.dll!nsCopySupport::HTMLCopy(nsISelection * aSel=0x03ada658,
nsIDocument * aDoc=0x03a94ef8, short aClipboardID=1)  Line 128 + 0x6c	C++

Comment 6

[Boris Zbarsky [:bzbarsky]]

So that looks like a bug in the copy code, then....  It's serializing the HTML
and then reparsing it incorrectly to get the Unicode text.

Comment 7

[Boris Zbarsky [:bzbarsky]]

OK, so maybe nsCopySupport needs to handle just create the plaintext using the
plaintext serializer instead of the mess it does now with the htmlconverter?

Over to DOM, since this is content code...

Comment 8

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.