399065 - Firefox crashes when pop-up window is closed via self.close() or window close button (red X)

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Mark Pemburn]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

A child window is opened using Javascript window.open(). When this window is closed using either the OS'es red X button or call to Javascript self.close().  This is not universally true -- some factor in the test code (in the example URL) is doubtless responsible.  (I will be spending some time isolating this factor -- it's killing my app and I want it to stop!)

BTW: I've tested this with Windows and it does not cause crash.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.pemburn.com/poptest/index.html
2. Click the "Edit" button
3. When window pops up, close it with "Cancel" button
Actual Results:  
Firefox crashes

Expected Results:  
Window should close

Comment 1

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100805 Minefield/3.0a9pre ID:2007100805

WFM

Comment 2

[Mark Pemburn]

Aha! Just discovered that the function called by the body "onUnload" event contains a call to "self.focus()".  Dumb, I know.  Still, this should not cause a browser crash.

Comment 3

[Jesse Ruderman]

It doesn't crash for me, using Firefox 2.0.0.7 on Tiger (Intel).

Can you attach a stack trace or give a talkback ID?  You should be able to pull a stack trace out of ~/Library/Logs/CrashReporter/firefox-bin.crash.log (the newest crash will be at the bottom).

Comment 4

[Mark Pemburn]

Okay -- log is at: http://www.pemburn.com/poptest/firefox-bin.crash.log

I have no idea what any of it means so it probably contains redundant or irrelevant data . . . however: I did notice that it referred to "PPC" and when I looked in the Mac Activity Monitor, I was shocked to discover that Firefox is running as a PowerPC app under Rosetta!  I had never noticed this before.  Is there no Intel version?

BTW: I should have mentioned -- I also have an old eMac that is, of course, a PowerPC.  I've tested this bug on that machine and it crashes there as well.

Is there any possibility that plug-ins installed on Firefox could affect this in any way (I wouldn't think so but I've been a software developer for over 20 years and you'd be surprised at the unlikely bugs I've found).  On both of my Macs I have the FireFTP plug-in loaded and I have FireBug loaded on my main machine (the latest version of MacBook).  

Comment 5

[Jesse Ruderman]

The stack traces in your log that don't have "Rosetta: Yes" mostly show the crash as being [@ TestWindowGroupAttributes].  Bug 388181 was reported as having the same signature, so hopefully the fix there will fix your crash too.  That patch was checked in on the branch for Firefox 2.0.0.8.  You can test a branch nightly from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/ to make sure it's fixed for you.

As for why Firefox is (sometimes?!) running under Rosetta, I have no clue.  Based on the crash log, it looks like the same thing was happening for you a month ago with Firefox 2.0.0.6: sometimes Rosetta, sometimes native.

Firefox 2.0.0.7 is shipped as a universal binary, so it *can* run under Rosetta (by loading the PPC section), but it should prefer to load the Intel section.  Try doing a "Get Info" on Firefox in your Applications folder.  Make sure it says "Kind: Application (Universal)" at the top and make sure the "Open using Rosetta" checkbox (just under the color labels) is unchecked.

Comment 6

[Mark Pemburn]

Downloaded "Bon Echo" (??) and tried my bug test.  It passed with flying colors!  I notice that it runs as native Intel.  Checked "Get Info" for Firefox as you suggested and it does list it as Universal.  Quit Bon Echo and went back to Fireox 2.0.0.7.  It did what looked like an update process (checked add-ins, etc). Still says "PowerPC", despite.  I haven't checked the again bug yet but I will as soon as I post this.

Comment 7

[Mark Pemburn]

Minutes later . . . Tested again w/Firefox 2.0.0.7 and the bug persists.  So, I'm guessing that when the 2.0.0.8 release becomes official, I'll be notified and the software will automatically update.  In the meantime, I've isolated a stupid coding error and eliminated it.  Thanks!

Comment 8

[Jesse Ruderman]

Ok, I'll mark this as FIXED by the patch in bug 388181.

"Bon Echo" was the codename for Firefox 2, and it's the name builds from that branch use to distinguish themselves from Firefox release builds.

Can you file a new bug report on the "Firefox mysteriously starts under Rosetta" issue?  That sounds kinda bad, and it would be nice to figure out why (or at least have something to compare to if someone else has  a similar problem).

Comment 9

[Mark Pemburn]

Will do.  It may take me a few days -- I have to make up for the time that figuring out _this_ bug cost me first.  Thanks!

Comment 10

[Carsten Book [:Tomcat]]

verified fixed 1.8.1.8 using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-JP-mac; rv:1.8.1.8) Gecko/2007100816 Firefox/2.0.0.8 - no crash on steps to reproduce

- Adding verified keyword