35866 - Need to show progress/status strings in splash screen

Status: RESOLVED WONTFIX

(Core :: XUL, defect)

Description

[Simon Fraser [no longer active]]

Lots of Mac users are reporting that their machines have crashed the first time 
they run NS 6, because of the extremely long delay on the first startup (when it 
does autoreg).

We need to be able to draw a status string in the splash screen to show progress 
at this time, and during normal startup.

Comment 1

[Suresh Duddi (gone)]

What I can do is make xpcom send out messages to an observer 
(xpcom-init-observer) and (xpcom-autoreg-observer). XPFE can then add itself 
via the observer service and display the messages.

Is that acceptable ? I can work on the xpcom portion of this.

Comment 2

[Suresh Duddi (gone)]

Another interesting one for ray.

Comment 3

[Ray Whitmer]

It sounds like a reasonable solution.  But a progress bar relies on continuous 
updating, not just a one-time call.  It seems reasonable that the init observer 
would be called once when initialization started, and once when it was finished, 
and the autoreg could also be called once as it was started, once for each file,  
and once when finished.  I believe that while we are doing it, a shutdown 
listener should be defined, to handle shutdown-related stuff, again, called once 
at the start of the shutdown, and once after it is complete.

But, it worries me what the state of the system will be when the init and 
autoreg observers are called back.  They cannot expect to rely on any component 
manager objects because the state of the components will be in flux.

Comment 4

[Ray Whitmer]

I am inclined to make this NOT fixed in M16.  It introduces new problems if code 
is called back during startup, when components will be in a flakey state.  
Going, going...

Comment 5

[Simon Fraser [no longer active]]

I think we'll need some code that does not rely on any components having been 
loaded. So you need some kind of observer mechanism, such that observers can be 
implemented in platform-specific code (like the splash screen itself).

Since so many users reported that Mozilla crashed on startup with PR1, because 
startup time is so long, I think this is an important beta2 feature. Nominating 
as dogfood for review by PDT.

Comment 6

[leger]

Putting on [nsbeta2+][5/16] radar.  This is a feature MUST complete work by 
05/16 or we may pull this feature for PR2.

Comment 7

[Ray Whitmer]

We have a problem of how to register observers before xpcom is started since the 
observer service would not be available.  Even a startup observer would be 
possible (as long as it would only called after startup is complete) and help 
solve problems, allowing additional observers to be registered, if we could just 
solve how a startup observer is registered before xpcom starts.  It is not clear 
how to do this without implementing a different observer mechanism.  I suspect 
there are more requirements lurking under the surface.

I believe that given the short time available, we do not have time to work these 
issues out right now.  As such, I intend to supply only an autoregistration 
observer, and to require the registration of that observer after xpcom has been 
initialized.  Is this still useful?

Comment 8

[Ray Whitmer]

I am trying to decide what to pass to an autoregistration observer.

I have ruled out a total count, because given the logic to determine which 
components need to be registered across various loaders, it does not seem to be 
a number that can be inexpensively derived.

Passing the filename of the component being autoregistered also is difficult.  
This is because while the Notify API prescribes Unicode strings, it is likely 
that the character mapping components themselves have not been loaded, and hence  
only native / binary versions of the file name is available.

We could cast native bytes into native words and pass them as though they were 
Unicode, allowing the recipient to cast them back.  But is the better 
alternative to choose some other mechanism than the established observer 
mechanism?

Or is a simple set of callbacks with no information at all about the actual 
progress or current component acceptable?

Comment 9

[Simon Fraser [no longer active]]

Oh what a can of worms this is turning out to be.

1. Registering observers before the XPCOM observer service is available:
   To be able to do this without depending on XPCOM, you'll just have to use
   regular C++ classes. I guess we'd need something like an 
   nsStartupProgressBroadcaster in XPCOM, with which clients can register. You
   could have observers of this broadcaster implement an interface (which may or
   may not be XPCOM), but of course no-one should be forced to use the service
   manager to get to it. That means they will have to link with XPCOM and address
   the nsStartupProgressBroadcaster directly. Linkage with XPCOM probably already
   happens everywhere we need this.

2. Tough. For now, I think we should just pass around char*s and have the autoreg
   broadcaster send through the file name. Other strings will come from platform-
   specific resources, so will use the standard OS encoding.

Comment 10

[Ray Whitmer]

I added support for an AutoRegistration observer, which receives events when 
autoregistration starts/stops as well as when native or js components register 
or unregister.  You register for this the same way you register for th4e 
shutdown observer.  It must occur after initialization of xpcom, since the 
service manager is required to get the ObservationService, which is required to 
register an observer for notifications.  

You just need to get the ObserverService, and call AddObserver, with a topic 
described by the macro NS_XPCOM_AUTOREGISTRATION_OBSERVER_ID defined in 
nsIServiceManager.h.

Comment 11

[Ray Whitmer]

Reassigning to sfraser, so he can do or get people to do the GUI parts.

Comment 12

[Simon Fraser [no longer active]]

cc pavlov for linux love

Comment 13

[Simon Fraser [no longer active]]

This is limping along on mac -- the splash screen shows progress for autoreg, but 
not much else.

Bill -- we need to keep the splash screen around until just before the first 
window comes up, so that we can show progress for reading prefs, bookmarks etc.
Currently, it goes away before the profile picker. In 4.x, the profile picker 
just comes up on top of the splash screen.

Reassigning to law to fix Windows, and make the splash screen persist for longer.

Comment 14

[don]

Move to M19.

Comment 15

[leger]

Putting on [nsbeta2-] radar. Removing [5/16]. Missed the Netscape 6 feature 
train.  Please set to MFuture.

Comment 16

[leger]

Putting on [dogfood-] radar since [nsbeta2+] already indicated.

Comment 17

[leger]

Actually - Putting on [dogfood-] radar since [nsbeta2-] already indicated.

Comment 18

[Bill Law]

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

Comment 19

[Grace Bush]

adding myself to cc list 

Comment 20

[Claudius Gayle]

update: on mac with a 200071709 build, the splash screen comes up and only 
displays progress for autoreg like sfraser said.

on Windows with 2000072109 build, I get a brief splash screen - no progress info
and it disappears when the profile manager appears.

On Linux I get no splash screen whatsoever.

Comment 21

[johng]

nav triage team:
nsbeta3-,editing summary and OS to Windows since bug has evolved to Win only.  
Start up is fast enough on Win so we can live without the progress bar.

If you like, you can open a new bug if you like for Mac

Comment 22

[Daniel Veditz [:dveditz]]

Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.

Comment 23

[leger]

Updating QA Contact

Comment 24

[Bill Law]

I have code for this (have had, for quite some time).  But the bitmap in the 
Netscape commercial build doesn't have room for any text.  Was the Mac .pict 
file modified to make room.  I have remarked on this elsewhere (the bug calling 
for new splash screens for each PR release) but it's still a problem.

Comment 25

[Tim Powell]

This bug's been dormant for a long time and it still feels like Mozilla hangs 
at start up because nothing happens with the splash screen on Windows. Can we 
get this checked in? What size/format does the image need to be?

Comment 26

[Simon Fraser [no longer active]]

nsNativeAppSupportWin needs to implement nsIObserver, and update its progress 
string in the Observe call. See nsNativeAppSupportMac.cpp for an example.

The text needs to be a native window or dialog text item (not just an image), and 
should draw over the lower portion of the image.

Comment 27

[Bill Law]

Simon, as I mentioned a while back, I've implemented the code (it's kicking
around somewhere still on my machine).  The bug never got high enough priority
to get into the Mozilla code otherwise known as NS6.

There's still the problem that the NS6 splash screen (on Windows) doesn't have
any room to overlay this status information.  My code overlays the copyright text.

None of that is of concern to Mozilla, though.  I'll nominate this for nsbeta1
(Mozilla 0.8/0.9) and see what happens.  If we screw up the Netscape splash
screen, probably somebody will be compelled to fix that splash screen.

BTW, how is the text overlaid on the Mac splash screen for NS6?  Does the Mac
version have a black band across the bottom where the Windows version doesn't?

Comment 28

[Simon Fraser [no longer active]]

I carefully aligned the text to fit under the NS6 copyright. I think I had to 
move the contents of the splash image up slightly to make room for it.

Comment 29

[Bill Law]

Attachment: Patch

Comment 30

[timeless]

+mailIcon ICON "mail.ico"
looks out of place.

can we try and get this onto the branch?

Comment 31

[Matthew T (active 1999-2002)]

Looks like this patch has been slightly mixed up with a patch for bug 57576.

Comment 32

[Bill Law]

Yes, the mail icon is residue from another bug fix.  What branch are you
speaking of?  mozilla0.8?  I don't think it's that big of deal because you don't
see much useful info anyway (basically, "component registration finished" or
some such).  We should look to maybe add "loading bookmarks" and similar
messages.  Of course, others argue we should just make those fast...

Comment 33

[Stephen Walker]

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

Comment 34

[Bill Law]

Attachment: Updated patch to work with new splash screen at http://www.crosswinds.net/~ggc/

Comment 35

[Mike Young]

Can we get this patch checked in? Its very weird to have that black space below
the splash screen with no status like 4.x 

Also, does this bug include "loading bookmarks" "initializing plugins" etc.
Those are very helpful when you are wondering what's taking mozilla so long.
Also, for all those people who think this will slow down mozilla, in fact
usability studies have shown that moving objects and changing text make
activities "appear" to go faster. (Why do you think M$ put useless animated
icons in all of their dialogs?) 

Comment 36

[Bill Law]

+, mozilla0.9.1  The code is done, we just need to iron out some
legalistic/artistic issues with the splash screen graphics.

Comment 37

[Viswanath Ramachandran]

as discussed in team meeting, moving all Nav+ team members nsbeta1+ P3 bugs from 
mozilla0.9.1 to mozilla0.9.2. 

Comment 38

[basic]

If the code is done, couldn't it work with the current splash screen that loads
in Mozilla (win32) ?

Comment 39

[basic]

If the code is done, couldn't it work with the current splash screen that loads
in Mozilla (win32) ?

Comment 40

[Bill Law]

Yes, although the latest patch probably draws on top of the copyright statement
or something.

It also doesn't work with at least one other Mozilla vendor's splash screens.

Comment 41

[basic]

Currently the splash screen has no copyright statement to my knowlege, and
couldn't this feature be turned off for that particular vendor? By the way,
shouldn't bug 62209 depend on this bug rather the other way around?

Comment 42

[Bill Law]

The code is pretty much done.  The patch might have to be rejiggered (it's a 
bit stale).

This will not work with the Netscape splash screen.  That splash screen will 
have to be fixed to work with this code.  That shouldn't be hard, though (just 
need to add black band at the bottom as per the Mac's splash screen).

Comment 43

[Bill Law]

P.S. Anybody should be able to take that patch, fix it up, and check it in.  
Requires minimal Win32 expertise.

Comment 44

[Simon Fraser [no longer active]]

Note that on Mac, the progress text appears in different places, and with a 
different background color, in Mozilla and Commercial builds.

Comment 45

[Bill Law]

I was thinking of handling that by using Win32 resources to specify color and
position.  We don't have separate Netscape-only code in the Windows executable.
 But we do have separate resources (for the splash screen and a couple of other
things) so we could add new ones for those values.

How is that controlled on the Mac?

Comment 46

[Viswanath Ramachandran]

nav triage: this is not an rtm stopper, its nice to have. moving to m0.9.3. 
anyone who has the cycles to take and fix this, help would be very welcome. 

Comment 47

[Blake Ross]

Looking at this while law's on sabbatical.

Comment 48

[Blake Ross]

Attachment: updated patch

Comment 49

[Blake Ross]

I read through this bug, it seems to be covering a couple things:

* Keeping the splash screen up even during the profile manager
* Adding strings for all the aspects of startup ("Importing Bookmarks", etc.)
* Adding the ability for Windows to display strings in the splash screen

This slightly modified patch only accomplishes the last item (so it only has the 
registration progress info).  Is it worth getting that in before tree closure?

Comment 50

[Simon Fraser [no longer active]]

* Keeping the splash screen up even during the profile manager
* Adding strings for all the aspects of startup ("Importing Bookmarks", etc.)

We need a new XP bug for these items. Mac needs them too.

Comment 51

[Blake Ross]

Okay, so I guess I'll go ahead and get this in (it can't hurt, although the 
feedback it provides is only marginally more useful).

r/sr, anyone?

Comment 52

[Blake Ross]

Simon, sr?

Comment 53

[Simon Fraser [no longer active]]

Comments:
Can you macroize the QI, AddRef, Release etc. in nsNativeAppSupportBase.cpp and 
nsNativeAppSupportWin.cpp.

In nsNativeAppSupportWin.cpp, you're hard-coding the text position in the dialog. 
This is bad, because the text needs to be in a different position for Mozilla and 
Netscape builds (and we don't want to have to fork the code for this).

On Mac, we use resources to position the text. Can you do the same for Windows?

Comment 54

[Blake Ross]

Macroize how (what QI?)?

Sure, I'll see if the position can be configurable from resource files...

Comment 55

[Simon Fraser [no longer active]]

It looks like the patch touches AddRef/QueryInterface methods that are written 
long-hand. You could change these to use NS_IMPL_ISUPPORTS2 or whatever.

Comment 56

[Peter Trudelle]

Mass moving lower-priority bugs to 0.9.6 (with Blake's pre-consent) to make room
for remaining 0.9.4/eMojo bugs and MachV planning, performance and feature work.
 If anyone disagrees with the new target, please let me know.

Comment 57

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 58

[Zach Lipton [:zach]]

ping, ping. blake: how goes this?

Comment 59

[Bill Law]

Attachment: Updated patch with additional features

I've updated this patch and have added a few new features:

1. It now gets the parameters for where to draw the text (and in which color)
from resources defined in splash.rc.  This means we can customize this now for
the splash screen used in the Netscape commercial builds.

2. I've modified the splash screen logic so that it opens another splash screen
after the profile manager window goes away.  That's because much more time
elapses after that window is dismissed than before it appears.

3. I've added a new nsIObserverService topic so that the status text can be
updated from anywhere.	As an example, I put "Opening
chrome://navigator/content/navigator.xul..." on the splash screen while the nav
window is loading.

Some of this breaks the Mac, since the Mac doesn't implement
nsINativeAppSupport (only nsISplashScreen).  It should be very easy to enable
this for the Mac (we can use nsNativeAppSupportBase, which will use the
existing nsISplashScreen implementation to implement the splash screen
methods).

This code needs some additional cleanup to make the "Opening <chrome-url>..."
message localizable.  Also, we might want to sprinkle other splash screen text
updates elsewhere in nsAppRunner.cpp.  There's some lengthy spots where no
useful text displays.

Comment 60

[Blake Ross]

-> law

Comment 61

[Grey Hodge (jX)]

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

Comment 62

[Simon Fraser [no longer active]]

Attachment: Patch to implement nsNativeAppSupportMac

Comment 63

[Bill Law]

I'm not sure how badly we really want/need this; setting target milestone.

Comment 64

[Simon Fraser [no longer active]]

I have a 0.9.9 bug that is blocked by this, bug 66898. So would like it in 0.9.9, 
as we discussed.

Comment 65

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 66

[Chris Lyon]

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

Comment 67

[Jason Kersey]

nomination love.  99 is over, nominating for 1.0 and machv.

Comment 68

[Peter Trudelle]

nsbeta1- per Nav triage team, ->1.2

Comment 69

[Tony Tovar]

Come on guys, do *something* with this before 1.0!  At least put a "Loading..."
message up.  As it is, the black bar across the bottom of the splash screen
makes it appear to be a corrupt image-file.

Comment 70

[Chris Lyon]

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

Comment 71

[WD]

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

Comment 72

[Chris Lyon]

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

Comment 73

[Brian 'netdragon' Bober]

What's the current status/progress for this bug?

Comment 74

[Julius Schwartzenberg]

What about Linux?

Comment 75

[R.K.Aa.]

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

Comment 76

[Andreas Kunz]

pepperxn: 
why do you think this bug should block the release of Mozilla 1.4b???
Do you think it makes much sense to hold it for a bug with no real for more than
a year? And a bug many Mozilla releases had and still were a success?

I just saw that 15 of the currently 72 'blocking1.4b?' requests were issued by you!
Unfortunately this one is not the only one of those 15 where I doubt the need to
block 1.4b for:
Bug 193309 (filed by you without specific component and explanation)
Bug 77104 (minor and not very important imo)
Both (and possibly more, along with this bug) make me wonder if you overestimate
your evaluation skills or just misuse the 'blocking1.4a' flag when you do more
than 20% of the requests.
This flag is definitely not meant as a way to try forcing people to fix bugs
you'd like to see fixed.

Comment 77

[Brian 'netdragon' Bober]

Until there is a patch for this has reviews, its not important enough to block
1.4b. We are not going to stall the release of a beta so that someone can come
and spend the 5 full days or so it takes to fix this. I understand you think its
important, and it is... But there are much more important things to contend with
in the eyes of developers -- security issues, etc. Let's not waste drivers'
time, use discernment with the flags.

Resetting out of date milestone. Adding keywords: "polish, helpwanted" removing
"mozilla1.0 and nsbeta1-"

Changing OS to all since this is an issue on Linux too if you use "Mozilla -splash"

Comment 78

[Ere Maijala (slow)]

Attachment: Patch to make status updates work on Windows

This patch is from timeless. The only thing I changed is the position of the
text on the splash screen. Now there's just one problem with this regarding
autoreg. Currently the splash screen can't be shown before xpcom init is done,
so it's displayed too late to be able to tell what's happening with autoreg.

Comment 79

[timeless]

Comment on attachment 121209 [details] [diff] [review]
Patch to make status updates work on Windows

i'll correct 'obserer'

with this basic status landed it will be easier to make further improvements

Comment 80

[Ere Maijala (slow)]

Comment on attachment 121209 [details] [diff] [review]
Patch to make status updates work on Windows

The splash screen won't go away when it has been displayed again after choosing
a profile in Profile Manager.

Comment 81

[Ere Maijala (slow)]

Attachment: Fixed patch to make status updates work on Windows

Cleaned up and fixed patch to make it work on Windows. This is now able to show
some basic status information and the splash screen is correctly hidden when a
real window opens.

Comment 82

[Ere Maijala (slow)]

All this said and done, I'll repeat my concerns. I'm not sure if this is the
best way to do it. Now we rely on observers which need xpcom which isn't
available soon enough to be really useful. 

Comment 83

[Grey Hodge (jX)]

With a year and a half having gone by, and Firefox not even having a splash,
should this maybe move to WONTFIX and be done with it?

Comment 84

[Aaron Kaluszka]

And if Seamonkey started up nearly as fast as Firefox, that's something that
could be done.

Comment 85

[Brian 'netdragon' Bober]

In other words, this is a Seamonkey bug. Bill Law is inactive in the project
(afaik). Reassigning.

Comment 86

[Robert Kaiser]

The splash screen isn't supported at all any more on the "new toolkit" platform that all Mozilla apps are using now, so we can't fix this.