As we move from xpfe to toolkit, we're going to loose the splash screen implementation which we would like to keep. I've filed this under SeaMonkey for now as it'll possibly end up as a SeaMonkey only extension, we can always move it to toolkit if necessary.

The basic support (hooks) for loading a splash must go into XULRunner's startup if we want to base SeaMonkey on it and have a splash, I believe...

> we're going to loose the splash screen implementation > which we would like to keep. Why do we need to keep it? How do the FF/TB splash-screens work?

(In reply to comment #2) > Why do we need to keep it? How do the FF/TB splash-screens work? They don't have one.

Really? So does Portable Firefox have its own spalsh screen code? Maybe we could copy-paste from there?

http://forums.mozillazine.org/viewtopic.php?t=433495 [EXT] Splash screen - Pre 1.0 (Runs on: Flock, Firefox) The code in this extension is probably not relevant to this bug but I'm filing this comment just in case.

FWIW, a splash screen is a *very* frequent request for (custom) xulrunner apps. I'd estimate that for 60% of all app vendors, this is a hard requirement.

This really belongs into XRE Startup, it needs at least hooks to be implemented there.

I recently created a XULRunner-based app that will be predominantly run from CD. This caused a long startup time with no feedback, resulting in users launching the app more than once. Another developer in the company ended up writing our own app which shows a splashscreen, launches our XULRunner app, then removes the splash screen once XULRunner is up and running. This was a lot of extra effort to create and results in an extra application starting up and running for no particularly good reason. I'd love to have a splashscreen that comes up early in the XULRunner startup, possibly with a progress bar. The user should be able to dismiss it by clicking on it, though, to prevent other applications effectively being blocked by an immovable splashscreen image.

Can someone please clarify what needs to be done in order to get this fixed? Pointers like where to start looking and what exactly needs to be done for the splash screen UI in the scope of the current bug are appreciated. I'm willing to invest some time on this, and in order to do so, I will need to know: a) where in the code I should start looking, and what documentation is available on that part of the code? b) what is the goal of this bug exactly? Is it simply a few hooks on which XUL apps can register to show a splash screen, or should a default one be provided and allowing apps to customize it via XUL overlays (and possibly turning it off by setting a flag)? Thanks!

In response to comment #10 with reference to (b), for my needs I don't require anything as sophisticated as customising it via XUL overlays. Just a simple image will do. A default image could be supplied which "advertises" XULRunner. This image could then be replaced by developers for custom apps, or removed entirely if no splash screen is required. They key point is that it should appear almost immediately after the user has launched the application. Any noticeable delay before the splash screen appears will result in users who end up launching multiple instances of an app.

> what is the goal of this bug exactly? You put an image as PNG file somewhere (hardcoded path relative to application.ini probably), and if splash screen feature is enabled and the file exists, it is shown as pretty much first thing after the app starts, and disappears when either the first (or main?) XUL window shows or when something went wrong during startup. You want to hook somewhere into main() or something quickly thereafter, probably look at xulrunner/app/nsXULRunnerApp.cpp, xulrunner/xulrunner/stub/nsXULStub.cpp and toolkit/xre/nsAppRunner.cpp:XRE_main()

What needs to be initialized before a splash screen can be shown? Are there any libraries (for example, image libs) which need to be initialized in order to display the PNG file? Since the splash screen's image should be contained in a window, is there anything which needs to be initialized before I can show a window?

I have implemented a workaround for this problem and thought I'd share with you guys. Essentially I open a splash xul file with the splash image, and open the real window from the onload() of the splash window. I made the splash window chrome-less by setting hidechrome=true. The splash can be closed either by the timer or by the main window whichever happens first. Here's some code snippets: splash.xul: ----------- <?xml version="1.0"?> <?xml-stylesheet href="chrome://global/skin/" type="text/css"?> <!-- NOTE: hidechrome below --> <window hidechrome="true" title="My App Name" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> <image id="splashImg" src="icons/splash.gif" /> <script src="splash.js"/> </window> splash.js --------- function done() { close(); } function onload() { centerWindow(605,282); w = window.open(CHROME_ROOT+"/main.xul", "splash", "chrome,centerscreen", window); // If you want to close the splash screen upon click, // uncomment line below //$('splashImg').onclick = done; setTimeout("done();", 30000); } main.xul -------- <?xml version="1.0"?> <?xml-stylesheet href="style.css" type="text/css"?> <!-- your main xul code --> main.js ------- function onload() { //... do your init ... var splashWin = window.arguments[0]; /* close splash if in case it's still open */ if (splashWin != null) { try { splashWin.close(); } catch (e) {} } }

Bug 481494 is a start.

Bug 506217 turns on the splash screen for Firefox Mobile (WinCE) builds. This is pure build config (plus some suitable images of course).

(In reply to comment #16) > Bug 506217 turns on the splash screen for Firefox Mobile (WinCE) builds. Bug 504750 was Firefox. Bug 506217 will be SeaMonkey (and maybe the other applications in c-c). Not sure on which one(s) this bug depends.

Songbird does it in last versions

For reference: The legacy WinCE splashscreen code was removed in bug 653333, so any approach here (if this is still desired) will need to take that into account.

Are there any updates on this? It is still marked as NEW though it was first posted 2006-03-08 01:05 PST by Mark Banner. SeaMonkey 2.13 still takes at least a minute to load with no visible activity on Windows 7 on a Toshiba Satellite with a Quad Core processor. As a side note, this version of SeaMonkey now appears to always do an active extension/add-on check prior to loading the profile. I know this because the Profile Manager starts because I have two profiles. As was stated in a closed bug, ideally the program should load faster so users don't think it has crashed. However, in the real world the user needs to know the program is loading.

xulrunner is no more, and there doesn't seem to be a demand for this any more. If SM/TB still want a splash screen, then its something they'll need to investigate and then work out what code needs adding, and file appropriate bugs that can move forward. I don't see FF/toolkit working on this at the moment.