I've only seen this in FF 1.5 but from the look of it trunk should also crash in the same place sometimes. Steps to reproduce: 1. Install a "select" event handler on the tabbrowser element. 2. When the event fires - retrieve .contentWindow.controllers.getControllerForCommand or .contentWindow.pkcs11.addmodule (no need to call the methods). 3. Open a new tab. Typically the browser will crash trying to create a wrapper if you do that. Talkback incident ID is TB13992337Z (http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB13992337Z), there are also a few similar crashes: http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsDOMClassInfo%3A%3APreCreate It looks to me that the problem is here: if (piwin->IsOuterWindow()) { *parentObj = ((nsGlobalWindow *)piwin.get())-> GetCurrentInnerWindowInternal()->GetGlobalJSObject(); } GetCurrentInnerWindowInternal() returns null. The code should check for it, like this: if (piwin->IsOuterWindow()) { nsGlobalWindow *innerWin = ((nsGlobalWindow *)piwin.get())-> GetCurrentInnerWindowInternal(); if (innerWin) { *parentObj = innerWin->GetGlobalJSObject(); } } The crash is triggered by an extension but I'll try to make a simple testcase.

This testcase crashes Firefox 1.5 for me. In order for it to work it has to be opened it through the chrome: protocol, simply requesting privileges doesn't work. After opening pressing Ctrl-T (open a new tab) should crash the browser.

Is this still an issue? This seems to work for me, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060814 BonEcho/2.0b1

No, it doesn't crash for me either, so at least this situation isn't a problem any more. But the code I cited above is still in nsDOMClassInfo::PreCreate and missing a null-check so I would rather not close this bug - unless somebody explains why GetCurrentInnerWindowInternal() can't return null here.

Yeah, I found a case where it crashes, it depends on an extension, see bug 348990. Well, adding a null-check shouldn't be too hard, would it?

Got this on a FF trunk. TB22417120X Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060822 Minefield/3.0a1 ID:2006082204 [cairo]

(In reply to comment #5) > Got this on a FF trunk. With the testcase?

(In reply to comment #6) > (In reply to comment #5) > > Got this on a FF trunk. > > With the testcase? No, that's just a random crash while browsing. Also I got TB22422755K which happened when I kept pushing down the backspace key to go back the history, probably it accessed non-initilized things in skipping pages back. Bug 341784 is a dupe.

*** Bug 341784 has been marked as a duplicate of this bug. ***

The testcase is harmless for Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060823 Minefield/3.0a1 ID:2006082304 [cairo]

This seems to fix the crash I see in bug 348990.

And this is number 22 on the talkback crash list for FF2: http://talkback-public.mozilla.org/reports/firefox/FF2x/index.html And number 8 on the talkback crash list for FF1.5: http://talkback-public.mozilla.org/reports/firefox/FF15x/index.html So if this is the good patch and safe enough, I think it would make sense to land it also on the branches.

Johnny and I talked about this a week ago, and we didn't patch this then because we're not sure what the right behavior in this case is. In particular, we were worried about something being parented to the outer window when we weren't expecting it. Another option would be to call EnsureInnerWindow from this code.

Martijn, you didn't mean to assign this bug to me? I don't know the implications of this code well enough. Reassigning back to default assignee.

(In reply to comment #13) > Martijn, you didn't mean to assign this bug to me? Ok, sorry about that.

Like Blake said, this adding a null check here isn't the right fix for this problem, it might fix the crash, but it would leave us with JS objects parented at an outer window which is generally asking for security problems. Calling EnsureInnerWindow() from this code is definitely safer, but ideally we'd get a reproducible testcase so that we can investigate this further and get a better understanding of what actually triggers this and possibly fixing this in an even better way.

Comment on attachment 235107 [details] [diff] [review] suggested patch of comment 0 r-

Well, bug 348990 doesn't have a minimal testcase, but it has a reproducable way of getting this crash.

As a sidenote to comment #7 I've not got this bug since I uninstalled LiveHTTPHeaders.

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. So basically I ripped out the whole livehttpheaders extension, by emptying the chrome.manifest file. It is still crashing after that. Then I started minimising the nsHeaderInfo.js file, which is in the extension's components directory. The file I attached is the most minimised I could get it, while it is still crashing.

(In reply to comment #11) > And this is number 22 on the talkback crash list for FF2: > http://talkback-public.mozilla.org/reports/firefox/FF2x/index.html The problem with that link is that the numbers are so small that they are easily skewed by a single tester investigating a crash. On the just-released FF2b2 I wouldn't call this a topcrash (#120) http://talkback-public.mozilla.org/reports/firefox/FF2b2/FF2b2-topcrashers.html

(In reply to comment #20) > The problem with that link is that the numbers are so small that they are > easily skewed by a single tester investigating a crash. On the just-released > FF2b2 I wouldn't call this a topcrash (#120) > http://talkback-public.mozilla.org/reports/firefox/FF2b2/FF2b2-topcrashers.html In that case, I guess I could be responsible for this. I crashed a few times with the Firefox2.0 branch (not really sure how many times, I sent the talkback ID, though).

FWIW, only four unique users generated those 16 crashes (in the FF2x topcrash list).

Which is not to say we shouldn't worry about it. We did change wrappers on js components (bug 345991) which did seem to make the problem worse or more reproducable (bug 348990), and several extensions--not to mention Firefox itself--use js components.

Patch for bug 348990 will fix this. This is a regression from bug 296639.

Fixed by checkin for bug 348990.