Last Comment Bug 342590 - Make --enable-extensions=venkman work for XULRunner
: Make --enable-extensions=venkman work for XULRunner
: helpwanted
Product: Toolkit Graveyard
Classification: Graveyard
Component: XULRunner (show other bugs)
: unspecified
: x86 Windows XP
-- normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on:
  Show dependency treegraph
Reported: 2006-06-23 18:15 PDT by Alex Vincent [:WeirdAl]
Modified: 2016-02-12 08:12 PST (History)
15 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image Alex Vincent [:WeirdAl] 2006-06-23 18:15:31 PDT
When I use --enable-extensions=default,inspector,venkman the resulting dist/bin/chrome contains a installed-chrome.txt file with the following:


It does not contain a venkman.manifest file.

Also, when I am able to add Venkman to my toolsPopup via overlay, I get this error message:

JavaScript error: chrome://venkman/content/venkman-overlay.js, line 43: toOpenWindowByType is not defined indicates it is a per-application function (calendar, browser, mail, suite).

I intend to fix this.
Comment 1 User image Alex Vincent [:WeirdAl] 2006-06-23 22:47:39 PDT
Ref bug 299716 for a better solution than I had in mind.
Comment 2 User image Ben Turner (not reading bugmail, use the needinfo flag!) 2006-06-23 23:57:33 PDT
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?
Comment 3 User image Alex Vincent [:WeirdAl] 2006-06-24 01:03:41 PDT 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.
Comment 4 User image Alex Vincent [:WeirdAl] 2006-06-24 02:01:21 PDT
Okay, I'm lost. calls on

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 and determine from that when to turn on chrome.manifest.

By reading, I stumbled across the -e flag.  Adding that to had no effect, as far as I could tell.  But I may have added it in the wrong spot on lines 78, 80, 82.
Comment 5 User image James Ross 2006-06-24 07:20:49 PDT
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.
Comment 6 User image Benjamin Smedberg [:bsmedberg] 2006-06-24 09:50:00 PDT
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).
Comment 7 User image James Ross 2006-06-24 10:00:21 PDT
That's just the ChromeReg sucking; either way, do not change to make a chrome.manifest. There is no use for it.
Comment 8 User image Alex Vincent [:WeirdAl] 2006-06-24 10:02:07 PDT
In that case, someone else should do the work on this bug.
Comment 9 User image Robert Strong [:rstrong] (use needinfo to contact me) 2006-06-24 10:47:58 PDT
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.
Comment 10 User image James Ross 2006-06-24 10:52:45 PDT
Can you please stop misinterpreting. 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.
Comment 11 User image Robert Strong [:rstrong] (use needinfo to contact me) 2006-06-24 11:02:10 PDT
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.
Comment 12 User image James Ross 2006-06-24 11:32:07 PDT
The XPI does not and will not have a chrome.manifest at this time.
Comment 13 User image Alex Vincent [:WeirdAl] 2006-06-24 12:12:31 PDT
All right, so here's where we stand.  The 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 not interpreting the file in a way we expect.  I erred in how is referenced, obviously.  But I don't understand how gets called by the or files via  I also don't understand why it reads and insists on generating installed-chrome.txt instead of chrome.manifest.
Comment 14 User image James Ross 2006-06-24 12:31:33 PDT runs the stuff over 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.
Comment 15 User image Alex Vincent [:WeirdAl] 2009-06-05 22:26:43 PDT
Gijs: see .  Is this bug fixed?
Comment 16 User image :Gijs (away until Feb 27) 2009-06-07 02:29:02 PDT
(In reply to comment #15)
> Gijs: see
> .
>  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.
Comment 17 User image Benjamin Smedberg [:bsmedberg] 2016-02-12 07:18:19 PST
XULRunner has been removed from the Mozilla tree: see!topic/ 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.

Note You need to log in before you can comment on or make changes to this bug.