Paste or drag&drop HTML content crashes

VERIFIED FIXED in mozilla1.9beta2

Status

()

defect
P1
critical
VERIFIED FIXED
12 years ago
12 years ago

People

(Reporter: dpopa, Assigned: mats)

Tracking

({crash, regression})

Trunk
mozilla1.9beta2
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(2 attachments)

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 http://www.mister-pixel.com/ever/bugs/firefox/crashonpaste.html
2. copy content from the document
3. paste anywhere inside the document (doesn't matter where)
Actual Results:  
browser crashes

Expected Results:  
not crash
You can reproduce the bug inside a page with designMode="on" here: http://www.mister-pixel.com/ever/bugs/firefox/313582.html

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.
Status: UNCONFIRMED → NEW
Component: Editor → HTML: Parser
Ever confirmed: true
Flags: blocking1.9?
Keywords: crash, regression
OS: Windows XP → All
QA Contact: editor → parser
Hardware: PC → All
Posted file stack
Note theCount = 0 in nsParser::ParseFragment
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.
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/parser/htmlparser/src/nsParser.cpp&rev=3.403&root=/cvsroot&mark=1310,1433,1439,1447#1297

This fixes the first crash at least. I can't reproduce the second one.
Assignee: nobody → mats.palmgren
Status: NEW → ASSIGNED
Attachment #288830 - Flags: superreview?(mrbkap)
Attachment #288830 - Flags: review?(mrbkap)
The branch code looks almost the same but probably wouldn't crash in
a similar situation due to a wallpaper for bug 358797:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/parser/htmlparser/src/nsParser.cpp&rev=3.370.4.6&root=/cvsroot&mark=1886-1890#1845

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

Thanks.
Attachment #288830 - Flags: superreview?(mrbkap)
Attachment #288830 - Flags: superreview+
Attachment #288830 - Flags: review?(mrbkap)
Attachment #288830 - Flags: review+
Attachment #288830 - Flags: approval1.9?
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.
Version: unspecified → Trunk
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!
mozilla/parser/htmlparser/src/nsParser.cpp 	3.404 

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M10
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.