Open Bug 34151 Opened 24 years ago Updated 2 years ago

When closing windows on quit, should close in front-to-back order

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

Future

People

(Reporter: sfraser_bugs, Unassigned)

References

Details

(Keywords: helpwanted)

If you have > 1 window open, one or more of which are composer windows, then the 
window layering changes as windows are closed on quit.

For example, do the following:
1. Launch, see 1 browser window come up.
2. Choose Composer on the tasks menu, get a composer window up. Type in it (to 
make it dirty).
3. Click on the browser window to bring it to the front.
4. Quit.

Note how the composer window, which was in the back, is brought to the front, 
then the 'do you want to save dialog is shown'. This looks weird (especially when 
you have several composer windows up, and their order seems to change randomly 
(creation order??) during this time).

Windows should be closed in front-to-back order, and if a window needs to pose a 
'do you want to save' dialog, then that should be shown when it's this window's 
turn to be closed. This is the way that every other Mac app I know works.
Give you a better summary.
Summary: When closing windows on quit, window ordering changes weirdly → When closing windows on quit, should close in front-to-back order
Status: NEW → ASSIGNED
Target Milestone: --- → M19
mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-
Target Milestone: M19 → M21
Target Milestone: M21 → Future
I'll take this, and fix it when I check in nsIWindowMeditor Z-order iteration.
Assignee: danm → sfraser
Status: ASSIGNED → NEW
Target Milestone: Future → M19
moving to future, just can't get to this one
Keywords: helpwanted
Target Milestone: M19 → Future
This applies to Windows too.
[--> All/All based on Brian's comments]
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Giving this back to danm.
Assignee: sfraser → danm
Target Milestone: Future → ---
->future
Target Milestone: --- → Future
Blocks: 115897
No longer blocks: 115897
*** Bug 115897 has been marked as a duplicate of this bug. ***
*** Bug 103072 has been marked as a duplicate of this bug. ***
Not that it matters much because this bug is over 2 years old, but it is
still a problem at V1.0 RC2. I'm testing OpenVMS build 20020513
Assignee: danm.moz → nobody
Blocks: 182417
is there a spec for how this should work on windows, and if there isn't does the order matter?

IMO it's a good thing if windows which require response are handled )and might get a reponse of cancel) before other windows are closed.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4
Assignee: nobody → jag
Severity: normal → minor
QA Contact: jrgmorrison → xptoolkit.widgets
Assignee: jag → nobody
No longer blocks: 182417
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.