I wasn't sure where to file this, so I picked on Browser / XP Toolkit/Widgets: XUL (which is surely wrong -- feel free to fix, or to suggest a better place). Problem: Many people have built and distributed XUL apps without having to run a compiler, worry about platform-specific packaging issues, etc. We want to support such people in the new dis-integrated apps world of the Mozilla development roadmap. Those people could still use mozilla -chrome ..., or perhaps some could use MozillaFirebird -chrome ... nowadays, but wouldn't it be even better if they could use a generic MozillaAppRunner that came with the GRE (XRE, whatever)? Issues: - How to provide OS-specific application icons? - How to specify a profile directory path name? - Other issues we haven't thought of yet? The icons may have to be compiled in on some platforms. More investigation is needed. Ben points out that we could get the profile directory from a manifest file that the installer pulls out of the XPI, along with the .jar file(s). So there would be no hard-coded profile directory app-specific pathname compiled into the proposed app-runner program. Let's use this bug to brainstorm and to report results of experiments with the icon binding rules and restrictions of various OSes (mainly Windows and Mac, I bet, but Unix info is welcome too). /be

yes! We really need this desperately. One thing that's got to go right now it to move all that nsINativeAppSupport stuff into xpfe/appshell (well, another dumping ground, but its better than it being in apprunner.exe)

Adding the other point we discussed - We would be renaming .jar files to something else, .app would be nice but Apple is using it for something else presently... maybe .moz ;-) We would then create associations where applicable (e.g. windows registry) that would load foo.moz in MozAppRunner. Dan discovered that you can create custom icons for non-executable files by creating an icon handler (whatever that is... probably some service registered with the shell). The icon could be placed alongside the ".moz" file. The only remaining problem is that at least for windows the icon needs to be in a recognized format which for Win98 probably means .ico... bryner suggested that we could make the icon handler convert from a XP type (e.g. gif) to the appropriate format on Windows... although I'm not sure how well that'd perform in directory listings so an alternative if that proved slow would be to create an XP icon format converter to convert a base type (e.g. gif/png) as part of the build system. All the generated icons would be distributed with the system and the right one loaded by the applicable environment. An example of the proposed scheme on Windows.... Simple App (XUL/JS only): Program Files/Chatzilla/Chatzilla.moz <-- double click to start Program Files/Chatzilla/manifest Program Files/Chatzilla/Chatzilla.ico Complex App (XUL/JS + C++): Program Files/Firebird/Firebird.moz <-- double click to start Program Files/Firebird/manifest Program Files/Firebird/Firebird.ico Program Files/Firebird/[...]/brwsrcomps.dll ...

Actually you're better off sticking the icon into the file. In fact since you return an icon handle there's very little reason (save perf) to have a real .ico I was thinking more like .xpa for the app extension (xp app).

This is also a prime opportunity to fix the command-line argument interfaces mentioned in bug 56654. I think it would be pretty slick if this app were nothing more than the xpcshell. We might need some new components, one to spin a new event loop for example, but that's not too difficult. If it could be done without hurting startup too much (and I bet it could), that would be even better.

bug 104382 seems related

Some musings for windows http://www.bengoodger.com/software/mb/mozrunner/MozRunnerMusings.jpg Technical Docs http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_int/shell_int_extending/extensionhandlers/iconhandlers.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_int/shell_int_extending/extensionhandlers/shell_ext.asp Sample Icon Handler http://www.codeproject.com/shell/shellextguide9.asp?print=true I'm going to take a crack at some of this this week.

Super-excellent! I've been wanting something like this. Are the "icons" we're talking about platform-agnostic? (i.e. can I make one for both mac and win, and maybe even *nix) or will I need one for each platform? I can imagine a similar solution on *nix #! /usr/bin/mozapprunner to load one of these things...

I wonder if the setup work is that simple. Esp. if Benjamin fixes his "have a bunch of component dirs" bug, setting those up might require additional work. Well, that would depend on the actual arch over there. Anyway, just a jar doesn't really tell which .xul to open, or if the apprunner should just lauch a .js. Unless something like the contents.rdf of the jar tells. cat head > /dev/null

