Paste or drag&drop HTML content crashes

VERIFIED FIXED in mozilla1.9beta2



12 years ago
12 years ago


(Reporter: dpopa, Assigned: mats)


({crash, regression})

Bug Flags:
blocking1.9 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)




(2 attachments)



12 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007111404 Minefield/3.0b2pre

If you try to paste or drag&drop content inside a page having a tag with contentEditable="true" will crash the browser.

Conditions for crash:a tag with contentEditable exists inside the page or the designMode is "on".

This happens only if the content beeing copied or dragged is HTML.

This does NOT happen if content is plain text (like beeing copied from a textarea): 
 - copy from textarea, paste into the editable tag: OK
 - drag text from textarea into the editable tag: nothing happens, but no crash.

Reproducible: Always

Steps to Reproduce:
1. goto
2. copy content from the document
3. paste anywhere inside the document (doesn't matter where)
Actual Results:  
browser crashes

Expected Results:  
not crash

Comment 1

12 years ago
You can reproduce the bug inside a page with designMode="on" here:

You'll also notice that when Firefox starts and one of the TABs beeing restored has designMode="on" will causes all the tabs to have JavaScript disabled.


12 years ago
Component: Editor → HTML: Parser
Ever confirmed: true
Flags: blocking1.9?
Keywords: crash, regression
OS: Windows XP → All
QA Contact: editor → parser
Hardware: PC → All

Comment 2

12 years ago
Posted file stack
Note theCount = 0 in nsParser::ParseFragment

Comment 3

12 years ago
Posted patch Patch rev. 1Splinter Review
When 'theCount' is zero in nsParser::ParseFragment() the first call
to Parse() will simply return without creating a context.,1433,1439,1447#1297

This fixes the first crash at least. I can't reproduce the second one.
Assignee: nobody → mats.palmgren
Attachment #288830 - Flags: superreview?(mrbkap)
Attachment #288830 - Flags: review?(mrbkap)

Comment 4

12 years ago
The branch code looks almost the same but probably wouldn't crash in
a similar situation due to a wallpaper for bug 358797:

The suggested patch should also work on branch if we want it - it would
make the testcase in bug 358797 not assert and createContextualFragment()
will return a valid DocumentFragment rather than throwing.
Comment on attachment 288830 [details] [diff] [review]
Patch rev. 1

Attachment #288830 - Flags: superreview?(mrbkap)
Attachment #288830 - Flags: superreview+
Attachment #288830 - Flags: review?(mrbkap)
Attachment #288830 - Flags: review+


12 years ago
Attachment #288830 - Flags: approval1.9?

Comment 6

12 years ago
This is the same crash as bug 403664 right?

If so you probably could bring over the blocking flag and priority.  
I don't understand, how could bug 403549 have caused this? Is the problem that theIndex get out-of-range?
Blocks: 403549
Flags: blocking1.9? → blocking1.9+
Priority: -- → P1
Please address Jonas' question.  Once addressed, release drivers will approve.
Ok, this should land. Bug 403664 contains the fix for the regression from bug 403549.
Actually, could you hold off landing this until we've fixed the real regressions from bug 403549. I'm worried landing this would mask real bugs.


12 years ago
Version: unspecified → Trunk

Comment 11

12 years ago
I heard reports that this patch fixes bug 403841 - just FYI.
I don't think it fixes the regression, but it probably fixes the crash.
Jonas, in what bug are "the real regressions from bug 403549" being pursued?
IOW, how will Mats know when to commit this fix?
We trunk mail users desperately want this fix!
In bug 403841. But there is a patch there now, so feel free to land here!

Comment 15

12 years ago
mozilla/parser/htmlparser/src/nsParser.cpp 	3.404 

Last Resolved: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M10


12 years ago
Flags: in-testsuite?
Verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007112805 Minefield/3.0b2pre. I verified by using the STR in both Comment 0 and Comment 1.
You need to log in before you can comment on or make changes to this bug.