75599 - [META] Turbo mode tracking bug

Status: RESOLVED WONTFIX

(Core Graveyard :: Cmd-line Features, defect, P2)

Description

[Bill Law]

The following is from a post to netscape.public.mozilla.performance.  I'll 
attach the patch to this bug shortly.  This bug will be used to track progress 
on this feature.

----------------------------------------------------------------------------

Attached is a patch that adds support for a new "-server" command-line switch 
for Win32.  It will suppress opening the initial window (but not profile 
manager so it really only works properly if you have a single profile and don't 
normally see the profile manager dialog at startup).

Launching Mozilla again will simply open a new window.  There's a patch to the 
DDE server code to support that better; thanks to Brian ([e-mail]) 
who provided that code for bug 50424.

Opening the first navigator window takes 6-7 sec with mozilla already running 
in "server mode."  That's versus 10-11 seconds starting from scratch.

Subsequent windows take 2-3 seconds (once mozilla is running with a Navigator 
window open; "server mode" or not).

We need to figure out what other services/libraries to load initially and 
figure out how to do that.

This code might support the Mac without too much work.  Linux is another story 
because it doesn't have any ipc mechanism for a second instance of the app to 
talk to the already running "server."

Bill Law

Chris McAfee wrote:

Sky wrote:

Saw this in a forum somewhere

"I don't know all that much about coding myself, but I think that it would
be interesting if someone were to create an optional preloader for Mozilla
that ran when you started up Windows that loaded up
some of the, uh, core files and stuff so that there wouldn't be so much of a
wait every time you load Moz for the first time (not that it's the WORST
wait in the world, I'm just saying there is room for
improvement still, right?)
"


Yes, we have been thinking about this.  CC-ing .performance.

-Chris

Comment 1

[Bill Law]

Attachment: Original patch

Comment 2

[Bill Law]

Attachment: Newer, slightly different patch

Comment 3

[Viswanath Ramachandran]

thanks Bill. Reassigning this to vishy. nominating for nsbeta1. 

Comment 4

[Asko Tontti]

dup of bug 36283?

Comment 5

[Paul Chen]

nav triage team:

marking p2

Comment 6

[Paul Chen]

nav triage team:

Also marking nsbeta1+

Comment 7

[Cathleen]

bill, any luck finding your patch?

Comment 8

[Bill Law]

No, I looked and I looked.  The only hope is if I emailed it to somebody (or a
newsgroup).

Probably, I decided it wasn't worth keeping (since it was a total hack to keep
the first window hidden and then show the next one).  I'll have another go at it
RSN.

Comment 9

[Peter Lubczynski]

Have you seen rickg's pre-loader stub in bug 36283?

Comment 10

[Bill Law]

Attachment: new nsINativeAppSupport.idl (separate from patch)

Comment 11

[Bill Law]

Attachment: New patch

Comment 12

[Bill Law]

I attached two new files.  The first is a new nsINativeAppSupport.idl that 
replaces the old nsINativeAppSupport.h header with an enhanced/scriptable/etc. 
interface.  I added some stuff to support this "server mode."

The second file is a comprehensive patch that provides as much "server mode" 
support as I think is necessary to prototype this feature, measure performance, 
etc.  It builds on the patch to bug 53952 (i.e., includes those changes to 
nsNativeAppSupportWin.cpp, also).

Basically, the changes in this patch:

1. Replace the nsINativeAppSupport.h header with an enhanced .idl.  This has 
not be tested on platforms other than Win32 so beware (although it would be 
trivial to fix up other platforms if by chance something is amiss; I *did* 
change the Makefile.in/MANIFEST*, etc. files so unless there's a typo or 
something it shouldn't be a problem).
2. Adds default implementation of the new nsINativeAppSupport methods to 
nsNativeAppSupportBase (used by Linux, Mac).
3. Changes nsNativeAppSupportWin.cpp to look for "-server" command line option 
and deal with it.  Also implements OpenHiddenBrowserWindow and uses this hidden 
browser window when a request to open a new window comes in.
4. Changes nsAppRunner.cpp so it checks for "server mode" and in that case 
opens a hidden browser window (rather than a visible browser window).  That's 
the only change necessary there, thus far.

The only quirk I've found is that for some reason, we get an "activate" 
triggerred when I make the browser window "hidden" (by resetting its parent).  
Because this occurs earlier on than would normally, the window/widget code 
throws some "warnings."  It works OK if I just "ignore" the assertions.  I 
think the assertion popups won't happen if we're in a non-debug build.

This is due to a WM_SETFOCUS being generated when SetParent is called.  I need 
to talk to danm/saari/hyatt about this and see about resolving this somehow.

Comment 13

[Bill Law]

Vishy is giving this back to me; what a guy!

Comment 14

[Cathleen]

alecf, can you help review law's latest patch?  -thx!  :-)

Comment 15

[Cathleen]

r=cathleen  :-)

I tried the patch, and ran with -server, and it works.  Will have some 
performance numbers coming up soon.

I ran without the -server, app starts as normal.

Comment 16

[selmer (gone)]

From today's perf meeting:

1.  Need profile manager fix to only allow -server if exactly 1 profile or -P
specified.
2.  Need to stay alive after last window is closed.  (Proposal to only exit all
the way out if File|Exit is used.  Is that OK?)
3.  Need a release note that multi-profile users should use -P option if they
want preloading with this solution.
4.  Need the installer to put the preloader into the startup folder.  (Do we
need a dialog in the installer for this?)
5.  Need to handle the case where user wants to get to Profile Manager while
we're running in -server mode.  Suggestion is to put up a dialog asking user to
user File|Exit and then launch to profile manager again.  
6.  Need to clear any UI changes implied by enabling this in the build for beta.

Comment 17

[timeless]

We need to break this into multiple bugs.  Personally I think Tasks*[call it 
what you like]>"Profile Manager" or "Change Profiles" or "Switch Profiles" 
or "Manage Profiles" would be a better idea.

I expect mpt has an objection to overloading the Exit dialog.

Comment 18

[selmer (gone)]

I put all those items here at Bill's request.  Separate bugs would be fine
except for items 1 and 2.  Items 1 and 2 are really part of this bug.

Comment 19

[Bill Law]

Attachment: Add onclose handler to navigator.js to "cache" window if in "server mode"

Comment 20

[Bill Law]

I've attached a patch to navigator.xul/navigator.js to add an onclose handler 
to the navigator window.  This handler checks for "server mode" and if set, 
gives the window to the nativeAppSupport object to be cached.