Benjamins stuff outlined in bug 209439 and http://bdsmedberg.no-ip.org/extensions.html seems to be capable of handling the dependencies of xpapps on extensions. As long as the apprunner can determine those from a setup-config.file_rdf within the jar. Which timeless wants to include the xul to be opened, as well. I can see some reason for having the chance to just run a js, too. <timeless> pike: my expectation is that there'd be some file (either manifiest, contents or a new file) <timeless> which indicated what url to load to launch the app <timeless> it'd also indicate which file extensions/mimetypes the app likes to own/handle <timeless> and it might even describe verbs (like .html=>Edit) <timeless> and it'd list any command line flags it wants handled <Pike> timeless: well, the "fix commandlinehandler" bug was referenced from that bug, so that might take care of that ;-) so much from our little discussion on #mozilla

I came up with another issue, that is, GRE versions. A generic apprunner should be GRE version aware. That means, the config file of the jar should specify the required GRE version, the apprunner should determine if it provides that, and if it doesn't, locate and lauch the apprunner of the right GRE version. I doubt that we can make the apprunner independent of a GRE, as we prolly wanna use necko to load the jar and either rdf or xml to parse to the config file.

pike: if we only use frozen methods of the GRE, we can use any GRE to load the JAR/RDF... of course, that might involve freezing large parts of RDF, which is probably beyond the pale... hrm

re #11 and frozen interfaces: nsIJARURI isn't even frozen, so freezing shouldn't count. I wouldn't expect that launching one GRE and then launching another would work anyway, I bet some parts of some libs are always incompatible. Or at least may be. I think that we'd be much better off if we just lauch the apprunner of the other GRE with the appjar we got. Yet another thing we came up with, if xpa-or-whatever should be able to provide extensions. And if, if the file to control the apprunner should be the same that drives the extensions. I favour to have different files. That way, we can adjust both formats as needed. I'm tempted to look into this bug, is there a some argument whether the config file should be rdf or xml? I feel reasonably well hacking both. On the extension/mimetype: It seems reasonable to have a new extension/mimetype, not sure about the extension, xpa would be fine for me. How about application/vnd.mozilla.gre-application ? (No idea about naming rules for mime types, as you can tell.)

OK, discussed with Pike on IRC for a while... the bootstrap sequence is a catch-22, because the XPA needs to specify a GRE, and the apprunner needs to load a GRE to read the ZIP and parse the startup config file. Solution: allow the command line to force the "local" GRE, thus --use-local-gre if the apprunner is launched "normally": load the apprunner's GRE load the config file if this GRE is not compatible, search for a compatible GRE shutdown the current GRE, and launch a new process: /path.to.correct.gre/apprunner application.xpa --use-local-gre

also, I would like to vote for an RDF config-file schema, and hope to coordinate this with the extension manager in bug 209439. It is possible that an application could also be an extension, using the same XPA file (for example, it is possible that the DOM inspector could be a standalone application, as well as an extension for multiple GRE apps).

noooo.. please no RDF we're trying to rip RDF out of the chrome registry as it is - lets not put it somewhere it doesn't need to be. Wouldn't a simple flat-file (i.e. properties) do?

> /path.to.correct.gre/apprunner application.xpa --use-local-gre That would be an optimisation in the process. I'm fine with that, but we need to parse the config data anyway. Passing all given options via the commandline would be major work, and it would keep us from extending the config data in later releases. > noooo.. please no RDF > > we're trying to rip RDF out of the chrome registry as it is - lets not put it > somewhere it doesn't need to be. Wouldn't a simple flat-file (i.e. properties) > do? As we gonna have multiple entries for a single category (like required extensions), I would prefer to have a formatted file. I'd feel good about whacking some parsing for an xml file, for example. I wouldn't wanna parse into a DOM, but create a custom content sink and hook that up to nsParser. I need to check out if I get synched loading into my head, we probably don't want to start an event queue to parse the config data.

