Closed Bug 310409 Opened 19 years ago Closed 19 years ago

QuickLaunch reopens Navigator upon close

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: dsmutil, Assigned: mcsmurf)

References

Details

(Keywords: fixed-seamonkey1.1b, regression)

Attachments

(1 file)

Patch
1.85 KB, patch
neil
: review+
bzbarsky
: superreview+
csthomas
: approval-seamonkey1.1b+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050928 SeaMonkey/1.1a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050928 SeaMonkey/1.1a

Using the nightly build of SeaMonkey (2005092806), when Quick Launch is enabled
and I quit the application, it quits, relaunches, and opens a new window.

Reproducible: Always

Steps to Reproduce:




This nightly needs to be installed with the -greLocal flag because of bug 308838.
Also reproducible with SeaMonkey/20050929, maybe related to 'startup' bug 58523?
Also true for 2005093009 after fix of bug 308838.
I can't see this problem anymore with 20051013.
*** Bug 314040 has been marked as a duplicate of this bug. ***
It's back again, and has been at least for the last week; I've been trying builds every day in the hope that it will be fixed. My build today is 20051110009. Quicklaunch is one of my major reasons for prefering Seamonkey. 
This looks like a regression from brian.lu's patch for bug 58523.
I guess -turbo was relying on the buggy behaviour.
*** Bug 319147 has been marked as a duplicate of this bug. ***
Keywords: regression
*** Bug 320534 has been marked as a duplicate of this bug. ***
*** Bug 311712 has been marked as a duplicate of this bug. ***
*** Bug 320641 has been marked as a duplicate of this bug. ***
*** Bug 320691 has been marked as a duplicate of this bug. ***
Brian Lu: So do you plan to work on this here? If not, your patch might be backed out again since this is a regression which basically breaks a whole feature which seems to be used by somewhat many people (see dupe count).
Blocks: 58523
Behaviour has changed, but this Seamonkey Unique Selling Point is still broken. When I boot, I get two windows. Sometimes one is large, but not full screen, and one is just a fragment of title bar; sometimes they are both large; sometimes they  
are both the size of a large icon. My Home Page is about:blank, and the windows are always blank. I can close one, but if I close them both, I get one back the size of the one I close. However, if I display a page, and then I close it,  usually, rather than having the window open again, I get the dialogue that asks me if I want to choose a different profile. I can exit here, and Seamonkey then still seems to be running down in the status area of the tool bar, as I would have hoped. 
*** Bug 321425 has been marked as a duplicate of this bug. ***
Attached patch Patch — — Splinter Review 
This here fixes it, don't know if this fixes it the correct way so.
Attachment #206878 - Flags: review?(neil)
Attachment #206878 - Flags: review?(neil) → review?(neil.parkwaycc.co.uk)
(In reply to comment #15)
> Created an attachment (id=206878) [edit]
> Patch
> 
> This here fixes it, don't know if this fixes it the correct way so.
> 

**Where can this file be found locally?

You need to compile SeaMonkey yourself for that. Or just wait until this patch gets reviewed and checked in.
Attachment #206878 - Flags: review?(neil.parkwaycc.co.uk) → review+
Comment on attachment 206878 [details] [diff] [review]
Patch

I don't know if you can sr this code, reviewers are quite mixed for this code...
Attachment #206878 - Flags: superreview?(bzbarsky)
Comment on attachment 206878 [details] [diff] [review]
Patch

sr=bzbarsky, but please use the -p option when making diffs and use more context (cvs diff -up8 is good as a baseline).  What with lxr being down, that would have saved me at least 10 minutes right now.  :(
Attachment #206878 - Flags: superreview?(bzbarsky) → superreview+
Assignee: quicklaunch → bugzilla
checked in. brian.lu@sun.com: It'd be nice next time not to ignore regressions you caused for some months and then letting someone else fix it.

Checking in nsAppStartup.cpp;
/cvsroot/mozilla/xpfe/components/startup/src/nsAppStartup.cpp,v  <--  nsAppStartup.cpp
new revision: 1.9; previous revision: 1.8
done
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Thanks to all for tracking this down and fixing it.

I do notice a behaviour change and wanted to ask if it was intentional. Before this bug initially started, when all Seamonkey windows were closed, it appeared to force Seamonkey into a full restart (i.e., the app terminated itself, the system tray icon disappeared and reappeared).

Now, it appears that when the all Seamonkey windows are closed, it just remains in memory and continues on.

Was this change intentional? I kind of liked the old behaviour since it gave Seamonkey a fresh start and was a quick way to free memory up, etc.
I did not observe that behaviour while testing the patch. However, there are some people who would like SeaMonkey to continue to check their mail while minimized to the tray. If this behaviour is reproducible then maybe we'll discover the cause which will allow us to provide a preference for it ;-)
I just re-read my comment and wanted to be sure I was clear (enough), the old Seamonkey behaviour DID restart the app, it just closed it out completely before then restarting it (and it would launch to the tray-- this bug started when that restart caused Seamonkey to fully launch AND bring up the new window). Would the restart cause it to stop checking mail in the tray?

It WOULD be nice to have a "close all windows restarts Seamonkey to tray" option, although I don't know how to explain that in a UI perspective that wouldn't cause confusion. (as opposed to "close all windows does nothing and leaves Seamonkey in tray")

[Please forgive my tone and line of questioning as I am just a power user now after being force to stop coding due to severe carpal tunnel, thoracic outlet, tendinitis and complex regional pain conditions due to coding and other extensive labor. -Bruce]

I can't understand why this is considered RESOLVED/FIXED when it is obviously misbehaving.  This has worked perfectly fine in the standard Mozilla Suite for nearly a decade.  What/how/why is it so different here all of a sudden like all is forgotten?  Am I getting this wrong?

My current version Gecko/20051225 SeaMonkey/1.5a just restarts a whole new instance of navigator once I closed all the windows with Quick Launch activated.
Is this the recent version with the patch in it?  If not, where to place the patch, please?

I recommend that the status be placed as REOPENED until it is fixed.
This bug is truly so very annoying and causes people who have severe pain conditions additional button clicks and keyboard that causes more pain and discomfort.  The idea is ease, not dis-ease.

Thank you for listening.

Respectfully,
Bruce Wolfe, MSW
===


(In reply to comment #23)
> I just re-read my comment and wanted to be sure I was clear (enough), the old
> Seamonkey behaviour DID restart the app, it just closed it out completely
> before then restarting it (and it would launch to the tray-- this bug started
> when that restart caused Seamonkey to fully launch AND bring up the new
> window). Would the restart cause it to stop checking mail in the tray?
> 
> It WOULD be nice to have a "close all windows restarts Seamonkey to tray"
> option, although I don't know how to explain that in a UI perspective that
> wouldn't cause confusion. (as opposed to "close all windows does nothing and
> leaves Seamonkey in tray")
> 


It wasn't fixed (in the executables) til 2005122808 (or maybe an earlier build on the 28th). Re-download a new nightly and at least the re-opening of the window is fixed. I'm just asking about how it now handles all windows being closed, perhaps you could offer your comments on a newer build?
FIXED now.  
All is well, all is nigh.

Bruce
==


(In reply to comment #25)
> It wasn't fixed (in the executables) til 2005122808 (or maybe an earlier build
> on the 28th). Re-download a new nightly and at least the re-opening of the
> window is fixed. I'm just asking about how it now handles all windows being
> closed, perhaps you could offer your comments on a newer build?
> 
Yeah it looks like it does not restart itself anymore when all windows are closed. I can try to look into this, but if someone else can pull up a patch for this, it's ok, too.
Ok some new info: It seems the new behaviour that it not restarts was (is?!) actually correct a few month/years ago. This was added between Mozilla 1.0 and Mozilla 1.1 in the Release Notes:
When you close the last window, Mozilla will unload itself and reload itself this may take a while. This will probably result in lots of disk thrashing. (Bug 143764)
So it seems the behaviour before this patch was "wrong", but i cannot say for sure since that Bug was just resolved wfm. But i found Bug 146340, which points to Bug 98673 which might have caused that new behaviour...
Yes, due to bug 143764, but also bug 98673, it is supposed to completely restart when the last window was closed, and the reopening of the navigator window which this bug was reporting was due to the failure of bug 58523 to handle that case.
So does that mean the bug needs to be re-opened for the patch's behaviour to be adjusted?
By my testing the patch works as advertised, i.e. 1.1 - 1.7 behaviour.

Although it might be possible that some obscure combination of preferences results in an alternate behaviour that is outside the scope of this bug.
Verified FIXED using trunk SeaMonkey 1.5a;Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060104 Mozilla/1.0.

This verification covers the regression behavior outlined in this bug only; any and all other bugs should be filed separately, thanks.
Status: RESOLVED → VERIFIED
Switching component to get the right flag...
Component: QuickLaunch (AKA turbo mode) → XP Apps
Product: Core → Mozilla Application Suite
Attachment #206878 - Flags: approval-seamonkey1.1b?
Attachment #206878 - Flags: approval-seamonkey1.1b? → approval-seamonkey1.1b+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: