Last Comment Bug 342590 - Make --enable-extensions=venkman work for XULRunner
: Make --enable-extensions=venkman work for XULRunner
Status: RESOLVED INCOMPLETE
: 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
:
:
Mentors:
Depends on:
Blocks:
  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: ---


Attachments

Description 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:

content,install,url,resource:/chrome/venkman/content/venkman/
locale,install,url,resource:/chrome/venkman/locale/en-US/venkman/
skin,install,url,resource:/chrome/venkman/skin/modern/venkman/

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

http://lxr.mozilla.org/seamonkey/search?string=toOpenWindowByType indicates it is a per-application function (calendar, browser, mail, suite).

I intend to fix this.
Comment 1 Alex Vincent [:WeirdAl] 2006-06-23 22:47:39 PDT
Ref bug 299716 for a better solution than I had in mind.
Comment 2 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 Alex Vincent [:WeirdAl] 2006-06-24 01:03:41 PDT
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.
Comment 4 Alex Vincent [:WeirdAl] 2006-06-24 02:01:21 PDT
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.
Comment 5 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 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 James Ross 2006-06-24 10:00:21 PDT
That's just the ChromeReg sucking; either way, do not change makexpi.sh to make a chrome.manifest. There is no use for it.
Comment 8 Alex Vincent [:WeirdAl] 2006-06-24 10:02:07 PDT
In that case, someone else should do the work on this bug.
Comment 9 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 James Ross 2006-06-24 10:52:45 PDT
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.
Comment 11 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 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 Alex Vincent [:WeirdAl] 2006-06-24 12:12:31 PDT
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.
Comment 14 James Ross 2006-06-24 12:31:33 PDT
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.
Comment 15 Alex Vincent [:WeirdAl] 2009-06-05 22:26:43 PDT
Gijs: see http://hg.mozilla.org/venkman/file/d3e68b8f918e/xpi/resources/install.rdf#l56 .  Is this bug fixed?
Comment 16 :Gijs Kruitbosch 2009-06-07 02:29:02 PDT
(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.
Comment 17 Benjamin Smedberg [:bsmedberg] 2016-02-12 07:18:19 PST
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.

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