axel: > I'm fine with that, but we need to parse the config data anyway. Passing all > given options via the commandline would be major work, I wasn't proposing parsing everything to the command line, just the GRE bootstrap. All other config information should be parsed by the new GRE, to allow for new features as you mention. alecf: what have you got against RDF? There is not a chance in hell that we can remove it from the chrome service, because every extension that currently exists declares itself through contents.rdf. RDF is a very versatile language, and at least in this case performance is not a major concern... here is a sample config.rdf that I can't possibly imagine in a flat-file configuration: <?xml blahblah?> <RDF:RDF xmlns... xmlns:xre="http://www.mozilla.org/projects/XRE/"> <RDF:Bag about="urn:mozilla:applications"> <RDF:li resource="http://somecomponent.mozdev.org/" /> </RDF:Bag> <RDF:Description about="http://jslib.mozdev.org/"> <xre:requires RDF:value="http://www.mozilla.org/GRE"> <xre:minVersion xre:release="1" xre:versionMajor="4" /> <xre:maxVersion xre:release="1" /> <!-- this XPA requires GRE version 1.4 or higher, but not a 2.x --> </xre:requires> <xre:requires RDF:value="http://jslib.mozdev.org/"> <xre:minVersion xre:release="1" xre:versionMajor="2" /> <!-- this XPA requires JSLib version 1.2 or greater --> </xre:requires> <xre:component>somecomponent.js</xre:component> <xre:component>somecomponent.xpt</xre:component> <!-- this XPA has XP components "somecomponent.js/xpt" --> <xre:component type="RDF:Alt"> <rdf:li RDF:value="bincomponent.dll" xre:platform="win32" /> <rdf:li RDF:value="bincomponent-i3.so" xre:platform="unix-intel-gcc3" /> <rdf:li RDF:value="bincomponent-x.dylib" xre:platform="macosx" /> </xre:component> <!-- this XPA also requires a binary component... it provides a win32, *nix-gcc3, and osx version... if one of these are not available, the apprunner should display an error message and exit --> <xre:chromeContents>contents.rdf</xre:chromeContents> <!-- this XPA provides chrome; the "contents.rdf" is located, surprisingly, at "contents.rdf" in this jar file. --> <xre:startURI>chrome://myprovider/content/</xre:startURI> </RDF:Description> </RDF:RDF> This would use the same RDF schema as my extension manager, and is a early shot at an RDF schema. I'm willing to elaborate and document this schema if someone wants to play with it.

lets not debate whether or not we can ditch RDF in chrome - because I believe it can be done, but the means is subject for another bug. I'd like to avoid RDF here because its a really heavyweight solution to a simple problem - it will just bloat up this generic startup mechanism.

To separate the discussion about the package data from the actual file format, I created a set of pseudo interfaces to abstract the information within a package. This tries to abstract the logic the extension manager needs to get to the data and check versions. The actual implementation will most likely be non-XPCOM. Unless we need to create a xpcom component to share the code between extension manager and apprunner.

Axel, have a look at this: I've cleaned it up a little, annotated some problem-spots, and added versioned dependencies (which I think are necessary).

I forgot at least one thing... applications (and extensions) also need to be able to specify default prefs. This might not be necessary immediately, but I'm sure some applications will need this, so we shouldn't design it out. see bug 212222

nsIPrefService has the ability to read in specific pref files, you just pass a file into readPrefFile() (sp?) so the question is, do we make prefs aware of applications in multiple places, or do we pump prefs with pref defaults when they are found? I vote for the latter - prefs shouldn't have any special knowledge that there are multiple places to read prefs from.

alecf: there is nsIPrefService.readUserPrefs but there is no method to read arbitrary *default* prefs. See bug 212222. I agree that the prefservice shouldn't need to know about this; it should be handled by the apprunner/extension manager.

Not really sure that using the prefsservice is a good idea. - We don't really want all of the config data to be visible preferences. (Though it might be cool to expose some of it, like the application name, in a standard way.) - If we went for something like mailnews does for multiple items, ie. mail.server.server1 or gre.extension.extension1.name, entries from separate packages will collide. But we may be able to make the same design as a config schema, like gre_config("gre.package.name", "http://somecomponent.mozdev.org/"); gre_config("gre.package.application.name", "http://somecomponent.mozdev.org/"); gre_config("gre.application.requires.require1.name", "http://www.mozilla.org/GRE"); gre_config("gre.application.requires.require1.minVersion", "1.4"); gre_config("gre.application.requires.require1.maxVersion", "1"); gre_config("gre.application.requires.require2.name", "http://jslib.mozdev.org/"); gre_config("gre.application.requires.require2.minVersion", "1.2"); gre_config("gre.application.components.component1", "somecomponent.js"); gre_config("gre.application.components.win32.component1", "bincomponent.dll"); gre_config("gre.application.chrome.contents", "contents.rdf"); // type = 1, windowed application gre_config("gre.application.type", 1); gre_config("gre.application.start", "chrome://myprovider/content/");

