Closed Bug 68766 Opened 24 years ago Closed 24 years ago

Closing all windows causes Mozilla stop responding

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
PowerPC
Mac System 9.x
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: mikepinkerton)

References

Details

If you close all windows in Mozilla, you cannot do anything. By anything: I mean use any menus or any hotkeys. Steps to reproduce involve: 1) start mozilla 2) close the window that appears
This error exists on build 2001021314 it does not exist on build 2001021308
could this be a result of the carbon carpool?
Seems almost like it has to be a result of the carbon carpool, this had to be broken after the 8 AM build, but before the 2 PM build. Doesn't seem like any of the other checkins in the time frame could have done this...
I would only expect this to happen if the Carbon build were turned on by default. Is it? Otherwise, none of the old menu code was touched.
*** Bug 69512 has been marked as a duplicate of this bug. ***
*** Bug 69597 has been marked as a duplicate of this bug. ***
*** Bug 69821 has been marked as a duplicate of this bug. ***
So, does this go to XPApps or XPToolkit (anything to get it out of browser general so it gets taken care of)?
beard's landing did this...
Assignee: asa → beard
QA Contact: doronr → asa
Been happening for a while in the carbon builds under OSX PB the Jan 3 build was doing it, I can't remember about any previous to that. Becasue OSX has the quit option in that extra menu, it's possible to close it. (I guess I never got around to reporting that bug, sorry)
*** Bug 69983 has been marked as a duplicate of this bug. ***
Mozilla seems to respond to apple events. Once all the windows are closed, drag and drop a text file on the Mozilla icon. Mozilla will open a new window, display the file and start responding to menus and hotkeys again.
I looked at this tonight and the code that calls MenuSelect attempts to dispatch this to the window that is returned by ::FrontWindow(). In my debug build, this window is the SIOUX console window, so it can't process the menu command. I'll bet something went in that alters the window ordering. Does this problem occur in an optimized build?
Status: NEW → ASSIGNED
yes, this happens in optimized builds.
*** Bug 70199 has been marked as a duplicate of this bug. ***
i found the regression, taking it over. i'll fix on the trunk, an open a new bug so we can deal with the carbon issues.
Assignee: beard → pinkerton
Status: ASSIGNED → NEW
see bug http://bugzilla.mozilla.org/show_bug.cgi?id=70388 for a discussion of the issues for carbon. fix checked in to return classic to normalcy when no windows are visible.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 70461 has been marked as a duplicate of this bug. ***
With my debug build pulled and built this morning as well as the 2001-04-09-08 build from sweetlou, this problem is back.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
this bug covers the breakage from the carbon carpool, which was fixed. saari has a bug to cover the recent regressions. reclosing as fixed.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
For those wondering, Saari's bug is bug 74499.
As original reporter, I've neglected my duty to mark this puppy as verified. Fixing that.
Status: RESOLVED → VERIFIED
FYI, the newer, still-open bug 130891 reports continuing failure of certain menu items to function with no windows open.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.