393652 - Trunk builds on Mac do not quit from menu after first window is closed

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Franklin Bynum]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007082404 Minefield/3.0a8pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007082404 Minefield/3.0a8pre

Trunk builds do not respond to Apple-Q or File-Quit when no window is open.

Reproducible: Always

Steps to Reproduce:
1. Open trunk version of Minefield.app
2. Close browser window
3. Go to File-> Quit or hit Control-Q
Actual Results:  
Minefield does not quit

Expected Results:  
Minefield should quit

Sometimes with a browser window open, File-Quit or Control-Q will hang Minefield, but I can't reproduce this.

Comment 1

[Franklin Bynum]

When upgrading to today's build (2007082504) just now via Software Update, the "restart and apply update" option would not quit the application.  I had to force quit the app, then manually relaunch.  The update applied successfully, though, and this bug still appears in today's build.

Comment 2

[philippe (part-time)]

Confirmed with the 2007082514 build.

Frank, do you have any idea when this regressed ?

Comment 3

[Gonzalo HIGUERA DÍAZ]

The 2007082304 (2007-08-23-04-trunk) build does not have this problem, but the next build (2007082404) does.

Comment 4

[Dave Townsend [:mossop]]

I cannot quit the application from the menu even when windows are visible

Comment 5

[Dave Townsend [:mossop]]

Actually, the menu appears to work when first launched, but after you close the window it stops working and doesn't start working even when opening a window again. No errors in the error console.

Comment 6

[philippe (part-time)]

Based on comment 3
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=2007-08-23+03%3A00%3A00&maxdate=2007-08-24+03%3A00%3A00&cvsroot=%2Fcvsroot

bug 372453 sounds suspicious

Comment 7

[Dave Townsend [:mossop]]

Yeah, more accurate range is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1187901420&maxdate=1187905259

Comment 8

[:Gijs (out for now; he/him)]

This is a toolkit bug, really...

Comment 9

[:Gijs (out for now; he/him)]

Attachment: Patch

This patch works for me.

The problem was that the mShuttingDown flag gets raised before the relevant code on mac, and then when it decides not to quit after all, it doesn't get set back to PR_FALSE. Then when another shutdown is attempted (ie, the user clicks "Quit" in the menu, hits Cmd+Q, etc.) the flag is still there and the Quit procedure returns early. Fixing this by moving the setting of this flag to after the code I added, so that if we return early, the flag is not set yet.

Comment 10

[Colin Barrett [:cbarrett]]

This is a really, really really annoying bug. I hit it all the time while working. If the review is going to take a while, should we back out the original patch?

Comment 11

[:Gijs (out for now; he/him)]

Checking in mozilla/toolkit/components/startup/src/nsAppStartup.cpp;
/cvsroot/mozilla/toolkit/components/startup/src/nsAppStartup.cpp,v  <--  nsAppStartup.cpp
new revision: 1.19; previous revision: 1.18
done

Comment 12

[Boris Zbarsky [:bzbarsky]]

So... this was a problem before this patch too, but 

+      mRestart = aMode & eRestart;

is bogus.  mRestart is a PRPackedBool, and you're assigning either 0 or 0x10 into it.  The latter is not a valid value for a PRPackedBool.  You want a "!= 0" or something tossed in there.

Comment 13

[:Gijs (out for now; he/him)]

(In reply to comment #12)
> So... this was a problem before this patch too, but 
> 
> +      mRestart = aMode & eRestart;
> 
> is bogus.  mRestart is a PRPackedBool, and you're assigning either 0 or 0x10
> into it.  The latter is not a valid value for a PRPackedBool.  You want a "!=
> 0" or something tossed in there.
> 

Bug 394629 filed.