oops, that's not what I meant at all, sorry for the confusion; I didn't want to use the prefservice to implement the apprunner/extensions stuff. Rather, an application will need to be able to specify default prefs (for example, if chatzilla were launched by the apprunner, it would want to set default prefs for extensions.irc.* (these prefs would be overridden in the normal way by prefs.js and user.js). in my RDF scheme, something along the lines of XRE:prefFile="somefile.js" would work, in the pseudo-IDL scheme add this to mozIXPExtension: readonly attribute nsISimpleEnumerator /*nsIFile*/ defaultPrefFiles;

The fact that people working on core components went and used the chrome registry (which was only ever intended for use with XUL apps) is a bug in and of itself. People started using the chrome registry inside core layout components simply because no other localization mechanism existed. Core components (like necko) that have some localizable strings should be using some (much simpler) mechanism for localization and shouldn't be using the chrome registry IMO. That isn't what it was ever intended to be used for. The fact is, the relationships between applications and extensions are best represented via a graph, and RDF is perfectly suited for this sort of relationship. This is what the chrome registry was designed for. If you want to simplify it in the embedding world, invent something else. Stop using chrome URLs and stop using the XUL chrome registry.

I like this .moz idea. It seems like each .moz could have its own profile directory (and its own chrome registry/components dirs that are placed into the profile). Then you could have the relevant files extracted and cached in the profile dir across multiple launches of the same .moz file. The .moz would have to name a primary chrome package. Since each .moz would have its own prefs file, that one piece of bootstrapping could be done via a pref. We already have this pref now, although it's poorly named: browser.chromeURL. My vision of the XRE may not be as fancy as some people want. I envison a mozRunner.exe that can handle .moz files, but each unique .moz file would get its own process and its own profile directory. I see little benefit to attempting any sort of fancy out-of-process communication or to sharing chrome information between two .moz files. Because each .moz file would have its own profile dir, the chrome registry can continue to function as it does now, and extensions can be installed directly into the profile dir for that .moz file. The chrome registry and components basically need to be 2-tier, covering the XRE directory and the .moz-specific profile directory. I know there have been proposals to extend the chrome registry and component registration to be n-tier, but I simply don't see the benefit. If you have an extension like smooth scrolling that you want to make available for all .moz applications, install it into a particular XRE, and it will be available for all applications. I don't see the benefit to putting an extension like this in some arbitrary directory, since it has to be re-registered anyway with each subsequent version of the XRE, and it's likely such extensions won't be able to maintain binary compatibility across different versions of the XRE. Also, as far as application UI is concerned, e.g., Firebird's extension manager, it is not going to cover XRE extensions. It's only concerned with the user's installed extensions, so it's only going to show what's in the profile dir. I think this strikes the right balance with the goals we want to achieve. Thoughts?

> The fact that people working on core components went and used the chrome > registry (which was only ever intended for use with XUL apps) is a bug in > and of itself. OK, filed as bug 215212... I'll need to come up with a list of files which are improperly "chrome-ized" but I don't think it's that hard. > I like this .moz idea. It seems like each .moz could have its own profile > directory (and its own chrome registry/components dirs that are placed into I hadn't really thought about the profile much, but that makes decent sense. Then we don't have to worry about profile-sharing either, which is a large can of worms. > or to sharing chrome information between two .moz files. What do you mean by this? > Because each .moz file would have its own profile dir, the chrome registry can > continue to function as it does now, and extensions can be installed directly > into the profile dir for that .moz file. [snip] > If you have an extension like smooth scrolling that you want to make available > for all .moz applications, install it into a particular XRE, and it will be 1) I'm not sure it's clear from this bug, but Axel Hecht and I were hoping to implement "XRA applications" and "extensions" in almost exactly the same manner: a JAR file containing chrome/components/whatever. I was hoping to entirely trash the current XPInstall system of delivering extensions into an application. Thus the FB extension manager would be entirely reworked, and the chrome manager would actually install/uninstall chrome, instead of using .setAllowOverlaysForPackage() 2) dougt has sworn that he doesn't want extensions installed into the GRE/XRE directory (see discussion in bug 209439)... do you think that policy should change? > I don't see the benefit to putting an extension > like this in some arbitrary directory, since it has to be re-registered anyway > with each subsequent version of the XRE, and it's likely such extensions won't XRE extensions would be "discoverable" in the same manner/locations that GREs are currently "disoverable" (win32 registry, /etc/gre and $HOME/.gre on *nix). Certainly many extensions are GRE-specific, but some (JSLib, for example) are not version-specific at all, or work with large ranges of GRE versions.

This kind of talk makes me crazy: "I was hoping to entirely trash the current XPInstall system of delivering extensions into an application." Don't rewrite (see http://www.joelonsoftware.com/articles/fog0000000069.html). Don't misunderstand the requirements. Don't over-engineer. Don't try to solve hard problems that can wait while ignoring easier problems that need solving now. Don't fail to talk to the relevant parties (you know, the owners of the system you were hoping to trash). Do please communicate before starting down a "rewrite" path. Do divide and conquer. Do reuse code with maximum leverage (judo). Do try to keep things working, until it's time for a new module (fork, or clean slate -- but see above about rewrites). And talk to me before you get near to forking anything. Whew. Sorry if this sounded harsh, but I had to say it. One last thing: I agree totally with this paragraph of hyatt's: "My vision of the XRE may not be as fancy as some people want. I envison a mozRunner.exe that can handle .moz files, but each unique .moz file would get its own process and its own profile directory. I see little benefit to attempting any sort of fancy out-of-process communication or to sharing chrome information between two .moz files." The last part is talking about how we don't need a shared DOM inspector for two distinct .moz applications (not that they'd have enough in common for inspector to overlay the same way in each). Some day, we may have layers of unity among XUL apps. Let's start smaller, and build up. We'll get better results early on, and later when we reach higher levels incrementally. /be

Heck, what I'm proposing would still support shared applications like DOM Inspector. The architecture would be something like this: [Inspector Core] - consists of the C++ code and all the chrome files for inspector windows. This would be installed into the chrome registry of the XRE. [Firebird.moz Inspector Extension] - consists of the overlay files for making inspector work in Firebird. Goes in the user's profile dir. [Thunderbird.moz Inspector Extension] - The same, but for Thunderbird. Goes in the profile dir. The extensions could be versioned independently of the core, and the Inspector author could essentially guarantee their compatibility with any version of the core. So I'll use the terminology "XRE extension" vs. ".moz extension". Nothing I'm proposing even rules out sharing for multiple apps that use the same XRE, since they'll all get the same "XRE extensions." The place where I think we should draw the line is trying to use "XRE extensions" across multiple XREs.

Ideally, I think we should pay attention to how typical Perl and Python installations operate. You generally have a single installation of the interpreter in a system path, and associated libraries in one or more system or user specific paths. The interpreter and the libraries have NO prefs, except for maybe a few settings read from the environment. There is NO notion of a global prefs file in the interpreter, so the only conflicts between instances of the interpreter happen as a result poorly designed code. In these setups, applications don't *need* to be installed anywhere in particular, you just run them through the interpreter in place. There is no implicit difference between a library that extends the "core functionality" and a library that extends any other kind of functionality. What I think we need is an install driver that is literally, just another mozilla application. One that gives the install script complete access to query both the system and the user, and decide how to install based on what it finds. One that provided some skeleton UI and a few hooks to control the user interaction. One that is similar to our current installer, and leverages most of the code, but is driven by tables defined in an arbitrary script instead of a set of platform specific input files. Solving this with multiple install "classes" or contorted RDF files is more trouble than it's worth.

Re brendan: AFAICT, neither Benjamin nor I have thought about the installation side of things. But including the installation into the thinking might help. AFAICT, XPInstall is designed to pull packages into an application. For stuff like jslib or inspector or friends however, there isn't really a single application that'd pull. Unless we'd follow hyatts plan to make those extensions be pulled into a single re. (GRE, XRE, whatever drivers will actually call that beast.) Just that hyatt and dougt conflict. If we follow dougt and rginda, we end up with separated locations of extensions. Those extensions need to be made accessible to both XPInstall for the installation procedure and to the apprunner. The question about the chrome registry touches this a bit. If we just have one "app" and the GRE, and all extensions are registered in one of those two locations, chrome registry is prolly simple. If we end up with separated locations for extensions, the apprunner must collect the package informations and feed that into the chrome registry, so that it can resolve the chrome urls into the separate packages. A note on development cycles, if we installed extensions into the GRE, developers had to install those extensions into their debug environment as well. If they need a debug GRE. Or one for profiling, timelining, etc. Do we want to put that burdon on application developers?

brendan: I'm sorry if I appeared to be uncommunicative; I definitely wish to have a complete design reviewed by appropriate people before doing any actual patching. Since my major concern is for extensions and not the apprunner per se, I will comment further in bug 209439... I just think that XPA and extensions could have very similar format and functionality.

> Let's use this bug to brainstorm and to report ... restrictions of > various OSes ... Therefore these remarks on restrictions/burdens. IMHO, debate here about the use or design of multi-instance or multi-personality support is an example of the cart-before-the-horse, no matter how attractive apprunner scenarios are (and they are very attractive). The largest burden currently facing Moz app developers is that on Windows only, the current instance does not reliably shut down when the last GUI window disappears. The next window invoked using -chrome then inherits that dirty instance. Testing is unreliable until the instance is hand-killed. Typically this occurs when part-constructed, ill-formed or ill-advised XUL, RDF or JS is tested. This is done at early prototype stage, usually. If the developer uses a syntax coloring editor (common) rather than an XML validating editor (uncommon), then this problem is almost certain to appear. It is hard for beginners to detect; it is a massive adoption obstacle for new moz apps. There are many bugs noting shutdown issues. To introduce multi-instance or multi-executable support without reliable shutdown makes everything so much more fragile and unlearnable on Windows. As it is, Windows app developers must punctuate their code-run-test cycle regularly with Ctrl+Alt+Del Task Manager checks, just to ensure that Mozilla died when it should have. It is a very unprofessional style of work and reflects poorly on Mozilla as a quality development tool. IDEs don't do that. Could this bug have a dependancy on reliable shutdown? Have what you want, but please don't let your innovation drown in a process problem. - N.

Erm, it takes effort to recycle instances. We don't have to, no windows app has to. When you have MOZ_NO_REMOTE=1 in your env then we don't try to recycle. The code to try to recycle is very easy to disable, and we'd most certainly want our apprunner to only recycle instances matching the package it's running. i.e. an apprunner running xpcshell.xpa would not try to recycle the apprunner instance of composer.xpa. Most likely our apprunner would actually let a flag inside the .xpa indicate whether an app wants to be recycled. In the case of xpcshell.xpa, I wouldn't want instances recycled. In the case of composer.xpa, I /might/ want to have multiple windows in a single instance (probably not). My guess is that composer.xpa or navigator.xpa would set the recycle flag for the time being, at least until they had a good cache/profile sharing system and possibly a way to enumerate windows from other instances (if they want to have a window menu, firebird.xpa probably wouldn't).

MOZ_NO_REMOTE is certainly useful, and addresses part of the problem I noted. Its shortcomings, however are: 1. invisible for new app developers, who don't read docs 2. and yet despite 1., important for new app developers 3. without it (the default), accidental buggy recycling can occur 4. it remains counter-intuitive that a Mozilla instance should be able to survive closure of its final window. 5. it is a pain to have to remember to set/unset an envvar when multi-window instances are required (eg a debug cycle that includes an extra window following one that doesn't) Expecting newbie developers to deduce the existence of such an envvar when they're trying to learn basics is asking too much, in any event.

