Ref bug 299716 for a better solution than I had in mind.
So to clarify this bug isn't about making venkman "work" with XULRunner... It works ok (I usually launch it by typing |x-jsd:debugger| into the url bar). This bug is about fixing venkman to use the new chrome.manifest format for registration and implementing a toolkit version of toOpenWindowByType. Maybe a separate bug?
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/extensions/inspector/Makefile.in provides some interesting MOZ_XUL_APP code, particularly rev 1.10. I think this is what we want for chrome.manifest and the other goodies.
Okay, I'm lost. http://lxr.mozilla.org/seamonkey/source/extensions/venkman/xpi/makexpi.sh#78 calls on make-jars.pl. http://lxr.mozilla.org/seamonkey/source/config/make-jars.pl#531 determines when we use installed-chrome.txt (it will use installed-chrome.txt by calling on RegIt) Unfortunately, we get into some messy regexp's. The regexp's take in lines from the given jar.mn and determine from that when to turn on chrome.manifest. By reading make-jars.pl, I stumbled across the -e flag. Adding that to makexpi.sh had no effect, as far as I could tell. But I may have added it in the wrong spot on lines 78, 80, 82.
Can you provide *any* reason for needing chrome.manifest? The current setup without one is handled fine by the ChromeReg's importing code in toolkit.
The problem with installed-chrome.txt is that the user is required to have write access to the install directory at first run. That is not an issue with the .manifest files (and allows apps to run directly from CDs and DMG mounts, for instance).
That's just the ChromeReg sucking; either way, do not change makexpi.sh to make a chrome.manifest. There is no use for it.
In that case, someone else should do the work on this bug.
There is value IMO in moving the dependency from the client to the build system which generating the chrome.manifest during the build process provides.
Can you please stop misinterpreting. makexpi.sh is used for making releases - not for building Venkman during the normal build. Make the normal build create a chrome.manifest (but only when required), just don't make the release script do it.
Since it isn't clear... the chrome.manifest will be used with apps that use the new toolkit so it should be created when building a new toolkit app or creating xpi's for new toolkit apps.
The XPI does not and will not have a chrome.manifest at this time.
All right, so here's where we stand. The makexpi.sh approach is clearly being vetoed by Silver. Fine. makexpi is not called as part of the build process (which confused me greatly until that was explained to me), so for all intents and purposes we should ignore it. That still leaves the problem of make-jars.pl not interpreting the jar.mn file in a way we expect. I erred in how make-jars.pl is referenced, obviously. But I don't understand how make-jars.pl gets called by the autoconf.mk or rules.mk files via Makefile.in. I also don't understand why it reads jar.mn and insists on generating installed-chrome.txt instead of chrome.manifest.
http://lxr.mozilla.org/seamonkey/source/config/rules.mk#1554 runs the stuff over jar.mn if it exists. That's just an automatic thing. It's generating what it does because of what's in the makefile, as I explained on IRC. Adding NO_JAR_AUTO_REG will make it not create installed-chrome, and the other options from Inspector will make it spam out the app-installed-extension structure instead of the normal location for the jar.
Gijs: see http://hg.mozilla.org/venkman/file/d3e68b8f918e/xpi/resources/install.rdf#l56 . Is this bug fixed?
(In reply to comment #15) > Gijs: see > http://hg.mozilla.org/venkman/file/d3e68b8f918e/xpi/resources/install.rdf#l56 . > Is this bug fixed? Not sure. I was under the impression that the bug was about having the build flag work, which I very much doubt it does under mozilla-central, which to my knowledge does not import venkman from hg. Not sure how it'd deal with it if you add it, ie if the build logic is still there or not. Someone'd have to test it, and I am not in a position to do so until at least a week from now, I'm afraid.
XULRunner has been removed from the Mozilla tree: see https://groups.google.com/forum/#!topic/mozilla.dev.platform/_rFMunG2Bgw for context. I am closing all the bugs currently in the XULRunner bugzilla component, in preparation for moving this component to the graveyard. If this bug is still valid in a XULRunner-less world, it will need to be moved to a different bugzilla component to be reopened.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.