This requires some modifications to my previous patch, though.  I'm just 
throwing it out there for review/discussion.  No additional work is required to 
make File|Exit really exit.  That seems to bypass the Navigator onclose handler 
somehow or other.  I'm not sure why, but I'm not looking a gift horse in the 
mouth.  A relatively simple fix to make this more fail-safe would be to call 
nsINativeAppSupport::SetIsServerMode(PR_FALSE) prior to going through the 
normal File|Exit logic.

I've landed the pre-requisite fix for bug 53952 and I'll be formulating a 
revised patch that only adds "-server" support.

Some work still needs to be done here because the "cached" browser window 
doesn't reset its session history and related stuff.  I'm thinking that sort of 
cleanup should go in this onclose handler (it's much easier to do there than in 
nsNativeAppSupportWin::CacheBrowserWindow).

Another thing is that this "cached" browser window does *not* get used if you 
open a new Navigator window by some means other than double clicking on the 
program icon (or equivalent).  E.g., if you go to Mail and press Ctrl-N, then 
it opens a new navigator window.  I think that's kind of a hard problem so 
solve because the chrome is littered with
window.open("chrome://navigator/content") calls which are hard to intercept.

Life might be better if we created an instance of some "navigator" object 
(e.g., nsBrowserInstance) and invoked an open() method on that.  But that's 
kind of a heretical point of view...

Comment 21

[Bill Law]

Attachment: Comprehensive patch file (make sure to get nsINativeAppSupport.idl, too)

Comment 22

[Bill Law]

Attachment: mozilla/xpfe/appshell/public/nsINativeAppSupport.idl (new file)

Comment 23

[Bill Law]

The last two patches provide all the code I've got so far.  This pretty much 
works.  Missing is profile-manager handling of cases where the profile manager 
would try to put up a dialog and some window resetting stuff that needs to be 
figured out (e.g., resetting session history).

You need to apply the "comprehensive patch" and also get the 
nsINativeAppSupport.idl file and put it in the right spot.

Recent development is code to handle early WM_SETFOCUS that causes assertions 
during reparenting of initial "cached" browser window.  I subclass the window 
during reparenting and suppress the WM_SETFOCUS.  I've replaced 
the "OpenHiddenBrowserWindow" method of nsINativeAppSupport with a more 
generic "CacheBrowserWindow" method that handles closing of previously opened 
windows.

Looking for review and super-review.  email questions or ask here in the bug.

Comment 24

[timeless]

I think we should queue messages we receive while waiting for profile manager.

Comment 25

[chris hofmann]

need this work to keep chugging along but its too late for 
adding features in 0.9.1.  changing milestones.
keep going on this as fast as you can..

Comment 26

[Peter Lubczynski]

What kind of notification is there that we are running in -server mode?

Comment 27

[Alec Flett]

as far as flushing stuff to disk, while I think this is a good idea, I'm
wondering if we should instead try to leverage conrad's profile-switching stuff
to make all "registered" components flush themselves to disk (like cookies,
preferences, etc)

Conrad's mechanism uses nsIObserverService and some well-known profile-related
topics.. he's built in the "flushing" mechanism into all the components that
need it.

Comment 28

[Alec Flett]

oh, and to answer peter: I think we need to have some kind of
taskbar/notification area icon like the preloader has.. we can probably build
that directly into nsINativeAppSupport

Comment 29

[Andreas Franke (gone)]

> 2.  Need to stay alive after last window is closed.  (Proposal to only exit
>     all the way out if File|Exit is used.  Is that OK?)

Regarding File|Exit, wouldn't it be nice if you got a dialog asking you to
confirm to shutdown the preloader (only if it's running, of course). This way,
the user would know what's happening, and if this dialog had a "remember this
decision and never ask me again." checkbox and the user checks it, the behaviour
for subsequent exits could be the same as it is planned now.
If the preloader still had an (small) icon in the taskbar somewhere, you could
still exit the preloader that way.

Or are there already other apps that behave according to the original proposal?

Comment 30

[Peter Lubczynski]

I just asked because I started working on some nsINativeAppSupport interface 
methods for loading and removing system tray icons in bug:

http://bugzilla.mozilla.org/show_bug.cgi?id=18729

While we are doing this, I'd be nice to do in a way that other XP apps could use 
(like Mail and AIM).

Comment 31

[Bill Law]

re: flushing stuff to disk

I simply cribbed that code (flushing Bookmarks and global history) from the
navigator.js Shutdown() function (a few lines further down).  I simply wanted to
replicate the semantics of closing the browser window without really closing it.

It does look like the observer mechanism used to deal with profile changes
*could* also be used to manage this, but my goal was to minimize changes so that
this "feature" could be added with minimal impact to running normally.  So I'd
like to pass on pushing for this enhancement.

re: a tray icon for "mozilla as server"

That sounds like a good idea.  There's a proposal for this feature (in general)
described in bug 18729).  I'm sure somebody will say that's not needed for beta,
though :-).

What would this icon do when clicked?  Would it need a menu? (the proposal in
bug 18729 didn't support that).

re: Andreas's suggestion for a "shutdown preloader" confirm dialog at file|exit

That sounds reasonable.  Note that there's distinct "preloader" vs. "server
mode" projects/proposals and it's not obvious which you're speaking of (or
both).  Again, that might be a post-beta enhancement.

Comment 32

[Alec Flett]

regarding the observer service, etc.. I didn't realize you were looking at
existing code - I guess if the existing code is working, we should leverage that
for now... at the very least, can you consolidate the Flush()ing/etc into one
function that's called from both File->Exit and the onclose= handler, and then
add a comment that we should be doing this in a more pluggable way? I will feel
a whole lot better about it if there is only one place to fix down the road. Thanks.

Comment 33

[Cathleen]

trying out bill's new patches, will get an optimized build and some numbers 
soon.

Comment 34

[Bill Law]

Yes, I'll factor that bookmarks/history flushing code out into a shared function.

There's still the task of figuring out what *else* needs to be done.  I think
session history can be cleared via:
  webNavigation.sessionHistory.PurgeHistory(webNavigation.sessionHistory.count);
or something like that.

I really don't know what else needs to be done.  What about the things that are
"per session?"  What's a "session" now?  This applies to cookies and cache.  Is
there anything else?

Comment 35

[Cathleen]

Got an experimental optimized build, and it's looking pretty good (except a
minor problem, noted below).

tests done to the build:
--------------------------
1) verified normal startup works
2) verified fast/server startup works
     used -server option, waited till disk grinding stoped, launch browser again
3) verified close last window we return back to the -server state works
4) verified File|Exit quits the app
5) verified normal startup works again

bug found:
------------
when browser is in -server mode, we're still responding to keyboard entries...
:-(   try using up/down arrows, browser search shows up and you can type text
in it.  We need to disable keyboard inputs while in -server mode.

suggestion: 
mcafee and I like the -turbo better than -server...  turbo startup mode.  
what do you think?  

I'll also ask paw's help to run some numbers on this build.  :-)

Comment 36

[Cathleen]

btw, the keyboard problem only exist in mojo build, not in mozilla.  :-)

Comment 37

[Bill Law]

Attachment: Everything; new and improved

Comment 38

[Bill Law]

That most recent patch is everything (I used "cvs diff -N" to get the
new/removed files, too).

Changes include the suggestions from Alec re: navigator.js code.

I've also added to navigator.js code that resets the session history and resets
to about:blank when a window pseudo-closes.

In addition, I've added support for "mozilla -kill" which cancels server mode.

No fix for the keyboard problem.  It seems we grab focus a lot and I couldn't
find an easy way to prevent that.  I think I may have to leave in place the
subclass proc that is currently used during reparenting.  It could be tweaked to
suppress getting focus while the window is "cached."  But I'll leave that as
another bug.

There was a request to get this code checked in ASAP.  I believe I've got an r=
from Cathleen and will get an sr= from Alec now that I've fixed navigator.js.
I've got to find the place in the Mac build to compile the new .idl file, but
that's the only remaining hurdle.

Comment 39

[Peter Lubczynski]

law, perhaps this link will help:

http://www.mozilla.org/build/mac-build-system.html#Adding_new_files_to_the_build

Comment 40

[Alec Flett]

the contents of this patch look good, but there is excessive if() indenting
which is making it really hard to read. Two examples (one C++, one JS)

+    // Check if caller wants resulting window.
+    if(aResult) {
+        // Always return 0 if we don't have a window.
+        *aResult = nsnull;
+        // If window open was OK, then pass result as nsIDOMWindow.
+        if (NS_SUCCEEDED(rv) && newWindow) {
+            nsCOMPtr<nsIDocShell> docShell;
+            if (NS_SUCCEEDED(newWindow->GetDocShell(getter_AddRefs(docShell)))) {
+                nsCOMPtr<nsIDOMWindow> newDOMWin = do_GetInterface(docShell);
+                *aResult = newDOMWin;
+                NS_IF_ADDREF(*aResult);
+            }
+        }
+    }

could be:
---------------
+ if (!aResult) return NS_OK; // ok not to return a value
+ 
+ *aResult = nsnull;
+ 
+ // XXX shouldn't we have checked for this above? -alecf
+ if (!newWindow) return NS_ERROR_FAILURE;
+ 
+ // If window open was OK, then pass result as nsIDOMWindow.
+ nsCOMPtr<nsIDocShell> docShell;
+ rv = newWindow->GetDocShell(getter_AddRefs(docShell));
+ if (NS_FAILED(rv)) return rv;
+ 
+ nsCOMPtr<nsIDOMWindow> newDOMWin = do_GetInterface(docShell, &rv);
+ *aResult = newDOMWin;
+ NS_IF_ADDREF(*aResult);

And in JS:
+    if (nativeSupport) {
+      if (nativeSupport.isServerMode) {
+          // Give native app a chance to cache this window.
+          if (nativeSupport.cacheBrowserWindow(window)) {
+            // Window is "cached" so don't close it.
+
+            // But flush bookmarks and history, as if we did close it.
+            BrowserFlushBookmarksAndHistory();
+
+            // Reset session history.
+            var webNav = getWebNavigation();
+            if ( webNav ) {
+                try {
+                    webNav.sessionHistory.PurgeHistory(
webNav.sessionHistory.count );
+                } catch(ex) {
+                }
+            }
+
+            // Go to blank page.
+            loadURI( "about:blank" );
+
+            // This stops the close.
+            return false;
+          }
+      }
+    }
+  } catch (ex) {
+  }
+  // Ok to close window.
+  return true;

becomes:
+ if (!nativeSupport || !nativeSupport.isServerMode) return true;
+ 
+ // Give native app a chance to cache this window.
+ if (!nativeSupport.cacheBrowserWindow(window)) return true;
+
+ // But flush bookmarks and history, as if we did close it.
+ BrowserFlushBookmarksAndHistory();
+
+ // Reset session history.
+ var webNav = getWebNavigation();
+ if ( webNav ) {
+ try {
+   webNav.sessionHistory.PurgeHistory( webNav.sessionHistory.count );
+ } catch(ex) {
+ }
+ 
+ // Go to blank page.
+ loadURI( "about:blank" );
+
+ // This stops the close.
+ return false;

There are many other examples of this in your patch..

Comment 41

[Cathleen]

issues with -turbo mode:
* multiple profile case (bug 81706)
* keyboard events (bug 81708)
* homepage with popup window (bug 81712)
* relaunch should go back to homepage (bug 81714)
* persist -turbo if restart for skin switching (bug 81715)

Comment 42

[selmer (gone)]

Since this still isn't checked in, where can people get binaries?

Comment 43

[Chris McAfee]

we need to get this checked in to get real testing on this.
until that happens, people are only going to be doing patched builds,
e.g. developers-only.

Comment 44

[Peter Lubczynski]

Please check this in, my $.02...

Comment 45

[Cathleen]

alecf, can you review bill's latest patch??

everyone is anxious to get bill's changes in, so we can start mass testing.

Comment 46

[Alec Flett]

at the request of cathleen, sr=alecf

Comment 47

[Mike Jaques]

So, how is this activated?  Does the installer give you the option of somehow 
having:  "mozilla.exe -turbo" on startup of windows?    is there eventually 
going to be a comprehensive preloader that sits in the tray ala realplayer with 
right clickable options, and a pref somewhere in mozilla itself to 
enable/disable the feature?  Also, I know its underway, but hopefully there are 
efforts underway to do similar pre-loading for linux X windowing and MacOS,  I 
know MacOS suffers greatly from poor start-up times and the pre-loader could 
offer some relief, though it doesn't fix the underlying slowness factors.  Just 
wondering about the implementation of this.

Comment 48

[Ben Goodger (use ben at mozilla dot org for email)]

Heh. I tried it out in my debug build, and it leads (predictably) to very fast 
"first window" display times. 

My only suggestion: rename the command line switch from "turbo" to "silvia". I 
can supply a patch ;) 

Comment 49

[Conrad Carlen (not reading bugmail)]

I think the name of this feature should be "headstart" instead of "turbo"
"turbo" is so cheesey and it's not even true. Nothing happens faster with this
approach - it just happens at a different time. A headstart is really what's
happening and, IMO, it's a catchy name.

I'm thinking about how to make this happen on the Mac. I don't think it would be
to hard.

Comment 50

[Andreas Franke (gone)]

Anything is better than "turbo". The old "server" was serious and correct.
Command line option names are not the right place for jokes, IMO.

Comment 51

[Conrad Carlen (not reading bugmail)]

The easy way to make this happen on the Mac is to put an alias to a Mozilla file
which contains "ARGS:-server" in the Startup Items in the system folder. That
will cause mozilla to be launched at startup with that document which, on the
Mac, is how we simulate command lines. Mozilla, from its prefs, could turn this
feature on or off by simply creating/deleting this alias.
The problem with this is that, launched this way, mozilla will be launched in
the foreground. I would think for this purpose we would want it to be silently
launched in the background. That's possible if we write a little deamon - an
alias to which is placed in the Startup Items folder. This little thing would
launch mozilla (in the background), sending it the -server arg, and then quit.
Again, this feature could be controlled by prefs which would create/delete the
alias to the launcher in Startup Items.

Of course, in addition to the startup trick, would be implementing the native
app support stuff from Bill's patch on the Mac.

Comment 52

[Cathleen]

come join tomorrow's 5/24 performance meeting 1:30pm PST, B21 Eng Pit (dial in 
numbers available at http://mozilla.org/performance/ ), if you're interested in 
discussing similar solutions for mac and linux.  :-)

Comment 53

[Brendan Eich [:brendan]]

mozilla.org doesn't cotton to marketing names.  If headstart is agreeable, great
-- how about a newsgroup discussion?  It may lead nowhere, but it could converge
on one or two names, and then (if people are still fighting), mozilla staff will
have the pleasure of breaking the tie.

/be

Comment 54

[Nicolás Lichtmaier]

-server is not accurate, as there's nothing being served here. -daemon would be
better IMO.

Comment 55

[basic]

Can someone explain the difference between this bug and bug 36283?

Comment 56

[Cedric Berger]

I hope that in "-turbo" mode, the Java VM is pre-initialized, right?

Comment 57

[Bill Law]

I dunno.  If it happens as a by-product of opening up a hidden Navigator window,
then yes.  If not, then probably not.

Clues as to how to do that would be welcome.  I suspect some people might
object, however (if they don't use Java).

Comment 58

[Ben Goodger (use ben at mozilla dot org for email)]

Java should NOT be pre-initialized. Java was pre-initialized in Netscape 6.0, I
think, if it was available, and much work was done to make it only initialize
when a page with java was encountered. This is the right thing to do. I don't
mind it as a (non-default) option, however. 

Comment 59

[Matthew Tuck [:CodeMachine]]

Yes, we could have something like:

[ ] Pre-load Browser.
[ ] Pre-load MailNews.
[ ] Pre-load HTML Editor.
...
[ ] Pre-load Java VM.

Where "browser" does not include the layout engine of course because that is
used by all parts and always pre-loaded.

Comment 60

[Andrew Paterson]

Command-line option name: I think that "-headstart" is much better than "-turbo" 
but what about "-preload"? After all, that is what is being done here I think!

Comment 61

[Peter Lairo]

Yes, "preload", everything else is just confusing and not to the point.

Comment 62

[Aleksander Hropot]

suggestion: if there is a taskbar icon, it *could* serve also as a new mail
notification icon. i also suggest that right clicking taskbar icon opens a menu
with selections:
(icon) navigator
(icon) messenger (mailnews)
(icon) composer
(icon) adress book
(icon) irc client or AIM
also, double click on icon would be customizable (i.e: opening new navigator
window or instantly checking new mail)

Comment 63

[timeless]

Aleksander Hropot: that's way too far afield, please check for other 
preexisting bugs or file a new rfe.

Comment 64

[David Ascher]

I'm amazed at the amount of discussion generated by a command line argument 
which the vast majority of users should never ever see because mozilla -whatever 
will be launched by an external program, shortcut, alias, shellscript, or 
whatever which ships with the app!  

I'm much more concerned with the user experience involved in making this go 
live.  

 1) Is this going to be the default?  How do we explain "oh, by the way, 
preloading means you'll have XX megabytes of RAM allocated, which may or may not 
slow down your OS, we can't tell".

 2) What's the UI like?  An other app?  Setup on installation?  Configurable 
from within Moz?  etc...

FWIW, I'm very keen on this feature, since we'll be able to use it in Komodo as 
well, which suffers from the same kind of startup issues as mozilla.  I would 
like us to come up with an "out-of-box experience" solution which works for all 
Mozilla-based apps in the long term, though...   

Does Microsoft Office's solution of putting something (can't even remember what) 
in the "startup menu" work?  Will people be unhappy when looking at their 
process list when no mozilla is "supposed to be running"?  I suspect the 
Microsoft Office preloader hides itself from the process list somehow... 

--david

Comment 65

[Tony Tovar]

I like David's comments about getting the program out the door.  I have the 
following additions to his comments:

1. Maybe the install program can use a pre-determined rule for whether or not 
to automatically install the pre-loader.  For instance, any PC with at least 
64MB (or is 128MB for realistic?) will automatically get the pre-loader 
installed.

2. re MS Office pre-load.  The Office97 pre-loader is visible in the Startup 
folder and also as an active process (MSOFFICE.EXE), but it is not listed as an 
Application.  This is what I am seeing in the WinNT (v4.SP6a) Task Manager.

As long as the pre-loader is implemented as an icon in the Windows Startup 
folder, then I think most users will know how to "manage" it, i.e., 
enable/disable it by moving the icon. (Sorry to the non-Windows users -- I 
don't know what the comparable steps would be on other platforms!)

P.S.  re the configuration UI.  Rather than continuing to extend the 
Preferences menu, has anyone considered some kind of internal "web-site", i.e., 
a local set of HTML documents that include Javascript commands to parse the 
config files and then present the current config in the main browser window.  
You would also need to be able submit changes and have OnClick Javascript that 
could update the local config files.  I know, I know, this needs to be a 
separate discussion thread, but hopefully someone here knows if this is even 
possible or desirable?

P.P.S.  Why is the OS for this bug listed as "Win2000" and not "All"?

Comment 66

[Cathleen]

-turbo suppose to work on all versions of windows

BTW, JAVA shouldn't get initialized during app startup.  we're delay loading 
JAVA till it's needed.  This is already fixed in bug 26516.  Our test result 
shown there is no difference to startup time whether you installed Java or not.

If -turbo is doing something funny where JAVA is loaded at startup, then that's 
a bug.

Comment 67

[Frank Burleigh]

This is *great*!  With the command line switch, moz opens nearly instantaneously
on my p733/512mb win2k machine; it is much faster to open than IE.  This will
solve one of the three big obstacles to "normal" users playing with moz.

But there is one side effect I think that has to be dealt with: when you click a
link in mail (a very common event these days, as I argued in bug 58848) or
probably anything else, you open a blank browser window that goes nowhere. 
Recall that in bug 58848 the problem is that embedded links or clicks on desktop
or file system objects brings up *two* mozillas: sometimes the requested "page"
is in both copies, sometimes only in one, all depending on how the builds are, I
guess.

So for me, until *that* gets cared for, this new but potentially great speed fix
doesn't really help.

Comment 68

[timeless]

we use the windows* things somewhat interchangably. However, ALL means at least 
two platforms. Eg Solaris and OS/2 or MacOS and Linux.

Personally i find the msoffice indexer applet (findfast?) which runs in the 
background to be a real disaster (dunno if current vers include it), most 
people run it becasue they weren't warned about it, and average users don't 
realize it's hurting their system [of course, find fast rarely helps because no 
one searches using it, so all it does is eat cpu cycles].

Comment 69

[Eugene Savitsky]

If I start mozilla with -turbo (I have a shortcut setted to activate at CTRL-M)
and then press once more CTRL-M the windows appears, but not maximazed.

Comment 70

[Eugene Savitsky]

When I close all the mozilla windows and press CTRL-M it appears with
"about:blank" instead with homepage.

Also it appears in background, so I have to click on it in the taskbar to get it
foreground.

Comment 71

[Eugene Savitsky]

More: when I click in my mail program (The Bat!) on a link the "about:blank"
windows appers, only when I click once more on the link it opens a new window
with the URL.

More: 

close all mozilla windows.
1. click on this link http://www.angelfire.com/ia/korolev/images in some
program, so mozilla will appear. 
2. The URL appears + banner window.
3. Close all windows
4. Launch mozilla
5. The first window will bw sized as the banner window was.

Comment 72

[Eugene Savitsky]

Sorry, in all my previous comments read CTRL-M as CTRL-ALT-M.

Comment 73

[Stefan Huszics]

My $0.02 on the name.

Does the commandline name really matter ?

YES!

Because somewhere in the prefs there has to be an on/off switch and the feature
must have an understandable name (so that even the everyday user knows what it
is). This name should the same used in the commandline or it will soner or later
lead to confusion.

As for what the name should be why not use one that is easily understandable and
already familear to people from other progs like eg "QuickLaunch" or "QuickStart" ?
No reason to make it cryptic by using a name like Turbo or Server that people in
general will have no clue about what it means or at least will have to look up
in a readme.

Comment 74

[Bozhan Boiadzhiev]

hi
i think that you don't have to think about the name 
--turbo and --server, why you try to give this thing name:) just call it 
mozilla... 
when ppl see such things like "winamp agent", "real player start center", and 
so on and so on... they blames this apps that they hurt their system...
what MS do is to hide all their **** from user ..do it the same way and nobody 
get hurts...put shortcut in Start -> Programs -> Start Menu -> mozilla which
executs "mozilla" and have fun, ppl will love this NEW FAST browser...
or even write it in registry.. as system tray, internat and many other apps....
..i can imagine diffrent world if NS have such feature...

Comment 75

[Ken Snider]

It's true.

The #1 issue (orders of magnitude above every other) that I have when I try to
"convert" users to Mozilla is startup time. Mozilla gets killed in reviews for
it, and the tech savvy know running IE with the "-nohome" option bring up IE in
under a second.

Mozilla *needs* this option; with it, one issue is *completely* resolved -
startup time.

And I have to agree with many others in this bug; activate it by default, or at
least include a checkbox in the installer that is "checked" by default. The
"default" user experience should be this "fast" mozilla. Until this happens you
can't possibly compete with IE's launch times, and it will *always* be a
detractor from mozilla/netscape.

Comment 76

[Jens Hatlak (:InvisibleSmiley)]

I'm using Apache/MySQL/PHP for my Mozilla Home page. The problem with the new 
-turbo cmd line option is that my page requires WWW authentication (realized 
with PHP to verify database connections). With the new option in use Mozilla 
asks me for my PSM master password, the user to take for auth. and finally for a 
confirmation at the user/password dialogue. I think the Home page should not be 
loaded in such a case, maybe it's better not to load the Home page until you 
actually call a Mozilla/Navigator window, e.g. by double-clicking a desktop 
icon. IMO the preload feature should never ask or tell anything: Even if the 
Home page is unreachable there should be no warning until you actually decide to 
USE Mozilla.
Apart from that I experienced that Mozilla loaded twice: At first Mozilla 
started in background (-turbo set) and asked me for authentication, then it 
loaded another time when I opened it using the desktop icon... Unreproducable, 
unfortunately. Another thing: When I open up Mozilla the first time after the 
preload it shows my Home page. If I close it then, it shows about:blank. :-/

Comment 77

[Sami Haahtinen]

A systray icon would be good to show if the 'server' is running on the
background, it also would allow selection of profile and starting & stopping of
the server if needed. (not to talk about mail notification, but that is beyond
this bug.)

Comment 78

[Peter Lairo]

Pleeeease don't call it "server" - that implies something different and more
complicated - it will only confuse users. Better call it "Command Center" or
something "markety" and intuitive and non-overwhelming like that.

Comment 79

[Andreas Franke (gone)]

It looks like the command line option name has to be different across platforms
then. My preference for "server" comes from a linux background where the "emacs"
text editor program successfully offers exactly this feature with programs
called "emacsserver" and "emacsclient". Since the Windows world is different,
feel free to choose anything for that platform that makes its users happy.

As far as I understand it, Windows users will never ever have to type the option 
because turning this feature on and off can be done with the GUI that puts a
prepared icon in the "Autostart" folder or something similar, whereas Linux
users will have to type the option manually on a command line, or at least write
it into some kind of script, so the option name is visible on this platform.

Since this bug is only about Windows, please disregard my preference for
"server" here. Also, I agree that correctness is at least as important as names.
:-) If you want to get the name discussion off this bug, please open the
discussion somewhere else (newsgroup, another bug) and post a link to it here.

Comment 80

[Judson Valeski]

what's the expected user reaction when closing the last window to switch 
profiles, or to kill the app for kiosk installations, doesn't actually shut 
down the product?

snuffing out the last window close seems like a mistake to me.

Comment 81

[Ken Snider]

Problem is that defeats the purpose of the "re-entrant" nature of this RFE.

Jest because I close the last visible window certainly doesn't mean I want to
unload the app; much like the way the mac works, if the idea here is to have the
application start *quickly* (i.e. with the same speed as IE), then it must
always be running. A taskicon that allowed you to unload it, or a menu option
(Shutdown?) would facilitate both the examples you've listed.

Comment 82

[Judson Valeski]

uh, mac is obviously an exception here. 75% of the OS marketplace has 
established the paradigm that closing the last window unloads the application.

Comment 83

[Judson Valeski]

sorry, that was supposed to read "75% plus...".

Comment 84

[Ken Snider]

That may well be, but you're missing my point.

The reason for this RFE to exist at all is to speed up the launch of the app, by
preloading it. I sincerely doubt that with the increased uptimes found in
Win2k/Linux that this can be served by preloading the app only the *first* time
it is launched, which is what you're suggesting by unloading it if I close all
windows.

Scenario: I boot. When I boot, Mozilla preloads. I do some gaming. Later, I
decide to browse the internet. I click on my Mozilla icon and enjoy all the
benefits this RFE has to offer. I then decide to return to gaming, so I close
all open Mozilla windows.

If, when I do this, mozilla *unloads*, then the next time I choose to open
Mozilla means I have to wait again. Considering I reboot *perhaps* once a week,
it means this feature has now been one I can enjoy *weekly*, unless I choose to
*always* leave a window open.

Does this seem to be the way this feature was intended? :)

IE Loads quickly because it is *always* in memory (since it is integral to the
OS). Closing the last window doesn't close IE, so it's safe to say that the
"competing products" already display this behaviour.

Comment 85

[Judson Valeski]

I'd actually argue that this is not a legitimate RFE :-).

in your scenario where mozilla pre-loads, what kind of system are you on that 
you can run mozilla and do "gaming" at the same time ;-)?

we're not integrated into the OS. in a simple black and white example, our 
"profiles" exist at the application level, whereas IE's exist at the OS login 
(boot time most often) level. pre-loading makes existing profile assumptions 
invalid.

Comment 86

[Tony Tovar]

For gods sake, people, we're talking about an *optional* performance feature to 
allow Mozilla to compete with integrated browsers like IE in start-up time ... 
and in perceived speed.

I agree with the comments about the -preload function loading a "permanent" 
object in the Taskbar which remains -- even when all Mozilla browser windows 
are closed -- unless it is manually unloaded.

Comment 87

[Judson Valeski]

sounded to me like we were going to have the installer do this at install time. 
I admittedly haven't read the entire text of this bug though.

if we make this a default, it will bite us.

Comment 88

[Conrad Carlen (not reading bugmail)]

> Considering I reboot *perhaps* once a week,
How is it that your system (and mozilla) is that stable? What about all the
electricity you're burning keeping your invincible system running that long?

Point is, there are some people who might prefer this feature and many who may
not. As far as I know, there has not been anything done to the prefs to allow
this to be switched on or off after installation. What happens at installation
time? There are several issues WRT profiles which were glossed over. I was
surprised to see that this code was checked in while so much discussion is going
on over it.

Comment 89

[Ken Snider]

I don't know if you can invalidte an RFE when the code is already in the tree. ;)

As for the system, it's just memory. :) Mozilla doesn't eat CPU cycles as it
sits there, and on a system without sufficent RAM, it would just get swapped out
if necessary. however most systems today have 128MB of RAM (My two have 256 and
512, respectively), and the memory footprint of Mozilla is really a non-issue.

This is a performance enhancement. Since Mozilla *cannot* be integrated into the
OS, the only way it can compete with the "incumbant" browser is to have a
feature where it can startup as quickly, by utilizing much of the same method.

most of the people I know finally switched from NS 4.x to IE because they didn't
like waiting 10 seconds for their browser to come up when IE is near
instantaneous. "Startup Time" has always been a negative, and this is one way
around it.

True, profiles are application-level things, but as I (and others) have
suggested, simply rewiring File->Quit (or adding a File->Shutdown) to close off
the resident portions of mozilla would solve that problem as well. :)

Comment 90

[Dimitrios]

I filed two bugs (bug 83366 and bug 82804) which are related to turbo mode
issues. In performance newsgroup, [e-mail] suggested to link any
related bug to #75599. Hoping I didn't make a big mistake by marking them as
blockers to 75599 :)

Comment 91

[Stefan Huszics]

"As for the system, it's just memory. :) Mozilla doesn't eat CPU cycles as it
sits there, and on a system without sufficent RAM, it would just get swapped out
if necessary."
---
Exactly how much memory are we talking about here ?
1MB ? 5MB ? More less ?

---
"however most systems today have 128MB of RAM (My two have 256 and
512, respectively), and the memory footprint of Mozilla is really a non-issue."
---

Be carefull with confusing the two widely separate issues, most systems
_bought_today_ and the mosts systems _in_use_today_ .

Your description is accurate on the first part, but definitly NOT on the second.

I totally agree that this feature is a really greate one, and probably should be
the default one during installation. However there must be an easy way to shut
it down.
If it isn't implemented with care and consideration to slow/old/lowend systems,
Mozilla risks to get a lot of unnessecary and unwarranted flak for it (the NS6
premature release any1 ?).

Comment 92

[Chris McAfee]

*** Bug 8578 has been marked as a duplicate of this bug. ***

Comment 93

[Pete Boyd]

I've filed bug 83657 (-noserver option to complement -server option) which is
closely related to this bug

Comment 94

[Pete Boyd]

if Moz has been loaded with the '-server' option, then run with the '-edit'
option, the Composer sits there downloading for a while and comes up with a page
from 'Netscape search results'.
I'm seeing this with build 2001052904 under Windows98

Comment 95

[Bill Law]

This is now just a tracking bug for all the fallout issues.  See dependency 
list.

Maybe we could reset this one's target milestone or something?  The "depends 
on" bugs will all be targetted for the appropriate milestone, right?

Comment 96

[Bill Law]

Changing milestone for this "tracker" bug to mozilla0.9.3 to get it out of my 
hair.  Please note that the "depends on" bugs have their own target milestones 
and this change is no reflection on the target milestone for those bugs.

Comment 97

[Jesse Ruderman]

Adding bug 83873, "-turbo prevents windows from getting focus when opened".

Comment 98

[Koike Kazuhiko]

I filed bug 83879 for #3 of selmer's comment on 2001-05-14.

Comment 99

[Peter Lairo]

Once Mozilla has the *ability* to load at win statup (this bug), we will need a
UI to turn this ability on or off. I created bug 83882 to track the UI for that.

Comment 100

[James "Kovu" Russell]

Having read the entirety of this bug, I have a few comments:

-turbo is better than any suggestion I've seen here. Other suggestions aren't
anywhere near as short (think typing - the fewer letters the better) or concise.
I would go so far as to call the feature "Turbo mode" so that users will really
want to use it. "Turbo mode" also implies to the user that the system needs to
be a good one if they're going to run turbo mode - people know that you don't
usually add/use a turbo feature on a Pinto, for example, only on a Mustang. Of
course "Turbo mode" should have an on/off checkbox in the installer, perhaps
even a "Not recommended for older machines" disclaimer.

As for the feature's closedown, I say we tag team:

* File|Exit closes preload.

* Right-clicking a taskbar icon (which could double as a command center) and
choosing Close Mozilla closes preload.

This way, if the user closes the window with the X button, they'll (hopefully)
see the taskbar icon is still open. They can right-click it and choose "Close
Netscape" and the preload bites it.

An option on the Start menu is also a possibility, but note that this might be
difficult to implement on Windows XP, which has a very minimized MS-only Start
menu IIRC. If this is true, we might not want to rely on the Start menu for much
of anything.

Comment 101

[Viswanath Ramachandran]

Moving this out as it is just a tracker bug, we are not fixing anything for this
bug in mozilla0.9.3. 

Comment 102

[Roger D]

I'm in the enterprise calendar client team. We need something that sits in the 
background and can pop up reminders at appropriate times if the user has asked 
to be reminded of something. It could also be occasionally polling the calendar 
server to see if the user has been invited to a new meeting (assuming it has 
network connectivity) and let them know if so (assuming they have set their 
preference to getting notifications). An obvious possibility would be to combine 
this with the -turbo option. [It also occurs to me that mailnews could do the 
same to check for incoming mail. Is anyone from the mailnews team here?]

Doing this would require that the -turbo stuff while running in the background 
can a) run various pieces of background code to monitor for significant events, 
b) come to the foreground and open a simple alert window if required (without 
locking the machine for many seconds while it does so), and ideally c) if the 
user prefers, do something more subtle to notify the user that they have new 
mail or a new calendar-related message, such as change the systray icon. This 
also adds a bunch of additional preferences issues (does the user want to open a 
network connection to check for new mail/calendar events if one isn't already 
open at startup time, do they want it to pop to the front if a new mail message 
coes in, ditto for a new calendar-related message, do they want it to play a 
sound in either of these cases, do they want it to just change the systray icon, 
etc etc.)

Comments?

Comment 103

[Matthew T (active 1999-2002)]

That would also require everyone who wanted notification to always have -turbo
turned on; it would be a non-starter (if you'll excuse the pun) for that reason
alone.

And by the way, Mozilla doesn't have an enterprise calendar client. Discussions
of features of such a beast would be best directed to a forum where it exists.

Comment 104

[Roger D]

To get notifications they are going to have to have _something_ running in the 
background all the time. The question is whether it's netscape -turbo, or just 
something more lightweight that just knows how to check for incoming mail, 
incoming calendar invitations, and times of events the user has requested 
reminders for, and that knows how to put up an alert window. The thing is, if you 
want that alert window to be skinnable, you need to pull in a significant 
proportion of Mozilla to display it - at which point going the whole hog to 
netscape -turbo doesn't seem so unreasonable, given its other advantages.

While the Netscape Enterprise calendar client is not (yet) open source, the 
Mozilla mail client is, and the primary reason I raised the issue in this forum 
was to see if anyone working on the mail client was interested in using the same 
mechanism there that we are thinking of using in the calendar client - clearly it 
would be silly to have multiple different pieces of Netscape/Mozilla sitting in 
tyhe background listening for events.

Comment 105

[Peter Lairo]

Whatever you do, make SURE there is only *ONE ICON* in the takbar. Integration
of features is everything - multiple icons for one app is unacceptable ;)

Comment 106

[Jesse Ruderman]

Adding:
bug 89504 enabling/disabling quicklaunch should not require a restart
bug 89505 Quicklaunch shortcut in startup menu is called "mozilla.exe"
bug 89511 quicklaunch should recover when restarting after crash

Comment 107

[Viswanath Ramachandran]

updating summary to indicate this is now a tracking bug. 

Comment 108

[Cesc Noguera]

Just a few ideas,

     First I would like to warn you that I am no programer, so my ideas might be 
miles of reality, but I think I do have a point, although the ideas might be a 
bit chaotic.

For a long time I have been following bug 18729 "[FEATURE] Windows integration 
for new mail notification" i.e. have a little mail icon appearing when a new 
message arrives. At bug 18729 it was suggested that maybe AIM could also use the 
same platform as the mail notification icon on the taskbar. Wouldn't it be 
better to create a single platform where we could include the mail, turbo, 
calender and AIM icons? Aren't we trying to solve the same problem twice? :-o

The turbo-icon might also be related to the mail-icon in that many people would 
appreciate being notified about new mail even if the browser is closed (or 
minimised as in the -turbo case) a bit as what happened nsnotify.exe in 
communicator 4.x

Comment 109

[Jaime Rodriguez, Jr.]

--> Pchen

Comment 110

[selmer (gone)]

*** Bug 99488 has been marked as a duplicate of this bug. ***

Comment 111

[Jaime Rodriguez, Jr.]

agree with steve, but let's make sure all the relevant bugs from the list below,
make it on this bugs dependency list.

Bug 86067
Bug 86904
Bug 87038
Bug 87379
Bug 87831
Bug 88844
Bug 89166
Bug 89532
Bug 88973
Bug 90690
Bug 93609
Bug 97620
Bug 99018
Bug 91129
Bug 95142
Bug 95894
Bug 96936
Bug 97620
Bug 98670
Bug 98673
Bug 98770
Bug 99387
Bug 99117
Bug 99129
Bug 99199
Bug 99321
Bug 99470

http://bugscape/show_bug.cgi?id=7196
http://bugscape/show_bug.cgi?id=9364

Comment 112

[Peter Trudelle]

Mass-moving lower-priority 0.9.5 bugs off to 0.9.6 to make way for remaining
0.9.4/eMojo bugs, and MachV planning, performance and feature work. If you
disagree with any of these targets, please let me know.

Comment 113

[Jaime Rodriguez, Jr.]

Todd/Sol - What's the short list of requirements (i.e. listed bugs) we must
resolve, for the next release?

Comment 114

[Jaime Rodriguez, Jr.]

Bug 99681 (WinXP: App does not launch in turbo mode if talkback is installed)

Comment 115

[Jaime Rodriguez, Jr.]

Bug 100319 (Turbo: Hangs or does allow Windows 98 to shut down)

Adding this one to the list for review.

Comment 116

[Peter Trudelle]

Here is my current short list:

86067 Closing all windows in -turbo mode keeps sessions informations
100385 [---, [e-mail]] - Turbo: Quick Launch, migrate a second
account that's IMAP and no acct info appears
100336 [---, [e-mail]] - Turbo: Quick Launch, conflicts in new
profile when creating Mail account
99940 [---, [e-mail]] - -kill option is ignored when mozilla isn't
already running [turbo]
100319 [mozilla0.9.5, [e-mail]] - Turbo: Hangs or does allow Windows 98
to shut down
98736 [---, [e-mail]] - Crashing on Exit (pref_ClearUserPref) [turbo]
The reporter is someone we need to convince to get Turbo on for eMojo.
84937 [---, [e-mail]] - [Windows XP]Profile Manager disappears too
early, app doesn't start

Comment 117

[Jaime Rodriguez, Jr.]

Thanks Peter - Here's one from Sol.
http://bugscape.netscape.com/show_bug.cgi?id=9566
and, possibly a new find from me ... needs some testing, though.
Bug 100625 (QuickLaunch is running older build/version, than what was last
installed)

Comment 118

[Jaime Rodriguez, Jr.]

updating 'stop-ship' short list:

Bug 86067 Closing all windows in -turbo mode keeps sessions informations
(Status = No patch)

100385 [---, [e-mail]] - Turbo: Quick Launch, migrate a second
account that's IMAP and no acct info appears
(Status = No patch)

100336 [---, [e-mail]] - Turbo: Quick Launch, conflicts in new
profile when creating Mail account
(Status = Verified Duplicate of Bug 99117 which is fixed)


99940 [---, [e-mail]] - -kill option is ignored when mozilla isn't
already running [turbo]
(Status = No patch; maybe dropped as a priority for shipment)

100319 [mozilla0.9.5, [e-mail]] - Turbo: Hangs or does allow Windows 98
to shut down
(Status = No patch; maybe dropped as a priority for shipment)


98736 [---, [e-mail]] - Crashing on Exit (pref_ClearUserPref) [turbo]
The reporter is someone we need to convince to get Turbo on for eMojo.
(Status = No patch; still researching)


84937 [---, [e-mail]] - [Windows XP]Profile Manager disappears too
early, app doesn't start
(Status = Blake says, this is not a Turbo bug. huh?)


http://bugscape.netscape.com/show_bug.cgi?id=9566
Turbo dialog uses mozilla icon
(Status = Patch needs an SR, and PDT+)

Comment 119

[Jaime Rodriguez, Jr.]

Turbo+ short list queries (1 bugscape + 6 bugzilla = 7):

http://bugscape.netscape.com/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&status_whiteboard=Turbo%2B&status_whiteboard_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time

http://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&status_whiteboard=Turbo%2B&status_whiteboard_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time

Based on some of the commnets in the bugs, I think we can cut the list to 3 by
the end of today. Pls remove Turbo+ and nsbranch- bugs, to shorten the list.

Comment 120

[Jaime Rodriguez, Jr.]

Adding Bug 89781

Comment 121

[Paul Chen]

mass moving mozilla0.9.6 bugs to mozilla0.9.7

Comment 122

[Paul Chen]

Moving this meta bug to mozilla0.9.8

Comment 123

[Peter Trudelle]

taking

Comment 124

[Brian 'netdragon' Bober]

See also: Bug 127122

Comment 125

[David Brittain]

Adding bug 26718, as this means that quick launch does not work in combination
with dial-up networking.

Comment 126

[Jaime Rodriguez, Jr.]

This is META tracking bug with a TM for Mozilla 099. Suggest we move it to TM
1.2 or Future.

Comment 127

[selmer (gone)]

Jaime, we need this fixed before the next release unless these bugs don't
matter.  The TM for the tracking bug should reflect when we need all the depends
fixed.

Peter, are we on track to get the necessary bugs in this list fixed?

Comment 128

[Peter Trudelle]

Yes.  This was the list from the last release, which got so inclusive as to be
useless.  For MachV, I'm using a much more focused dependency list in Bug
198795.  I'd like to retire this bug, or at least move it out.

Comment 129

[David Brittain]

Removed 26718 and replaced with 133108

Comment 130

[marlon bishop]

I am not sure if this point has been raised before:  is there a reason to show the systray icon while the browser is still open?  It seems that 
a user really just needs to know that once they've exited the application, the icon displays upon (apparent) exit.

it's just that we look a little pretensious in start bar with an icon in windows quicklaunch, one for each open netscape/mozilla window in 
task bar, and one in the systray.  that's a minimum of 4 access points from the start bar if you count the open start menu, this number of 
course grows with more windows you have open.  

Peter: Bug 198795 does not seem to exist yet.

Comment 131

[marlon bishop]

sorry for the spam, i messed up the dependencies with 4.x again

Comment 132

[Tony Tovar]

I think the QuickLaunch icon needs to be in the systray because it's a distinct
feature of Mozilla *AND* we're having problems with it activating.  Currently,
the systray icon acts as an immediate indicator if QuickLaunch has activated
correctly.

Comment 133

[Roger D]

As a user, I occasionally have to kill Mozilla out of my quick-launch tray (e.g.
when I'm doing an install, of if it's managed to hang). It's useful to have the
quicklaunch icon to do this from, and it's useful to have it there to indicate
whether Mozilla is running or not.

Comment 134

[Peter Trudelle]

Thanks Marlon, it is actually bug 18795.  

Comment 135

[Jaime Rodriguez, Jr.]

Adding paul, scott, and evelyn.

Comment 136

[Peter Trudelle]

er,... bug 108795

Comment 137

[Peter Trudelle]

Folks: please do not directly add or remove bugs from the dependency list of
this, or any other bugs you don't own, without the owner's permission. If we
can't control our own tracking lists in bugzilla, we'll be forced to do so using
private lists, which you won't even be able to see.  You are of course free to
create your own tracking list, and change it however you see fit.  

Also, please note that this tracking list has been obsolete for quite some time,
and is not currently being used or maintained.

Comment 138

[Peter Trudelle]

Mass moving all of my open Nav/toolkit bugs to new owner.

Comment 139

[Vedran Miletic]

retargeting

Comment 140

[Worcester12345]

(In reply to comment #137)
> Folks: please do not directly add or remove bugs from the dependency list of
> this, or any other bugs you don't own, without the owner's permission. If we
> can't control our own tracking lists in bugzilla, we'll be forced to do so using
> private lists, which you won't even be able to see.  You are of course free to
> create your own tracking list, and change it however you see fit.  
> 
> Also, please note that this tracking list has been obsolete for quite some time,
> and is not currently being used or maintained.

Funny, I just came across this post. I HAD tried to do my own tracking bug, but
it was closed on me. :-(

Comment 141

[Wayne Mery (:wsmwk)]

=> WONTFIX - turbo is gone after SM v1.1