Closed Bug 146340 Opened 23 years ago Closed 17 years ago

quick launch icon disappears for a second after closing last window

Categories

(Core Graveyard :: QuickLaunch (AKA turbo mode), defect)

Product:
Core Graveyard
Component:
QuickLaunch (AKA turbo mode)
Version:
1.8 Branch
Platform:
x86
Windows 95
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file)

Win32 interprocess shared memory code
1.68 KB, application/octet-stream
Details
When I close the last Mozilla window, the Quick Launch icon disappears and then comes back a second later. This is a recent regression: it worked in 051908 but this bug appears in 052208.
reproduceable using trunk builds for 519 and 522 as noted 519 build, multiple profiles, QuickLaunch icon appears and remains after file/exit. double click on icon, brings up ProfileManager and you may select new profile 522 build, same profiles, QuickLaunch icon appears - when you file/exit, it disappears and reappears.
*** Bug 146444 has been marked as a duplicate of this bug. ***
Possibly related bug: double-clicking on quick launch icon just after the icon reappears causes a crash (TB6647205G).
*** Bug 147254 has been marked as a duplicate of this bug. ***
Blocks: 147254
This is a side-affect of the new turbo model (see bug 98673). Not much we can do about it.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
That doesn't indicate a wontfix resolution though. reopen, ->future
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Target Milestone: --- → Future
The only problem with not fixing it is that it leads to some bugs in modules like Download Manager (see dependancy Bug 147254) and causes weird XPI behaviour (tricks Moz into thinking it was closed).
Blocks: 147223
*** Bug 148631 has been marked as a duplicate of this bug. ***
*** Bug 153394 has been marked as a duplicate of this bug. ***
Note that at least on my system this produces the undesirable behavior of stopping mail checking. IE, if you have the mail component set to check your account every 10 minutes and close the mail window, but have a browser window open, it will still check the mail and report new mail. However, if you close that browser window, quicklaunch "restarts", and it stops checking for new mail until you open mail/news and enter your master password again. It's annoying enough to me that I'd like to find a solution, anyway. ;)
Comment #10 is another side effect of the new turbo model -- see bug 98673. It has nothing to do with this bug report however. Even if the icon didn't disappear momentarily (perhaps by delaying the removal of the icon for a few seconds), the symptom described in comment 10 would still occur. Furthermore, the behavior experienced in comment 10 is the correct behavior. If we didn't have turbo mode active, and the user shutdown all windows, then mailchecking will certainly stop. The fact that turbo is present should be transparent to the user, except for the faster startup.
It may be the "correct" behavior for the new turbo mode (which is still called "quicklaunch" in the prefs), but it certainly does change the expected behavior from 1.0, where as long as you had mozilla in the system tray it would continue to check your e-mail. At the very least it's confusing to previous users, but I'll agree that this probably isn't the domain of this bug and should be brought up elsewhere. Question is, which bug does this concern fall under, or should I open a new one?
I use 1.0 and I expect Mozilla to STOP checking my e-mail if I've closed all my windows. I believe this is the intended and actual behavior in 1.0. If that weren't the case, I'd say it were a bug. When you close all your Mozilla windows, you've effectively exited the app.
Open a new one.
First, re: comment #13, I believe the standard behavior of most (if not all) windows apps is that the application continues to perform its background tasks while in the system tray, regardless of if there's any windows open. This is really what I see as the problem described in bug 147254 too: people expect the download manager to keep functioning even if the window is closed because Mozilla is running and active in the system tray. In any event, I've opened bug 155444 to deal with the specific mail checking issue.
I have a slow computer with limited memory. I use turbo mode because I want to easily reopen Moz even after I close the last window. But this reloading of the quick launch uses so much system resources that everything on my computer slows down after that. As a workaround, I keep one blank window open and minimized on the taskbar. I shouldn't have to do this because that is what Quick Launch is supposed to be for. Bug 98673 says the reloading should free up resources, but that is not what I experienced. I see my computer slowing down after the reload.
I agree with the previous comment about using extra resources. This 'exiting and reappearing' thing is not good at all, as far as I'm concerned. Of course, I had no problem with Moz eating 40MB while in turbo mode, as I have 512MB. But, this restarting of QuickLaunch is worse, as it takes actual CPU time to restart. Please find a different workaround. That's my pennies, -bZj
I can confirm this on 1.1beta. The whole point of quicklaunch is that you can quickly open a window after you close the last mozilla window. With this current regression it takes about three seconds on my pc before I can do anything with quicklaunch (like close it to enable some newly installed stuff). It almost looks like mozilla is relaunching itself entirely!
The relaunching also clears the master password, so you have to re-enter it to get saved usernames/passwords. My expectation of the quick launch feature is that it keeps the master password unlocked and continues checking mail until I deliberately close the systray icon. This is a very standard behavior for most other Windows programs, and I don't see a compelling reason for Mozilla to deviate from this standard.
Here are several comments: 1. This affects all versions of Windows so shouldn't OS=Win95, or even OS=ALL? 2. The fact that the icon disappears is disconcerted, yes, but not really the point. Instead, the point seems to be that the recent changes to QuickLaunch (to fix memory-usage problems) work by resetting the whole Mozilla environment. Unless there's a way to "properly" fix memory-use (on-the-fly and as-needed) then we need to patch the reset process so that everything else doesn't reset/break. At the very least, I suggest changing the summary, e.g. "closing last browser window causes delay in QuickLaunch, breaks mail, etc" Personally, my biggest concern is the delay as Mozilla/QuickLaunch unloads then reloads.
w95. this bug is a mozilla-w32 bug which does not occur on most other platforms since most platforms have no turbo/quicklaunch functionality at all.
OS: Windows XP → Windows 95
Eric, this is not proper behaviour. As Morse indicated, in his words, "The fact that turbo is present should be transparent to the user, except for the faster startup." In addition, as a response to Tony, there are patches being prepared to deal with the dissappearing to make the UI more appealing. Eventually the pause will be lesser when some perf issues are worked on.
Shark: This may not be the Mozilla team's intended behavior, but as we've seen in the traffic on this bug, it is the behavior expected by Windows users. If something is left running in the system tray, it's expected that the program keeps running without interruptions or resets. Even applications which don't reside in the system tray but are still resident in memory (*cough* IE *cough*) keep your settings and passwords open when all windows are closed. There should be very compelling reasons to deviate from this platform standard specifically for your application, especially when the standard provides useful features to the user.
What per-session setting does IE keep after a window close? Only elements of it's rendering engine and some small extras are still in RAM. If we were to implement this, not only would it deviate from intended Mozilla behaviour, but it would also require more annoying Windows-only code (not that Mozilla doesn't have a lot already). Think of it this way: If we didn't have a quicklaunch systray icon, would you expect the same? We act like IE but with a systray icon.
AFAIK IE will keep your opened saved passwords, even if all browser windows are closed, which is something Mozilla doesn't do. I guess my problem is simply what your question raised: if there was no system tray icon, I'd expect what we're currently getting with Mozilla. However, with the system tray icon, I expect Mozilla to do what every other Windows program does. Inconsistency is bad. And, I think that if we're duplicating IE behavior we have to duplicate Outlook behavior as well, since Mozilla should replace both. However, simply removing the system tray icon from Mozilla doesn't solve the bigger issue, IMHO. Having the program stay resident in the system tray checking your e-mail is pretty much a required feature, as in the pre-quicklaunch days I could not convince a single user at my work or a single one of my friends to switch from Outlook to Mozilla because that feature was missing. These are not technically uneducated people, they understood the advantages of using Mozilla quite clearly, but they'd rather use something terribly insecure that spreads virii than something that was incovenient. And now, with the way this new Turbo feature works (which most people I think don't understand is a deviation from the way Quicklaunch used to work), these same people are coming and saying they're dropping Mozilla and going back IE/Outlook, because it's buggy and it isn't working properly... and I've discovered what they mean is that it doesn't keep the master password unlocked and checking e-mail when all their windows are closed. Honestly, the lack of a persistent mail checker in the system tray is what I've seen as the largest impediment to Mozilla adoption. Mozilla surpases IE in everything else at this point, and is getting better every day, but users are simply not willing to switch away from something that's more convenient, and will in fact switch back if the better engineered software becomes less convenient. I figure we should at least have an option for Mozilla to be able to have persistent mail checking, since its obviously in demand, and I don't see Mozilla being able to compete as a mail client without it. Maybe if you could minimize the Mail window to the system tray instead of the taskbar, and remove the system tray icon when just doing Turbo mode. This would (I think) resolve the inconsistencies with having the system tray icon how it is now, and also let people keep the mail client open in the system tray like they want to.
The lack of a persistent mail checker is a deal breaker for me, as is the inability to keep the master password unlocked. There are many times when I don't have web or mail window open, but I still want to receive notifications. I understand that there was a good reason for the change, but from a functionality perspective it results in a step backwards.
What if the master password was tied to the Windows user profile, so that the Mozilla master password was unlocked when the user logged into Windows?
The features you are talking about, such as keeping the master password unlocked, did not occur in the previous implementation of quicklaunch either. In those days we were looking for any state that stayed around after the last window closed and were explicitly adding code to make sure to delete that state. In the case of session cookies for example, there was a listener installed to catch the last-window-closing event and delete all session cookies. The only reason for the new turbo model is that we were having to find and delete each state individually, and we weren't getting them all. And we were filing bug reports on those cases that we missed. By doing a complete shutdown, we assured ourselves that all state had been reset. For the behavior that you are describing (closing all windows but still continue doing background things like checking e-mail), why can't you simply minimize your windows rather than close them?
Eric: I don't think we should depend on Windows' security in any way. I trust Mozilla's password encryption a lot more than I trust the NT password hash. Stephen: I agree that cookies and such were deleted, but if you had it sepecified to keep your passwords "unlocked" for a certain period of time, the old Quicklaunch would keep those passwords unlocked that long and keep checking mail, even if all browser and mail windows were closed. The only reason I got involved with this bug discussion is because quicklaunch stopped doing this, with the advent of the new Turbo model. And as to why you can't just minimize things, I think that's a psychological question really. Users in general don't like their system tray cluttered up with programs they aren't currently using, and they've been taught that if something needs to keep doing something, you can keep it out of the way in the system tray, where it doesn't chew up your screen real estate. Plus, having something minimized in the task bar causes all sorts of little annoyances, like having it re-open the mail window when you close other windows in the system tray, or opening it when you alt-tab, etc. You can do it, I understand, but users (myself included) don't like to do it, and see it as a nuisance. I can't really explain why, perhaps it's the anal retentive in all of us, but it's really annoying at a basic level. :) Besides, who are we to break consistency with the way competing applications on the platform work? AFAIK every other mail program (Eudora, Outlook, etc) has a mode where they stay resident in the system tray checking your mail. The biggest harm done to ease of use is usually through breaking consistency of how things operate, and in this case I think that the breakage is a considerable sticking point with people looking to adopt the software. I can only offer annecdotal evidence, but with my sample size of a little over 30 people and a reaction rate of 100% towards this issue, I'd say that's enough to make a statistical guess that this is probably one of the major issues stopping Mozilla's adoption as a mail client on Win32 platforms. I'd be interested to see a poll of people who've tried Mozilla and continue to use Outlook anyway, and see what their reasons are. Anyway, back on topic, I guess this is just a question of forcing people to do things the "Mozilla way", and losing market share, or giving the users what they want and expect, and gaining market share.
I second Eric on the fact that the lack of a persistent mail checker is a deal breaker (for me too at least).
The relaunch also breaks the intended functionality of making it easy and quick to launch Mozilla. If you close the last window and then have to wait 30+ seconds for it to relaunch, that's a hindrance. My understanding was that an original goal of Mozilla was for a small, fast browser that would run well on a variety of platforms and older machines. From the discussion on this bug it sounds like the new turbolaunch behavior is having a major impact on people without the absolute newest or fastest boxes.
My system is a 1 gigaherz athlon with 384 megs of RAM, which is much more than the average user right now. It can take up to 10 seconds (thankfully, its usually less) on my machine for the "hidden window" to hide and for mozilla to be accessible after that. This is definately inconvenient. I'm voting for this bug, since there's not much else I can do.
The restarting of the quicklaunch icon interferes too much on my p2-400 with 512 Megs RAM. The hourglass actually appears for several seconds and since I open and close browser windows all day long (I'm on cable) it's very annoying to me. I definitely agree that 1.0's quicklaunch performed a lot more like i expected it to. I actually spent a few hours figuring out how to join bugzilla and searching for this 'bug', specifically because I perceived this as a bug! Before installing 1.1beta I was just a simple user. Since I don't use mozilla for e-mail I can't comment on the mailchecking item, although having it check in the background seems desired behaviour to me.
I just upgraded to 1.1 today from 1.0, and it is better looking and faster great work guys! However, the new behavior of quicklaunch/turbo is very irksome. I have reviewed the discussion above, but I would like to point out the fact that if you want to enable persistent email checking you need to keep a mozilla window open. Rather than use quick launch, I could just launch mozilla normally and use the application shortcuts on the status bar. From my limited understanding Quick launch basically loads a big chunk mozilla when you first load it. How is this functionality any different than just opening up mozilla without quicklaunch and leaving a window open? I always close out application windows when they are not in use. This is causing a huge performance hit for me due to mozilla constantly reloading itself to clear the memory. My request is this, create a somewhat hidden/burried option(maybe under advanced) to disable the restart functionality and implement a "clear cache" type button somewhere to reload quicklaunch when memory utilization gets out of hand. Mozilla 1.0 never really got out of hand for me so I doubt I would even use it. I'm probably going to revert back to 1.0 since I cannot break my in-grained habits of closing windows when not in use until this is addressed. If not, I guess I'm stuck with 1.0 forever.
I thought of another point to add on. If those of us who are annoyed by the constant reloading; or want to keep checking email; or don't want to be entertained by download manager doing its job; (noticing a pattern here?) leave a mozilla window open all of the time, when does the memory problem get fixed? I am not a coder; I'm not saying I can fix any of the bugs in Mozilla better that anyone currently working on the project, but it seems like the resolution to fix the memory use is creating many more problems not just in the "engine" of mozilla but in raw functionality of the user interface. I personally do not think a 1.0 to 1.1 version change should drastically change the way the application performs to fix an "under the hood" problem?
Is anyone claiming that the new behaviour (complete unload/reload) isn't a kludge to fix memory-leak problems? Regardless of the answer, I'm in the camp that wishes the Quicklaunch taskbar-icon/module was permanent and kept email, etc. settings persistent.
Mail Checking: I have always thought there should be a "check mail" option in the Quicklaunch right-click menu. Reloading: I never had a problem with memory unless I left Mozilla running for a week or more on a PII-350 (384MB RAM) or Duron-600 (256MB RAM). On the PII-350, reloading causes the system to halt for 1 second then act slow for another 1-3 seconds. On the Duron-600 I haven't noticed a performance hit, but seeing it reload is annoying to look at. After I just spent half the day getting 1.1 to work, I think I'll go back to 1.0 until the reloading is fixed.
can there be an option for the system tray icon to only appear after the lastwindow is closed? i like to use the windows quicklaunch toolbar. that is wherei always click to get a new window to come up. when i have windows open,, i do not need the system tray icon to let me know that mozilla is running, because i have windows open to let me know that, so it is just wasting space for me. when i close all my windows out, i want the system try icon to appear, to let me know that mozilla is still running.
Andy: that's definately a useful option, IMO, but probably outside the realm of this particular bug. I'd suggest opening a new "feature request" bug with that description in it, as your request will most likely get resolved quicker by itself than if it was tacked onto this. ;)
*** Bug 165743 has been marked as a duplicate of this bug. ***
There is some confusion in the discussion of this bug. 'Turbo' or 'Quicklaunch' was intended to reduce the time from clicking the icon to actually using the program. This came up because of Mozilla's long startup time in comparison to IE (which is always in 'Turbo' mode, since it's the shell.) The system try icon only exists because of the Mozilla teams desire to be honest. The effect should be transparent. Those who were taking advantage of bugs in the implementation and using it as a 'Minimize-to-tray' or biff option we're only delaying the inevitable: file a new enhancement request. When I close Outlook Express (note that IE doesn't include Outlook) my mail ceases to be checked, even if I leave a browser window open. So comparison to IE is invalid. Having said all this, those who need these additional features should file relevant bugs asking for them. I think both a mail-check and minimize-to-tray option would be useful. Perhaps the Quicklaunch preference (don't shoot me) could have radio buttons or a slider to choose how 'open' you want Mozilla to remain. As for the cpu and disk activity during shutdown, this is valid bug material and needs to be addressed. In the meantime I've found that Mozilla 'warm-starts' up so quickly now that I don't need Quicklaunch. It's a little slow the first time after boot but subsequent loads are quite snappy. (Sorry for the novel.)
Kevin: I see what you're saying, and I agree with it. I think the discussion just got carried away on this bug because it dealt with the changes that made everyone aware of the issue. I've filed a feature request (bug 168234) to deal with the concept of persistent mail checking, and anyone interested in that feature should probably deal with it there, so this bug at least can get dealt with on its own.
Kevin: In that case, I strongly urge the development team to remove the Mozilla icon from the system tray. To Windows users, an icon there doesn't mean "I'm being honest about my presence in memory," it means either "I'm actively doing something in the background" (e.g. antiviral programs, Popup Killer) or it means "You can use me to easily tweak settings or to quickly access features" (e.g. Volume, Nero's InCD). That being said, recategorizing users' problems as "feature requests" still leaves open one of the problems with the current functionality of the Turbo/QuickLaunch feature, which is that it hogs system resources. It shouldn't be necessary to slow down an entire system (even if only for a second or two) in order to keep a program in memory. On my machines, the slowdown is on the order of two to three seconds. In addition, as Tony said in <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=146340#c36">Comment #36</a>, this is a kluge that attempts to address a deeper problem with memory leakage. Since it's also causing other serious problems with users (whether or not you classifythese problems as "bugs" or "feature requests") it's obviously not the way to go. Finally, another problem with the Turbo/QuickLaunch as it stands now is that every time I close my last window and then start Mozilla again, I have to reselect which profile I want to use. This is a regression in functionality since 1.0 when Mozilla would "remember" which profile to use. So I have a quick question...is that a "bug" and thus belongs here, or should I open another "feature request" for it?
>In that case, I strongly urge the development team to remove the Mozilla >icon from the system tray. This would not hurt my feelings at all. Microsoft Office has a program called osa (Office Startup Agent) which loads in startup by default. It loads common office dll's and does not have an icon. You have to kill it from task manager if you want it gone. >"You can use me to easily tweak settings or to quickly access features" Precisely what this icon currently provides: quickly start Mozilla. >Finally, another problem with the Turbo/QuickLaunch as it stands now is that >every time I close my last window and then start Mozilla again, I have to >reselect which profile I want to use. This is a regression in functionality >since 1.0 when Mozilla would "remember" which profile to use. So I have a quick >question...is that a "bug" and thus belongs here, or should I open another >"feature request" for it? According to the "transparency" goal of turbo, the 1.0 "functionality" was a bug and was corrected. Again, minimize-to-tray would address this. The whole turbo feature was not well planned, but was a reaction to address browser startup time problems as compared to Internet Explorer. It's time to re-think it. I think the system tray icon should not be tied to -turbo, but should be available for many Mozilla functions. Turbo should use the icon as a status indicator ("I'm loaded") and for quick access. The same icon could be also be used for new mail indication, calendar alarms, and minimize-to-tray functionality. Bug 115348 has the foundations of this, but hasn't been commented on in awhile. Is this bug good for addressing performance problems related to the turbo 'reload' issue, or do we need another one? The description only mentions the icon disappearance. Perhaps the reporter should clarify so that we can move irrelevant discussion somewhere else if necessary.
*** Bug 168503 has been marked as a duplicate of this bug. ***
(All of this is IMHO) I thought that the whole point of Quick Launch was that Mozilla stays running at all times so that windows open more quickly, pages load more quickly, etc. What is happening here is that the mozilla process is entirely unloaded from memory and then restarted. This results in: 1) Consuming a ton of CPU cycles. On slower computers, this amounts to a lot of lag. 2) Creates a window of time when opening a new browser window takes a very long time. Are there not better ways to free up memory other than to reboot the whole thing?
IMHO this is a serious issue to be resolved for 1.2 (although it's pretty close).... It really knocks Mozilla down a notch from being a premier browser. QuickLaunch made it really zippy to launch... Now if I accidently close all windows, it takes a while to reboot. On a laptop this is a real drag with a low RPM drive. Not to mention what it does to the battery. If this is a memory issue, could we possibly have a temporary work around where a user can edit prefs so that it will only quit when it occupies XX MB of RAM... So that someone with a good amount of RAM can specify it to only do this at that point? That wouldn't be perminent... But would make quick launch, and Mozilla a bit more useable for the time being until someone finds a good fix.
*** Bug 170198 has been marked as a duplicate of this bug. ***
*** Bug 170198 has been marked as a duplicate of this bug. ***
*** Bug 149408 has been marked as a duplicate of this bug. ***
Flags: blocking1.3a?
Flags: blocking1.3a?
More than two monts after the post in this bug, and one generation further down the line (we've just hit 1.3 beta) this Bug is still destroying quite a bit of the fun one could have with Mozilla. I use Mozilla personaly, but then again I've got 512MB RAM and a 10kRPM drive, but there is no way I can recomend Mozilla to people using a less workstation-like PC. I'm sorry for spewing, I myself can't program by far good enough to participate other then beta-testing, but I just thought I'd let you know how a user (and webpage-designer) sees this bug: it needs to be fixed ASAP!
Blocks: majorbugs
*** Bug 193423 has been marked as a duplicate of this bug. ***
as i see it, this feature has nothing to do with "turbo" as it is called. the turbo is intended to reduce the startup time by keeping parts of mozilla in memory. but as it is now, it does not keep mozilla in memory, mozilla is closed and parts of it are loaded again at once. so from another viewpoint, you reduced the startup time by moving parts of the load process to the shutdown sequence. so mozilla is faster to load but takes longer to close. the turbo feature is a bug.
I looked how the quick launch works and I'd say it's a feature, since mozilla just restarts, so it blinks. I have for 1-2 days open multiple windows + mozilla mail and mozilla takes about 120Mb of ram + 150 Mb of virtual RAM and since this problem is not fixed we just have to restart the whole thing into it's "just started" state where it eats 17-20Mb...
As was previously stated, the purpose of quicklaunch/turbo is to make launching mozilla faster. Those of us who don't have top-of-the-line computers experience much more than a blink. It takes many seconds for mozilla to restart. The lousy hack to deal with orphaned memory (or whatever the problem is) is just that, a lousy hack, and it significantly affects the user experience. The memory problem needs to be fixed. It makes enough sense, I suppose, for this bug to depend on that one, but really, this ``fix'' depends on the fact that the user is going to close all of his windows at some point, which is not necessarily going to happen.
I'm running a 1.8Ghz laptop... since it has a 4200RPM drive... I suffer as a result. I agree fixing this feature is important. I also think it should stay, and shouldn't be removed. It's a great feature that helps make Mozilla more usable on win32.
> The memory problem needs to be fixed. Too bad it's a problem in the system C library....
> Too bad it's a problem in the system C library.... Does that mean this bug cannot or will not be fixed? If so, then perhaps this bug needs to be closed with that notation? Also, I'd like to point out that these issues (the slow restart and the memory leakage) come up frequently during our Mozilla Evangelism/Adoption efforts. These aren't just academic issues, they are real problems hampering the wider adoption of Mozilla both as a whole (that is to say, as a browser suite) and as a platform for other development.
I agree with 200% with comment #58. And the release notes say Mozilla needs only 64 MB of RAM.... to install. I think this is giving Mozilla the "bloated" reputation. Fixing this now would increase performance, and free valuable resources... leaving more room to expand upon Mozilla. That ram is wasted potential.
Adding Boris to CC list, since he seems to know more about this bug... I have to second what was said in comment #58 and comment #59. I have been running mozilla on winNT/2k, as well as Linux with Glibc 2.2 and 2.3 in Debian. On all four platforms (if you want to call different Glibc versions platforms) mozilla has leaked memory, and it just keeps getting worse. It wouldn't be so bad if it just leaked memory, as the OS would just swap out the pages that were unused after a while with memory pressure, but mozilla doesn't do that. Its working set keeps getting bigger and bigger eventually until the system is thrashing in swap, so you close and reopen mozilla and let it happen again...
Blocks: 108795
Oh, boy. There are two separate issues here. 1) Memory leaks. These exist. Information on finding them is always welcome. No one seems to ever bother to provide any. "Mozilla leaks" is not such information. 2) Mozilla's memory requirements are determined by the largest page it has loaded thus far. See bug 130157. This is a problem with the malloc() implementation and so far there are no good ideas for how to work around it.
Actually, memory problems are only secondary to the true focus of this bug, which is how QuickLaunch as it is currently implemented is violating user expectations. (At least, that's what the focus seems to be to me...) Still, it is good to know the underlying and related problems. After reviewing the discussion for this bug, there seems to be a need for not only QuickLaunch, but also a Minimize To Tray feature. Minimize To Tray would allow users to close all their Mozilla windows and still have it maintain their session ephemera (cookies, passwords, profile selection, etc.). Of course, Minimize To Tray wouldn't have the memory clearing benefits, so that problem would have to be fixed in another way. Thoughts?
thoughts? don't think in this bug. use a newsgroup. the correct fix is to honor the windows user interface guidelines and not dump garbage (quicklaunch) in the system notification area. -- if the icon never appears in that area then you wouldn't notice it disappear. -- this is correct. -- don't complain to me or argue about it, it's a fact. that doesn't mean we'll actually do it (ever). and of course fixing that doesn't prevent mozilla from causing the disk to thrash, that's some other bug.
> that doesn't mean we'll actually do it (ever). Sorry, I was with you right up until then (mostly because you were saying what I'd already said in Comment #43 ;). What exactly do you mean by this? Are you saying this bug isn't going to get fixed? > and of course fixing that doesn't prevent mozilla from causing the disk to > thrash, that's some other bug. IIRC, the last time a separate bug was opened to deal with the disk thrashing issue it was marked a duplicate of this one...but if you think a new bug needs to be opened, I say go for it.
> not dump garbage (quicklaunch) in the system notification area. -- if the icon > never appears in that area then you wouldn't notice it disappear I, and, I'm sure, many others use that icon to open a new browser window. But that's beside the point. There are other just as convienient ways, if you want to get rid of it. However, if it wasn't there, I'd have never figured out why it takes 5 seconds for me to open a new browser after I've closed the last one. That's the real issue. While quicklaunch does make a new window open faster in many circumstances, it makes it very slow in others. Assuming QuickLaunch exists to make launches quick, then you have a bug, regardless of any UI anomaly.
Perhaps this bug needs to be renamed, "Quicklaunch is unloaded as workaround to memory leaks", and then added to the blocked-by list of a bug related to memory leaks? Then, when the memory issues are better resolved, this workaround (unloading/reloading Quicklaunch) can be undone.
*** Bug 193687 has been marked as a duplicate of this bug. ***
While playing with newest Firebird builds, I noticed that 'turbo' feature is also incorporated to FB, unofficially of course. Anyway, it can be turned on with -turbo switch in shortcut, sadly bug annoying as this one has sneaked itself to FB. Any chance get this fixed before in next FB release? Just my 0.02 Euro.
*** Bug 210336 has been marked as a duplicate of this bug. ***
I agree absolutely with everything in comment 46 I have a P150 laptop (yes, it's below sysreq, but it still works), and I timed it: 0s: close last window, start timing, hdd thrashes furiously 7s: quicklaunch disappears 45s: quicklaunch reappears, hdd slows, probably virtual memory handling 65s: hdd stops, computer useable again Just over a minute between closing and being able to reuse computer. It also takes about a minute to start mozilla without quicklaunch. I'm yet to decide whether it's more conveniant to have the loading times when it starts or when it ends (or use M$IE) In preferences, under the quick launch option, it says "part of Mozilla will stay in memory when not in use, allowing it to start up faster" Surely it should do just that, stay in memory, rather than being dumped and reloaded again. Possibly (and this is just me thinking aloud) the quicklaunch should be a completely seperate process to the browser, so killing the browser can kill the process and free the memory, but the quicklaunch can remain. I don't know much about windows programming, but I think that would be possible. Just keep the data needed on loading loaded by the quicklaunch and get it from there (by DDE or shared memory or some such thing) rather than disk.
I'm sure someone will tell me how far off I am, but the last suggestion sounds like making QuickLaunch something like a RAM drive that holds the necessary Moz code for starting up. This seems like it would relieve the memory build-up, but cause a little bit more than usual of RAM to be 'reserved' for QuickLaunch. I'm not a programmer, so I don't know how that might work, or if it would net any help, but it, at least to me (non-programmer), sounds like an interesting idea to try. -bZj
> sounds like making QuickLaunch something like a RAM drive that holds > the necessary Moz code for starting up. That would (roughly) double the initial memory footprint after launch, which would be a Bad Thing (TM). (Low-memory systems would swap, defeating the entire purpose of quicklaunch.) However, on some operating systems it is possible to use something called copy-on-write, wherein two processes share the same memory unless it changes, in which case the process that changes gets a copy then of that section. I don't know whether the Win9x and/or NT kernels have this capability. Linux does, for example, but Moz on Linux doesn't have quicklaunch at present, so that's neither here nor there. If the MS kernel supports this feature, it ought to be possible for quicklaunch to hold in memory just the stuff that is loaded from disk at startup time and sit idle; subsequently, starting Mozilla could start a process that shares the memory with the quicklaunch process in this fashion; it would only have to be copied when anything changed, and only the sectors that changed would be copied. I suspect large sections would never be copied, so the memory footprint should much less than double. If I had to guess, I would guess that Win9x probably doesn't have this feature, but the NT kernel just might; we should find an NT guru to ask. Moz can't very well declare Win9x as unsupported yet, but since the quicklaunch feature as it currently stands is essentially broken anyway, telling Win9x users to turn it off on low-memory seems no worse than the present scenerio. (Presumably, if Win9x doesn't support copy-on-write it would copy the memory on process creation, which would double the memory footprint, though if the system has tons of RAM that might still improve speed.)
Re: comment 72: I discussed this in #mozilla and was told (this is the short abbreviated version) that it would be a real serious pain to implement and might not work as intended.
*** Bug 211970 has been marked as a duplicate of this bug. ***
about comment 72, this is essentially what I meant, just using DDE rather than shared memory, but I suppose that would work too. There isn't afaik a "copy-on-write" feature in windows, but there _is_ a "shared process memory" feature. <phlip searches through old code> OK, I found it. Should I post it here, or as attatchment?
This may be helpful to seperate the quicklaunch into a seperate process, so mozilla can quit without the quicklaunch closing. Then again, it might not. I suppose that's up to the developers to decide.
sorry about the lots of comments but I keep thinking of things to add (where oh where is edit post) this is not quite the same as what I think you mean by copy-on-write memory - if the browser wrote to the memory it would not make a copy, it would write to the shared memory as used by the quicklaunch, so the changes would persist after closing. What would happen is something like this: (1) The computer starts. Quicklaunch is loaded. It loads everything it needs to and dumps it into the shared memory area. (2) The user launches mozilla by the quicklaunch. It passes mozilla the pointer somehow (maybe via commandline parameter or DDE). Mozilla accesses shared memory and copies out anything dynamic, leaving static data behind. I don't know what kind of data the quicklaunch preloads, so I can't get more specific than that. (3) Mozilla quits, the process terminates and its memory is freed. Quicklaunch, as a seperate process is unaffected, it still has the shared memory, and is ready to launch again. I don't know how this compares to the memory footprint that quicklaunch already takes up, but it presumably wouldn't be too much bigger.
*** Bug 220660 has been marked as a duplicate of this bug. ***
I just installed the RC's of 1.5, and the bug is still there. The biggest problem I have with it is the moment when the reboot occurs. People with pre-configured desktops see the different components as different applications. They check their mail, close the mail component, start the browser, start the browser, start the browser, curse the computer, start the browser, and start surfing. If this restarting is needed, why not 30 seconds or 1 minute after closing the last window (as a dirty workaround), so that closing mail -> opening browser (within those 30 secs - 1 min) is much less painful? And another thing, 'listening' for user-input (ie. launching moz by clicking a desktop-icon) seems to be the last thing the quicklauncher does when starting, and every click received in the time the quicklauncher is starting will be ignored. If it were the first thing, people could start mozilla immediately after it appeared on their desktop, and the quickstarter should execute the command immediately after it's loaded.
*** Bug 223748 has been marked as a duplicate of this bug. ***
The fact is: "Quick Launch" is anything BUT quick now and it is confusing to new Mozilla users. Problems: 1) There is about a 10 to 15 second "dead windows" if you use quick launch when you can click the "launch Mozilla" icon and nothing happens and: 2) On high speed computers "Quick Launch" is actually slower than not using it and 3) New users think Mozilla is broken when they try Quick Launch immediately after shutting down as "nothing happens" while Mozilla does its housekeeping for 10 to 15 seconds after a shutdown in many cases. Maybe this is "normal and expected operation" for the designers, but "we users" normally would expect QUICK LAUNCH to a) be quick and b) not be so "dead" that it could not listen for a "quick launch command" while it was doing its housekeeping. Certainly if you do NOT use QL on a 1.8Ghz machine it is quicker responding immediately after a shutdown than USING QL. Thanks
*** Bug 229808 has been marked as a duplicate of this bug. ***
*** Bug 182861 has been marked as a duplicate of this bug. ***
Assignee: law → quicklaunch
Status: REOPENED → NEW
No longer blocks: majorbugs
Is this now a SeaMonkey-only bug?
Quick Launch has been remove by bug 361682. This bug should be invalid.
Trunk -> 1.8 branch: I think (only) SeaMonkey 1.1.x still has this feature !?
Assignee: quicklaunch → nobody
Blocks: 98673
Depends on: 361682
Keywords: regression
QA Contact: agracebush → quicklaunch
Target Milestone: Future → ---
Version: Trunk → 1.8 Branch
Quicklaunch/Turbo Mode is no longer supported in Seamonkey 2 and Seamonkey1.X is in the maintenance mode (fixing only security bugs)
Status: NEW → RESOLVED
Closed: 23 years ago → 17 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: