Need to show progress/status strings in splash screen




18 years ago
4 years ago


(Reporter: Simon Fraser, Unassigned)


({helpwanted, polish, pp})

helpwanted, polish, pp
Dependency tree / graph
Bug Flags:
blocking1.4b -
blocking1.4 -

Firefox Tracking Flags

(Not tracked)


(Whiteboard: time:.5days)


(3 attachments, 4 obsolete attachments)



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

18 years ago
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.
Target Milestone: --- → M16

Comment 2

18 years ago
Another interesting one for ray.
Assignee: dp → rayw

Comment 3

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

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

18 years ago
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.
Keywords: dogfood


18 years ago

Comment 6

18 years ago
Putting on [nsbeta2+][5/16] radar.  This is a feature MUST complete work by 
05/16 or we may pull this feature for PR2.
Keywords: nsbeta2
Whiteboard: [nsbeta2+][5/16][dogfood-]

Comment 7

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

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

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

Comment 9

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

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


18 years ago
Assignee: rayw → sfraser

Comment 11

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

Comment 12

18 years ago
cc pavlov for linux love

Comment 13

18 years ago
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.
Assignee: sfraser → law

Comment 14

18 years ago
Move to M19.
Target Milestone: M16 → M19

Comment 15

18 years ago
Putting on [nsbeta2-] radar. Removing [5/16]. Missed the Netscape 6 feature 
train.  Please set to MFuture.
Whiteboard: [nsbeta2+][5/16][dogfood-] → [nsbeta2-]

Comment 16

18 years ago
Putting on [dogfood-] radar since [nsbeta2+] already indicated.
Whiteboard: [nsbeta2-] → [nsbeta2-][dogfood-]

Comment 17

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

Comment 18

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

Comment 19

18 years ago
adding myself to cc list 

Comment 20

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

18 years ago
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
OS: Mac System 8.5 → Windows 98
Summary: Need to show progress/status strings in splash screen → Windows: Need to show progress/status strings in splash screen
Whiteboard: [nsbeta2-][dogfood-] → [nsbeta2-][dogfood-][nsbeta3-]
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.
Keywords: nsbeta3

Comment 23

18 years ago
Updating QA Contact
QA Contact: leger → gbush

Comment 24

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

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

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


17 years ago
Depends on: 62209

Comment 27

17 years ago
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?
Keywords: dogfood, nsbeta2, nsbeta3 → nsbeta1
Whiteboard: [nsbeta2-][dogfood-][nsbeta3-]

Comment 28

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

17 years ago
+mailIcon ICON "mail.ico"
looks out of place.

can we try and get this onto the branch?
Keywords: mozilla0.8

Comment 31

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

Comment 32

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


17 years ago
Keywords: mozilla0.9

Comment 33

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


17 years ago
Keywords: mozilla0.8.1


17 years ago
Keywords: mozilla0.8

Comment 34

17 years ago
Created attachment 27304 [details] [diff] [review]
Updated patch to work with new splash screen at

Comment 35

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

17 years ago
+, mozilla0.9.1  The code is done, we just need to iron out some
legalistic/artistic issues with the splash screen graphics.
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla0.9.1
as discussed in team meeting, moving all Nav+ team members nsbeta1+ P3 bugs from 
mozilla0.9.1 to mozilla0.9.2. 
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 38

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

Comment 39

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

Comment 40

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

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

17 years ago
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).
Whiteboard: time:.5days

Comment 43

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

Comment 44

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

Comment 45

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

Comment 47

17 years ago
Looking at this while law's on sabbatical.
Assignee: law → blake

Comment 48

17 years ago
Created attachment 39221 [details] [diff] [review]
updated patch

Comment 49

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

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

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

17 years ago
Simon, sr?


17 years ago

Comment 53

17 years ago
Can you macroize the QI, AddRef, Release etc. in nsNativeAppSupportBase.cpp and 

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

17 years ago
Macroize how (what QI?)?

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

Comment 55

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


17 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4


17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 56

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


17 years ago
Target Milestone: mozilla0.9.6 → mozilla1.0
*** Bug 105792 has been marked as a duplicate of this bug. ***

Comment 58

17 years ago
ping, ping. blake: how goes this?


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

Comment 59

17 years ago
Created attachment 58195 [details] [diff] [review]
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

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.
Attachment #24719 - Attachment is obsolete: true
Attachment #27304 - Attachment is obsolete: true
Attachment #39221 - Attachment is obsolete: true

Comment 60

17 years ago
-> law
Assignee: blakeross → law
Priority: P3 → --
Target Milestone: mozilla0.9.9 → ---

Comment 61

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

Comment 62

16 years ago
Created attachment 65343 [details] [diff] [review]
Patch to implement nsNativeAppSupportMac

Comment 63

16 years ago
I'm not sure how badly we really want/need this; setting target milestone.
Target Milestone: --- → mozilla1.0

Comment 64

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


16 years ago
Keywords: 4xp, pp


16 years ago
Keywords: mozilla0.9.9

Comment 65

16 years ago
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  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2

Comment 66

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

Comment 67

16 years ago
nomination love.  99 is over, nominating for 1.0 and machv.
Keywords: mozilla0.9.9 → mozilla1.0, nsbeta1
Target Milestone: mozilla1.2 → ---

Comment 68

16 years ago
nsbeta1- per Nav triage team, ->1.2
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.2alpha

Comment 69

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

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

Comment 71

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

Comment 72

16 years ago
*** Bug 182415 has been marked as a duplicate of this bug. ***
What's the current status/progress for this bug?
What about Linux?

Comment 75

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


15 years ago
Blocks: 32218


15 years ago
No longer blocks: 32218


15 years ago
Component: XPCOM → XP Toolkit/Widgets
QA Contact: gbush → sairuh


15 years ago
Flags: blocking1.4b?

Comment 76

15 years ago
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.
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"
Flags: blocking1.4b? → blocking1.4b-
Keywords: mozilla1.0, nsbeta1- → helpwanted, polish
OS: Windows 98 → All
Summary: Windows: Need to show progress/status strings in splash screen → Need to show progress/status strings in splash screen
Target Milestone: mozilla1.2alpha → ---

Comment 78

15 years ago
Created attachment 121209 [details] [diff] [review]
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

15 years ago
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
Attachment #121209 - Flags: superreview?(roc+moz)
Attachment #121209 - Flags: review?

Comment 80

15 years ago
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.
Attachment #121209 - Flags: superreview?(roc+moz)
Attachment #121209 - Flags: review?
Attachment #121209 - Flags: review-

Comment 81

15 years ago
Created attachment 121946 [details] [diff] [review]
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.


15 years ago
Attachment #121209 - Attachment is obsolete: true


15 years ago
Flags: blocking1.4?

Comment 82

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


15 years ago
Flags: blocking1.4? → blocking1.4-

Comment 83

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

14 years ago
And if Seamonkey started up nearly as fast as Firefox, that's something that
could be done.
In other words, this is a Seamonkey bug. Bill Law is inactive in the project
(afaik). Reassigning.
Assignee: law → jag
QA Contact: bugzilla → jrgmorrison


9 years ago
Assignee: jag → nobody

Comment 86

9 years ago
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.
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.