477437 - crash with greasemonkey, xhr, and setting innerHTML property on document fragments [@ nsWrapperCache::PreserveWrapper() ]

Status: RESOLVED DUPLICATE of bug 480975

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

Description

[Jonathan Chang]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.48 Safari/525.19
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090207 Minefield/3.2a1pre

A greasemonkey script adds an onclick event handler to a link. This handler requests a second page using GM_xmlhttpRequest and calls the callback for the function. This callback uses the response data and creates a document fragment, setting some of the response data to the innerHTML property of the document fragment. Firefox then crashes at this point.

Reproducible: Always

Steps to Reproduce:
1. Install the provided Greasemonkey script
2. Go to the test URL above
3. Click the link
Actual Results:  
Firefox crashes

Expected Results:  
Firefox not crashing

Crash ID: 78907a19-5dd2-491a-809d-c0e162090207
Installed extensions: Greasemonkey 0.8.20080609.0

Comment 1

[Jonathan Chang]

Attachment: greasemonkey script

Download this

Comment 2

[Jonathan Chang]

http://no-jons.com/first.html test url here

I haven't been able to reduce the test case any further; apparently this requires some weird interaction with greasemonkey, XHRs, and document fragments. Setting the innerHTML property on the document fragment works as expected (and doesn't crash) in a greasemonkey script, just not in this instance

Comment 3

[Dave Garrett]

Confirmed on WinXP and Linux.
bp-b32972f3-6aea-444d-b09a-fb45c2090207
0  	libxul.so  	nsWrapperCache::PreserveWrapper  	nsWrapperCache.h:104
1 	libxul.so 	nsDOMClassInfo::PreserveNodeWrapper 	dom/src/base/nsDOMClassInfo.cpp:4249
2 	libxul.so 	nsJSContext::PreserveWrapper 	dom/src/base/nsJSEnvironment.cpp:3396
3 	libxul.so 	XPCWrapper::MaybePreserveWrapper 	js/src/xpconnect/src/XPCWrapper.h:202
4 	libxul.so 	XPCWrapper::ResolveNativeProperty 	js/src/xpconnect/src/XPCWrapper.cpp:478
5 	libxul.so 	XPC_NW_NewResolve 	js/src/xpconnect/src/XPCNativeWrapper.cpp:713
6 	libmozjs.so 	js_LookupPropertyWithFlags 	js/src/jsobj.cpp:3621
7 	libmozjs.so 	js_SetPropertyHelper 	js/src/jsobj.cpp:4070
8 	libmozjs.so 	js_Interpret 	js/src/jsinterp.cpp:4634
9 	libmozjs.so 	js_Invoke 	js/src/jsinvoke.cpp:1334
10 	libmozjs.so 	js_InternalInvoke 	js/src/jsinterp.cpp:1392
11 	libmozjs.so 	JS_CallFunctionValue 	js/src/jsapi.cpp:5299
12 	libxul.so 	nsJSContext::CallEventHandler 	dom/src/base/nsJSEnvironment.cpp:1997
13 	libxul.so 	nsGlobalWindow::RunTimeout 	dom/src/base/nsGlobalWindow.cpp:7661
14 	libxul.so 	nsGlobalWindow::TimerCallback 	dom/src/base/nsGlobalWindow.cpp:7993
15 	libxul.so 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:428
16 	libxul.so 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:520
17 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:510
18 	libxul.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:230
19 	libxul.so 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:170
20 	libxul.so 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:192
21 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3216
22 	firefox-bin 	main 	browser/app/nsBrowserApp.cpp:156
23 	libc-2.7.so 	libc-2.7.so@0x1644f 	

I had to right-click->"open in new tab" to get the page to open. Error console gets this on clicking the test URL link in comment 2:
Error: quotedtext is null
Source File: file:///C:/Documents%20and%20Settings/User/Application%20Data/Mozilla/Firefox/Profiles/o330agfw.default/extensions/%7Be4a8a97b-f2ed-450b-b12d-ee082ba24781%7D/components/greasemonkey.js
Line: 390

Comment 4

[Dave Garrett]

Also crashes 3.1b3pre but doesn't work in 3.0.6.

Comment 5

[Jonathan Chang]

Thanks for verifying. Regarding having to open the link in a new tab (comment 3): The greasemonkey script's behavior is intended to override the default action for clicking the link

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

Has anybody seen this crash since bug 480975 was checked in?

Comment 7

[Dave Garrett]

(In reply to comment #6)
> Has anybody seen this crash since bug 480975 was checked in?

I can't reproduce this anymore with latest 3.6a1pre. 3.5b4pre still crashes.

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

I'm going to mark this as a dupe then. This will be fixed on the 1.9.1 branch when bug 484692 is checked into that branch.