See upcoming testcase, that I'll attach.
You need to let it run at least 5 seconds or so, to let it build up multiple alert dialogs.
After waiting, click them away.
At this point, I crash often (50% of the time).
I get backtraces with different signatures, so that's why I'm filing it as security sensitive.
Some talkback ID's width different signatures:
js_GetSlotThreadSafe JS_GetParent nsDOMClassInfo::WrapNative nsWindowSH::SetProperty XPC_WN_Helper_SetProperty js_SetProperty JS_SetUCProperty nsWindowSH::SetProperty XPC_WN_Helper_SetProperty js_SetProperty js_Interpret 0x0188ba40
nsGetInterface::operator() nsCOMPtr_base::assign_from_helper nsCOMPtr<nsIScriptGlobalObject>::nsCOMPtr<nsIScriptGlobalObject> nsLocationSH::PreCreate XPCWrappedNative::GetNewOrUsed XPCConvert::NativeInterface2JSObject nsXPConnect::WrapNative nsDOMClassInfo::WrapNative nsWindowSH::SetProperty XPC_WN_Helper_SetProperty js_SetProperty JS_SetUCProperty nsWindowSH::SetProperty XPC_WN_Helper_SetProperty js_SetProperty js_Interpret 0x0188c9e8
JS_GetParent nsDOMClassInfo::WrapNative nsWindowSH::SetProperty XPC_WN_Helper_SetProperty js_SetProperty JS_SetUCProperty nsWindowSH::SetProperty XPC_WN_Helper_SetProperty js_SetProperty js_Interpret 0x02080760
This seems to have regressed between 2005-08-01 and 2005-08-02:
I suspect bug 302889 might be the culprit.
Created attachment 221816 [details]
I even asked jst who marks the inner window's JS object yesterday ;-).
The answer to my question is that the inner window's JS object is rooted through the outer window's mInnerWindowHolder. This is usually enough keep the inner window alive, but nsWindowSH::SetProperty first calls SetHref() (which gives the outer window a new inner window, unrooting the inner window's global JS object) and then tries to use the inner window's global JS object to wrap the location object. Martijn's alerts allow a GC to nest in between and we access the inner window's collected JS object and crash.
Unfortunately, when I swapped the two calls (so that I wrapped the location object before the call to SetHref) I hit a JS assertion.
Blake's attempt to swap the order of changing the location and wrapping the location object does fix this problem and is IMO the right fix here. And now that the assertion is fixed (bug 364657), swapping the two calls is safe. Patch coming up.
Created attachment 250526 [details] [diff] [review]
Fix per mrbkap's comment.
Fixed on the trunk.
Comment on attachment 250526 [details] [diff] [review]
Fix per mrbkap's comment.
Approved for both branches branches, a=jay for drivers.
Fixed on the branches.
Testing with 126.96.36.199pre and the provided testcase still caused a crash.
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:188.8.131.52pre) Gecko/2007011103 BonEcho/184.108.40.206pre
Should the testcase no longer crash at all, or am I just looking for a 'secure' crash?
Hmm, the testcase should not crash at all. I wonder if there's other bugs that are causing a crash with the same testcase, maybe mac only? I've ran the testcase a *lot* with my fix and haven't seen a crash. Please re-test with another build and another platform too if you can and report back (and reopen the bug if it's still crashing for you). Oh, and talkback data would be useful too.
This is fixed for me, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11pre) Gecko/20070111 BonEcho/18.104.22.168pre
and current trunk build.
I'm on windows, so perhaps a Mac specific crash?
Created attachment 251291 [details]
mac crash report
Reproduced the crash on mac for 22.214.171.124pre. It was triggered after alternating clicking on the 'okay' button on the alert and the 'back' arrow on the browser - it was the combination of these two actions that caused the crash.
Ok, indeed, with the steps to reproduce in comment 12, I can too reproduce this crash on the latest branch build, talkback ID: TB28292905Y
Probably a new bug should be filed on that issue, so this bug can stay fixed then.
Now I have another issue. The testcase causes 126.96.36.199pre to hang. After running the testcase, having the alert raised, waiting 5 seconds and then clicking the alert the browser becomes unresponsive. Clicking on buttons has no effect - though I can command-Q to quit.
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:188.8.131.52pre) Gecko/20070111 Firefox/184.108.40.206pre
Ok, I have filed bug 367123 for the crash mentioned in commment 9 and further.
That crash is a different issue, because it has a different way of reproducing and has a different stacktrace.
The original bug is fixed on trunk and branches, this was verified by me and Alice.