excuse me, but your problems have nothing to do with this bug. please rant elsewhere.

arrogance n : overbearing pride evidenced by a superior manner toward inferiors

I myself am quite suprised to see -remote support as a feature request for the generic apprunner. I'd expect that apps had to opt-in, at least. As timeless already indicated, supporting -remote would require to have ipc running, I'd say. Not sure if we want that in general. I don't see SeaMonkey or any of the birds as primary target of this code, either. They can easily ship an apprunner of their own. Stuff needed to run any of those should, if at all, go into the third or fourth incarnation of the generic apprunner.

I've at no point asked for -remote. I said useability for Windows developers should be preserved and improved as part of this work. My focus on technology uptake does seems to threaten and attract comments, even though my expertise is widely recognised: <http://www.phppatterns.com/index.php/article/articleview/91/1/12/> I say that instance management should work reliably out of the box for Windows developers, whether apprunner or not. It doesn't today. That is a big problem for -chrome users. Taken alone, more executables and/or invocation methods, (like apprunner) will make that existing problem worse and Mozilla overall worse. Apprunner alone is therefore no improvement for the Windows app developer audience. By itself it is a step backwards, not a step forwards. Proper startup/shutdown is required as well. If that is in place, apprunner is a great idea. - N.

> The largest burden currently facing Moz app developers is that on > Windows only, the current instance does not reliably shut down > when the last GUI window disappears. The reason all windows don't shut down is because you might have "Quick Launch" (a Windows only feature) enabled. Disable it, and you will be able to shut down all Mozilla windows hidden or visible. Quick Launch: http://www.mozilla.org/projects/ui/communicator/framework/quicklaunch/ It is just a simple pref that can easily be turned off programmatically. I hope this helps.

