Open Bug 282244 Opened 15 years ago Updated 6 months ago

Pasting in standards mode uses quirks-mode parsing

Categories

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

defect

Tracking

()

People

(Reporter: bzbarsky, Unassigned)

References

Details

Attachments

(1 file)

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....
Attached file Testcase.
Any ideas what's up here?  Does editor use some other string-to-DOM method when
pasting?
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.
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...
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++
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.
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...
Assignee: mozeditor → general
Component: Editor → DOM
OS: Linux → All
QA Contact: bugzilla → ian
Hardware: PC → All
Assignee: general → nobody
QA Contact: ian → general
Depends on: 650784
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.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.