Closed
Bug 206358
Opened 21 years ago
Closed 20 years ago
Need a generic apprunner.exe in the new roadmap world
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
VERIFIED
DUPLICATE
of bug 257162
People
(Reporter: brendan, Assigned: bugs)
References
Details
Attachments
(2 files)
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
Comment 1•21 years ago
|
||
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)
Assignee | ||
Comment 2•21 years ago
|
||
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
...
Status: NEW → ASSIGNED
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).
Comment 4•21 years ago
|
||
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.
Comment 5•21 years ago
|
||
bug 104382 seems related
Assignee | ||
Comment 6•21 years ago
|
||
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.
Comment 7•21 years ago
|
||
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...
Comment 8•21 years ago
|
||
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
Comment 9•21 years ago
|
||
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
Comment 10•21 years ago
|
||
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.
Comment 11•21 years ago
|
||
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
Comment 12•21 years ago
|
||
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.)
Comment 13•21 years ago
|
||
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
Comment 14•21 years ago
|
||
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).
Comment 15•21 years ago
|
||
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?
Comment 16•21 years ago
|
||
> /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.
Comment 17•21 years ago
|
||
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.
Comment 18•21 years ago
|
||
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.
Comment 19•21 years ago
|
||
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.
Comment 20•21 years ago
|
||
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).
Comment 21•21 years ago
|
||
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
Depends on: 212222
Comment 22•21 years ago
|
||
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.
Comment 23•21 years ago
|
||
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.
Comment 24•21 years ago
|
||
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/");
Comment 25•21 years ago
|
||
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;
Comment 26•21 years ago
|
||
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.
Comment 27•21 years ago
|
||
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?
Comment 28•21 years ago
|
||
> 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.
Reporter | ||
Comment 29•21 years ago
|
||
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
Comment 30•21 years ago
|
||
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.
Comment 31•21 years ago
|
||
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.
Comment 32•21 years ago
|
||
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?
Comment 33•21 years ago
|
||
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.
Comment 34•21 years ago
|
||
> 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.
Comment 35•21 years ago
|
||
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).
Comment 36•21 years ago
|
||
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.
Comment 37•21 years ago
|
||
excuse me, but your problems have nothing to do with this bug.
please rant elsewhere.
Comment 38•21 years ago
|
||
arrogance
n : overbearing pride evidenced by a superior manner toward inferiors
Comment 39•21 years ago
|
||
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.
Comment 40•21 years ago
|
||
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.
Comment 41•21 years ago
|
||
> 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.
Comment 42•21 years ago
|
||
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
Comment 43•21 years ago
|
||
> 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.
Comment 44•21 years ago
|
||
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.
Comment 45•21 years ago
|
||
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!
Comment 46•21 years ago
|
||
Lodged bug 229822 for the specific shutdown problem.
- N.
Comment 47•20 years ago
|
||
isn't this a duplicate of the xulrunner bug?
Comment 48•20 years ago
|
||
*** This bug has been marked as a duplicate of 257162 ***
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•