Quick Launch is not relevant. To see a trivial example, turn off quick launch and other caching effects, and act like an app developer: Shut down Mozilla totally. From a Windows DOS/Command Box (my test box: PIII 800/128, Moz 1.6b, Win98se + fixes): cd "Program Files" (or Winnt etc) cd mozilla mozilla -chrome chrome://foo/content/bar.xul Since bar.xul doesn't exist, an error results. Close the error window. Check with Task Manager (Ctrl+Alt+Del). Mozilla still runs. Why? It is counter-intuitive and non-obvious why. Now load any valid XUL file using -chrome from the Dos Box. Probably it won't display at all. That is at face value very mysterious, not to mention problematic. Kill Mozilla from Task Manager. Try your valid XUL file again. It works. That XUL file is processed reliably at one time and not at another. Now make the XUL ill-formed XML. Repeat the whole thing. The ill-formed XUL does not even report a normal XUL syntax error window. There are many scenarios that lead to this unreliability. Imagine foo and bar.xul are the start of a mozilla-based project. You see the annoyance, confusion and mystification that shutdown problems create. A newbie to Mozilla app development will likely give up, and may not ever deduce what the problem was. He jumped on the tool using a straightforward and sensible approach, and the tool silently tied itself in a knot. Now add further invocation methods (apprunner) to the mix. The above problems should be addressed too, or they will just multiply horribly. - N

