I am able to crash Mozilla pretty reliably when I am loading GMail and suddenly going offline. I can reproduce it on 1.8.0.x, 1.8.1 and trunk branch. But it only happens in combination with the livehttp headers extension: http://livehttpheaders.mozdev.org/installation.html To reproduce: - Install live http headers extension, restart - Load gmail.com (you need to have an account an be logged in) - Suddenly go offline (by using File->Work Offline) - Press reload a couple of times Result: crash It seems to be timing dependant. It seems you need to go offline when the back button gets activated (when you are able to press back). Talkback ID: TB22184979X nsDOMClassInfo::PreCreate XPCWrappedNative::GetNewOrUsed XPCConvert::NativeInterface2JSObject XPCConvert::NativeData2JS XPCWrappedNative::CallMethod This might very well be the same bug as bug 323641. Marking a dependancy on that bug.

Better way to reproduce (you still need Live http headers installed): - Load Gmail - Go offline - Press the back button - Press reload a couple of times

From talkback ID: 22767488 Tryed to download FlashFxp from download.com. Reproducible: always. click on the "download now" link: http://www.download.com/FlashFXP/3000-2160-10037696.html?part=dl-FlashFXP&subj=dl&tag=button Indeed, this always crashes for me when clicking on the download now link, so this is a much more reliable way of crashing with the livehttpheaders extension.

Was this a regression shortly before you filed it? I see nsDOMClassInfo::PreCreate crashes starting to appear in Firefox2 (1.8 branch) talkback on 2006-08-08 (although at an average rate around 1 per day, so hard to tell exactly). The user comments and the stack signature below the top seem a bit similar to bug 317283.

(In reply to comment #3) > Was this a regression shortly before you filed it? Yeah, apparently it is (although 1.8.7pre branch also crashes for me). The regression range I get for both trunk and 1.8 branch is between 2006-07-27 and 2006-07-28. Bonsai link trunk: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-07-27+05&maxdate=2006-07-28+06&cvsroot=%2Fcvsroot Bonsai link 1.8 branch: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-07-27+06&maxdate=2006-07-28+06&cvsroot=%2Fcvsroot The patch for bug 345991 was checked in that day on 1.8 branch and on trunk. The patch was also checked in on 1.8.0.x branch, so that could explain why my 1.8.0.7pre (2006-08-24) branch build is also crashing.

I'm adding topcrash, although it's a little borderline for "top".

I just verified in my debug trunk build that backing out the patch from bug 345991 does fix the crash.

Too late for 1.5.0.7, but nominating for 1.5.0.8 and adding regression keyword. Let's try to get a handle on this for the next release. Backing out bug 345991 has been suggested, but I wonder if there is a better way... If people think this is a common enough case, we could relnote it.

Jay, this is a topcrash regression on the 1.8.0.x branch. In my opinion we should hold 1.8.0.7 for fixing this one way or another; worst-case we do back out bug 345991. I plan to spend tonight working on this in hopes of finding something better. Note that I think that unlike security fixes for old problems (which I can understand slipping to the next security release if we want to release on a regular cycle), regressions should NOT get slipped once found; otherwise people will be afraid to update to the security releases we make...

Probably not really a topcrash -- it's 42 crashes across 14 users in Firefox2 nightlies (including the Fx2b2 release, although only a few there; most of the spike in nightlies has been since then).

Boris, I can't see any [@ nsDOMClassInfo::PreCreate] crashes listed at the firefox 1.5.0.6 talkback analysis page: http://talkback-public.mozilla.org/reports/firefox/FF1506/index.html

This fixes the bug for me. When splitwindow landed, there was code added to ensure inner windows for gets. This code wasn't on for XPCNativeWrappers, however. All this patch does is give XPCNativeWrapper parity with the raw Window object in terms of whether we force creation of an inner. We continue to not forward the get to the inner in the XPCNativeWrapper case. This fixes bug 323641 (where we always had an XPCNativeWrapper because we were performing a content access from chrome) and this bug (where we started getting an XPCNativeWrapper because of bug 345991).

Comment on attachment 237036 [details] [diff] [review] Proposed fix r+sr=jst

Fixed on trunk.

Comment on attachment 237036 [details] [diff] [review] Proposed fix Requesting branch approvals. I think this should be quite safe.

Comment on attachment 237036 [details] [diff] [review] Proposed fix Approved for 1.8.0 branch, a=jay for drivers. Please land this ASAP.

Fixed on the 1.8.0 branch for 1.8.0.7. Thanks for the speedy reviews and approvals!

Comment on attachment 237036 [details] [diff] [review] Proposed fix a=beltzner on behalf of 181drivers

Fixed on 1.8.1 branch.