[META] Turbo mode tracking bug

RESOLVED WONTFIX

Status

Core Graveyard
Cmd-line Features
P2
normal
RESOLVED WONTFIX
17 years ago
9 years ago

People

(Reporter: Bill Law, Unassigned)

Tracking

({meta, perf})

Trunk
x86
Windows 95
meta, perf
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nav+perf])

Attachments

(8 attachments)

(Reporter)

Description

17 years ago
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 (binarycowboy@mail.com) 
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
(Reporter)

Comment 1

17 years ago
Created attachment 30458 [details] [diff] [review]
Original patch
(Reporter)

Comment 2

17 years ago
Created attachment 30459 [details] [diff] [review]
Newer, slightly different patch
thanks Bill. Reassigning this to vishy. nominating for nsbeta1. 
Assignee: law → vishy
Keywords: nsbeta1
Priority: -- → P1
Target Milestone: --- → mozilla0.9.1

Comment 4

17 years ago
dup of bug 36283?

Comment 5

17 years ago
nav triage team:

marking p2
Priority: P1 → P2

Comment 6

17 years ago
nav triage team:

Also marking nsbeta1+
Keywords: nsbeta1 → nsbeta1+

Comment 7

17 years ago
bill, any luck finding your patch?
Blocks: 71780
(Reporter)

Comment 8

17 years ago
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

17 years ago
Have you seen rickg's pre-loader stub in bug 36283?
(Reporter)

Comment 10

17 years ago
Created attachment 33473 [details]
new nsINativeAppSupport.idl (separate from patch)
(Reporter)

Comment 11

17 years ago
Created attachment 33474 [details] [diff] [review]
New patch
(Reporter)

Comment 12

17 years ago
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.
QA Contact: sairuh → jrgm
(Reporter)

Comment 13

17 years ago
Vishy is giving this back to me; what a guy!
Assignee: vishy → law
(Reporter)

Updated

17 years ago
Depends on: 53952

Updated

17 years ago
Blocks: 79765

Comment 14

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

Comment 15

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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.
(Reporter)

Comment 19

17 years ago
Created attachment 34579 [details] [diff] [review]
Add onclose handler to navigator.js to "cache" window if in "server mode"
(Reporter)

Comment 20

17 years ago
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...
(Reporter)

Comment 21

17 years ago
Created attachment 34627 [details] [diff] [review]
Comprehensive patch file (make sure to get nsINativeAppSupport.idl, too)
(Reporter)

Comment 22

17 years ago
Created attachment 34629 [details] [diff] [review]
mozilla/xpfe/appshell/public/nsINativeAppSupport.idl (new file)
(Reporter)

Comment 23

17 years ago
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.
Keywords: review

Comment 24

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

Comment 25

17 years ago
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..
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 26

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

Comment 27

17 years ago
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

17 years ago
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
> 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

17 years ago
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).
(Reporter)

Comment 31

17 years ago
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

17 years ago
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

17 years ago
trying out bill's new patches, will get an optimized build and some numbers 
soon.
(Reporter)

Comment 34

17 years ago
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

17 years ago
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

17 years ago
btw, the keyboard problem only exist in mojo build, not in mozilla.  :-)
Keywords: perf
Summary: Enable Mozilla to start at windows startup to improve first window opening time → Enable Mozilla to start at windows startup to improve first window opening time
(Reporter)

Comment 37

17 years ago
Created attachment 35056 [details] [diff] [review]
Everything; new and improved
(Reporter)

Comment 38

17 years ago
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 40

17 years ago
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

17 years ago
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)
Depends on: 81706, 81708, 81712, 81714, 81715

Comment 42

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

Comment 43

17 years ago
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

17 years ago
Please check this in, my $.02...

Comment 45

17 years ago
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

17 years ago
at the request of cathleen, sr=alecf

Comment 47

17 years ago
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.
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 ;) 
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.
Anything is better than "turbo". The old "server" was serious and correct.
Command line option names are not the right place for jokes, IMO.
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

17 years ago
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.  :-)
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

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

Comment 55

17 years ago
Can someone explain the difference between this bug and bug 36283?

Comment 56

17 years ago
I hope that in "-turbo" mode, the Java VM is pre-initialized, right?
(Reporter)

Comment 57

17 years ago
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).
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. 
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

17 years ago
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

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

Comment 62

17 years ago
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

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

Comment 64

17 years ago
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

17 years ago
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

17 years ago
-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.
OS: Windows 2000 → All

Comment 67

17 years ago
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

17 years ago
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].
OS: All → Windows 95

Comment 69

17 years ago
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

17 years ago
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

17 years ago
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

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

Comment 73

17 years ago
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

17 years ago
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

17 years ago
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.
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

17 years ago
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

17 years ago
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.
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.

Updated

17 years ago
Depends on: 83139

Comment 80

17 years ago
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

17 years ago
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

17 years ago
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

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

Comment 84

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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.
> 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

17 years ago
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

17 years ago
I filed two bugs (bug 83366 and bug 82804) which are related to turbo mode
issues. In performance newsgroup, cathleen@netscape.com suggested to link any
related bug to #75599. Hoping I didn't make a big mistake by marking them as
blockers to 75599 :)