> Since bar.xul doesn't exist, an error results. Close the error window. > Check with Task Manager (Ctrl+Alt+Del). Mozilla still runs. Why? It is > counter-intuitive and non-obvious why. Mozilla still runs because it requires a hidden window/s to run in the background. I just Ctl+C to kill Mozilla from my cygwin shell when I get this error. > Now make the XUL ill-formed XML. Repeat the whole thing. The ill-formed > XUL does not even report a normal XUL syntax error window. It will if you are using a DEBUG build you will certainly see xml syntax errors. > A newbie to Mozilla app development will likely give up, and may not > ever deduce what the problem was. Yes, a point well taken. An unfortunate result of Mozilla development where newbies become collateral damage and where an "elitist" culture permeates. Something I have been vehemently against. Having said that, I don't this this bug is the right place for my pontificating about Mozilla culture. I think your citations are valid and relevant to apprunner. Maybe you should file a new bug requesting that the alert error you see, should shut down Mozilla instead of letting hidden windows linger.

Windows application developers are unlikely to start with a debug build or have Cygwin in place. On Windows, vanilla Mozilla on a vanilla box is the basic scenario to start with. Probably true on Linux as well (but no shutdown problem there). I do hope that the nature of new app developer audiences for Mozilla is appreciated carefully. Nearly everything is in place today, except for a motherhood statement and a few key bug fixes. Doing both would quash recent unfair criticisms that 1.x releases are "adding nothing substantially new", and would give a release something particularly singular to Announce. I'll file a bug on shutdown (XP Apps: Cmd-line features) and contribute in every way I can, if some person likely to write code shows interest. Anyone? My email's above. - N.

Phew! Good thing I found this bug and read Nigel's comments. I've been trying for the last 3 hours trying to figure out why my XUL code wasn't running!

Lodged bug 229822 for the specific shutdown problem. - N.

isn't this a duplicate of the xulrunner bug?

*** This bug has been marked as a duplicate of 257162 ***