Updated

17 years ago
Depends on: 83366

Updated

17 years ago
Depends on: 82804

Comment 91

17 years ago
"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 ?).

Updated

17 years ago
Depends on: 83569

Comment 92

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

Comment 93

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

Comment 94

17 years ago
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
(Reporter)

Comment 95

17 years ago
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?
Keywords: review
(Reporter)

Comment 96

17 years ago
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.
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 97

17 years ago
Adding bug 83873, "-turbo prevents windows from getting focus when opened".
Depends on: 83873

Updated

17 years ago
Depends on: 83879

Comment 98

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

Updated

17 years ago
Blocks: 83882

Comment 99

17 years ago
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.
No longer blocks: 83882

Updated

17 years ago
Depends on: 81149
No longer depends on: 83879
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.

Updated

17 years ago
Depends on: 83995

Updated

17 years ago
Depends on: 85984

Updated

17 years ago
No longer depends on: 85984

Updated

17 years ago
Depends on: 86021

Updated

17 years ago
Depends on: 85984

Updated

17 years ago
Whiteboard: [nav+perf]

Updated

17 years ago
Depends on: 84882

Updated

17 years ago
Depends on: 86761
Moving this out as it is just a tracker bug, we are not fixing anything for this
bug in mozilla0.9.3. 
Target Milestone: mozilla0.9.3 → mozilla1.0

Comment 102

17 years ago
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?

Updated

17 years ago
Depends on: 86976

Updated

17 years ago
Depends on: 86977

Updated

17 years ago
Depends on: 87033

Updated

17 years ago
Depends on: 87053

Updated

17 years ago
Depends on: 86902

Comment 103

17 years ago
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

17 years ago
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

17 years ago
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 ;)

Updated

17 years ago
Blocks: 87379

Updated

17 years ago
Depends on: 88324
Depends on: 88630
Depends on: 88729

Updated

17 years ago
Depends on: 89157

Updated

17 years ago
Depends on: 89165

Updated

17 years ago
Depends on: 89166

Updated

17 years ago
Depends on: 89170

Comment 106

17 years ago
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
Depends on: 89504, 89505, 89511

Updated

17 years ago
Depends on: 89532

Updated

17 years ago
Depends on: 87035

Updated

17 years ago
Depends on: 85437

Updated

17 years ago
Blocks: 90466
updating summary to indicate this is now a tracking bug. 
Assignee: law → vishy
Keywords: meta
Summary: Enable Mozilla to start at windows startup to improve first window opening time → [META] Turbo mode tracking bug

Updated

17 years ago
Depends on: 82657

Updated

17 years ago
Depends on: 85308

Updated

17 years ago
Depends on: 83079

Updated

17 years ago
Depends on: 86067

Updated

17 years ago
Depends on: 86904

Updated

17 years ago
No longer blocks: 87379

Updated

17 years ago
Depends on: 87379

Updated

17 years ago
Depends on: ? 88973, 895
No longer depends on: ? 89532

Updated

17 years ago
Depends on: ? 89424
No longer depends on: ? 89511

Updated

17 years ago
Depends on: ? ?
No longer depends on: ? ?

Updated

17 years ago
No longer blocks: 90466

Updated

17 years ago
Depends on: ? ?
No longer depends on: ? ?

Updated

17 years ago
Depends on: ? ?
No longer depends on: ? ?

Updated

17 years ago
Depends on: ? ?
No longer depends on: ? ?

Updated

17 years ago
Depends on: ? ?
No longer depends on: ? ?

Updated

17 years ago
Depends on: ? ?
No longer depends on: ? ?

Updated

17 years ago
Depends on: ? ?
No longer depends on: ? ?

Updated

17 years ago
Depends on: ? 88840
No longer depends on: ? 89505

Updated

17 years ago
Target Milestone: mozilla1.0 → mozilla0.9.5

Updated

17 years ago
Depends on: ? ?
No longer depends on: ? ?

Updated

17 years ago
Depends on: ? ?
No longer depends on: ? ?

Updated

17 years ago
Depends on: ? ?
No longer depends on: ? ?

Updated

17 years ago
No longer depends on: 89424

Updated

17 years ago
Depends on: 97326

Updated

17 years ago
Depends on: 95894, 96936

Updated

17 years ago
Depends on: 89956

Updated

17 years ago
Depends on: 95142

Updated

17 years ago
Depends on: 98770

Updated

17 years ago
Depends on: 98805

Updated

17 years ago
Depends on: 98959

Comment 108

17 years ago
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

Updated

17 years ago
Depends on: 99199

Updated

17 years ago
Depends on: 99318

Updated

17 years ago
Depends on: 99321
--> Pchen
Assignee: vishy → pchen

Comment 110

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

Updated

17 years ago
Depends on: 99470

Comment 112

17 years ago
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.
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Updated

17 years ago
Depends on: 99129
Todd/Sol - What's the short list of requirements (i.e. listed bugs) we must
resolve, for the next release?

Updated

17 years ago
Depends on: 99117

Updated

17 years ago
Depends on: 99387

Updated

17 years ago
Depends on: 99681

Updated

17 years ago
Depends on: 99646
Bug 99681 (WinXP: App does not launch in turbo mode if talkback is installed)
No longer depends on: 99117, 99387, 99646
Bug 100319 (Turbo: Hangs or does allow Windows 98 to shut down)

Adding this one to the list for review.
Depends on: 100319

Updated

17 years ago
Depends on: 84937

Updated

17 years ago
Depends on: 92348

Updated

17 years ago
Depends on: 82722

Updated

17 years ago
Depends on: 94769

Updated

17 years ago
Depends on: 77505

Updated

17 years ago
Depends on: 91905

Updated

17 years ago
Depends on: 98445

Updated

17 years ago
Depends on: 98736

Updated

17 years ago
Depends on: 99292

Updated

17 years ago
Depends on: 99940

Updated

17 years ago
Depends on: 87038

Updated

17 years ago
Depends on: 100385

Updated

17 years ago
Depends on: 100336

Comment 116

17 years ago
Here is my current short list:

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

Updated

17 years ago
Depends on: 100516

Updated

17 years ago
Depends on: 99117, 99387, 99677

Updated

17 years ago
Depends on: 89677
No longer depends on: 99677

Updated

17 years ago
Depends on: 99677
No longer depends on: 89677

Updated

17 years ago
No longer depends on: 84937
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)

Updated

17 years ago
Depends on: 100625

Updated

17 years ago
No longer depends on: 99292

Updated

17 years ago
Depends on: 100699

Updated

17 years ago
No longer depends on: 100699
updating 'stop-ship' short list:

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

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

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


99940 [---, law@netscape.com] - -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, law@netscape.com] - Turbo: Hangs or does allow Windows 98
to shut down
(Status = No patch; maybe dropped as a priority for shipment)


98736 [---, bnesse@netscape.com] - 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 [---, namachi@netscape.com] - [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+)


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.

Updated

17 years ago
Depends on: 98182
Adding Bug 89781
Depends on: 89781

Updated

17 years ago
Depends on: 101263

Updated

17 years ago
Blocks: 101144

Updated

17 years ago
No longer blocks: 101144

Updated

17 years ago
Depends on: 101144

Updated

17 years ago
No longer depends on: 91129

Updated

17 years ago
No longer depends on: 95894

Comment 121

17 years ago
mass moving mozilla0.9.6 bugs to mozilla0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Updated

17 years ago
No longer depends on: 100385

Comment 122

17 years ago
Moving this meta bug to mozilla0.9.8
Depends on: 100385
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Comment 123

17 years ago
taking
Assignee: pchen → trudelle

Updated

17 years ago
Target Milestone: mozilla0.9.8 → mozilla0.9.9
See also: Bug 127122

Comment 125

17 years ago
Adding bug 26718, as this means that quick launch does not work in combination
with dial-up networking.
Depends on: 26718
This is META tracking bug with a TM for Mozilla 099. Suggest we move it to TM
1.2 or Future.

Updated

17 years ago
Target Milestone: mozilla0.9.9 → mozilla1.0

Comment 127

17 years ago
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

17 years ago
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.

Updated

17 years ago
Depends on: 131665

Updated

17 years ago
Depends on: 132641

Comment 129

17 years ago
Removed 26718 and replaced with 133108
Depends on: 133108
No longer depends on: 26718

Updated

17 years ago
Target Milestone: mozilla1.0 → mozilla1.0.1

Updated

17 years ago
Depends on: 99848

Updated

16 years ago
Depends on: 135686

Comment 130

16 years ago
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 132

16 years ago
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

16 years ago
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

16 years ago
Thanks Marlon, it is actually bug 18795.  
Adding paul, scott, and evelyn.

Comment 136

16 years ago
er,... bug 108795

Updated

16 years ago
Depends on: 130915

Updated

16 years ago
No longer depends on: 135686

Updated

16 years ago
Depends on: 133120

Updated

16 years ago
No longer depends on: 100336

Updated

16 years ago
No longer depends on: 99199

Updated

16 years ago
No longer depends on: 131665

Updated

16 years ago
No longer depends on: 99129

Updated

16 years ago
Depends on: 144235

Comment 137

16 years ago
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.

Updated

16 years ago
No longer depends on: 144235

Comment 138

16 years ago
Mass moving all of my open Nav/toolkit bugs to new owner.
Assignee: trudelle → sgehani

Comment 139

15 years ago
retargeting
Target Milestone: mozilla1.0.1 → Future
No longer depends on: 101500
Depends on: 101329, 147223
No longer depends on: 81714, 83139, 87379, 88840, 89170, 89505, 89511, 90466, 98182, 130915
Depends on: 87831

Comment 140

14 years ago
(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. :-(

Updated

12 years ago
Assignee: samir_bugzilla → nobody
QA Contact: jrgmorrison
Target Milestone: Future → ---
=> WONTFIX - turbo is gone after SM v1.1
Status: NEW → RESOLVED
Last Resolved: 9 years ago
QA Contact: cmd-line
Resolution: --- → WONTFIX

Updated

9 years ago
Component: Cmd-line Features → Cmd-line Features
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.