-chrome vs -app?
John J. Barton
URL, its not firefox, it looks like a different app. So whats -app do?
jjb
Mark Finkle
wrote:
> What is the difference between -chrome and -app? -chrome opens a chrome
> URL, its not firefox, it looks like a different app. So whats -app do?
>
> jjb
-app will launch a completely new application, a xulrunner-based
application. But instead of using a xulrunner runtime, the Firefox
libxul runtime is used. The application is _not_ launched into a
Firefox process. The only thing I can think of that is different than
using xulrunner itself, is the extra Firefox browser components _are_
loaded with the application.
John J. Barton
Thanks, so -app is Firefox libxul runtime + Firefox browser components.
As in xpcom components?
Is Firefox libxul runtime used in Firefox ? If yes then what is missing in:
Firefox = Firefox libxul runtime + browser components + ?
Mark Finkle
wrote:
> Thanks, so -app is Firefox libxul runtime + Firefox browser components.
> As in xpcom components?
Yes. The xpcom components packaged with Firefox that are or packaged
with a typical xulrunner runtime.
>
> Is Firefox libxul runtime used in Firefox ? If yes then what is missing in:
> Firefox = Firefox libxul runtime + browser components + ?
The Firefox front-end GUI itself
Also, when launched using -app, an application uses it own profile
folder, not the Firefox profile.
John J. Barton
So....if I ran Firefox process with -chrome <myurl> but did not open
Firefox, then called the same code as -app <app.ini> calls then....?
I guess the -app code can't find the app because of the profile. But I
suppose that could be fixed up with some reg directory work.
(I'm trying to guess how much work would be needed to apply chromebug to
songbird).
jjb
Robert Kaiser
-app is basically Firefox pretending to be XULRunner (I almost said
"misusing Firefox as XULRunner"), and this option is special to Firefox,
no other XUL app that I know of has this support.
-chrome on the other hand is supported by any XUL app (even 1.x suite)
and just opens a window with that chrome in the environment of that app.
Robert Kaiser
John J. Barton
> -chrome on the other hand is supported by any XUL app (even 1.x suite)
> and just opens a window with that chrome in the environment of that app.
So if I put Chromebug down in a thunderbird profile and ran thunderbird
with -chrome <chrombug URI>, it might work. For FF I start FF with
"window.open(URL)"; how could I open thunderbird or another app instead?
jjb
Benjamin Smedberg
> Robert Kaiser wrote:
>
>> -chrome on the other hand is supported by any XUL app (even 1.x suite)
>> and just opens a window with that chrome in the environment of that app.
This is incorrect. The -chrome command-line handler is in Firefox-specific
code located here:
http://mxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserContentHandler.js#483
SeaMonkey has copied this code here:
http://mxr.mozilla.org/comm-central/source/suite/browser/nsBrowserContentHandler.js#351
And Thunderbird here:
http://mxr.mozilla.org/comm-central/source/mail/components/nsMailDefaultHandler.js#245
> So if I put Chromebug down in a thunderbird profile and ran thunderbird
> with -chrome <chrombug URI>, it might work. For FF I start FF with
> "window.open(URL)"; how could I open thunderbird or another app instead?
Why is chromebug using -chrome? It seems more useful for me for chromebug to
implement its own command-line handler, so that you could do, e.g.
firefox -chromebug
And it would launch chromebug and then launch the browser normally.
The key here is, I think, to avoid setting cmdLine.preventDefault = true.
This means that after you open the chromebug window, startup will continue
on normally.
For more information on writing a command-line handler, see
https://developer.mozilla.org/en/Chrome/Command_Line
Or to see how DOMI implements -inspector, see
http://mxr.mozilla.org/comm-central/source/mozilla/extensions/inspector/base/js/inspector-cmdline.js#81
--BDS
Robert Kaiser
> On 12/22/08 12:22 PM, John J. Barton wrote:
>> Robert Kaiser wrote:
>>
>>> -chrome on the other hand is supported by any XUL app (even 1.x suite)
>>> and just opens a window with that chrome in the environment of that app.
>
> This is incorrect.
Thanks for clearing this up, I didn't know about that.
Robert Kaiser
John J Barton
...
>> So if I put Chromebug down in a thunderbird profile and ran thunderbird
>> with -chrome <chrombug URI>, it might work. For FF I start FF with
>> "window.open(URL)"; how could I open thunderbird or another app instead?
>
> Why is chromebug using -chrome? It seems more useful for me for chromebug to
> implement its own command-line handler, so that you could do, e.g.
>
> firefox -chromebug
>
> And it would launch chromebug and then launch the browser normally.
>
> The key here is, I think, to avoid setting cmdLine.preventDefault = true.
> This means that after you open the chromebug window, startup will continue
> on normally.
Ok thanks I can do that and simplifying the startup is good. But what I
was really after here was a way to try with thunderbird and songbird.
jjb
Mark Banner
> Benjamin Smedberg wrote:
>> Why is chromebug using -chrome? It seems more useful for me for
>> chromebug to
>> implement its own command-line handler, so that you could do, e.g.
>>
>> firefox -chromebug
>>
>> And it would launch chromebug and then launch the browser normally.
>>
>> The key here is, I think, to avoid setting cmdLine.preventDefault = true.
>> This means that after you open the chromebug window, startup will
>> continue
>> on normally.
>
> Ok thanks I can do that and simplifying the startup is good. But what I
> was really after here was a way to try with thunderbird and songbird.
Thunderbird (and I believe Songbird) should support the same command
line handler interfaces. Therefore you can use exactly the same code to
let you do
thunderbird -chromebug
songbird -chromebug.
Standard8.
John J. Barton
...
> Thunderbird (and I believe Songbird) should support the same command
> line handler interfaces. Therefore you can use exactly the same code to
> let you do
>
> thunderbird -chromebug
> songbird -chromebug.
>
> Standard8.
Well its a nice theory anyway ;-)
I ran into three problems:
1) The install.rdf for has to have a stanza for thunderbird,
songbird, whatever. It does not seem possible to have a mozilla platform
tool using this technology. To use chromebug on a new app you have to
edit all of its install.rdf files and add your app to it.
2) Unlike FF, thunderbird does not notice changes to the extensions
folder. I had to delete extensions.* to get the extensions to be loaded.
3) chromebug fails to load because of xul errors.
I guess I could look at the other half of the glass: by editing the
install.rdf files, installing chromebug extensions in to thunderbird,
deleting extensions.*, and running thunderbird with -chromebug it looks
possible to apply chromebug to a XUL app other than Firefox.
jjb
Robert Strong
> Mark Banner wrote:
> ...
>> Thunderbird (and I believe Songbird) should support the same command
>> line handler interfaces. Therefore you can use exactly the same code
>> to let you do
>>
>> thunderbird -chromebug
>> songbird -chromebug.
>>
>> Standard8.
>
> Well its a nice theory anyway ;-)
>
> I ran into three problems:
> 1) The install.rdf for has to have a stanza for thunderbird,
> songbird, whatever. It does not seem possible to have a mozilla
> platform tool using this technology. To use chromebug on a new app you
> have to edit all of its install.rdf files and add your app to it.
version (Toolkit version maps to Gecko version) to specify compatibility
with a Toolkit.
https://developer.mozilla.org/en/Extension_Versioning,_Update_and_Compatibility
> 2) Unlike FF, thunderbird does not notice changes to the extensions
> folder. I had to delete extensions.* to get the extensions to be loaded.
This works for me with other extensions... if you install or update the
extension I suspect it will work for you as well. I've had problems in
the past where modifying files in place (especially the install.rdf)
wouldn't get picked up.
> 3) chromebug fails to load because of xul errors.
This is often caused by relying on app provided locale strings.
Cheers,
Robert
L. David Baron
> On 12/23/2008 9:46 AM, John J. Barton wrote:
>> ...
>>> Thunderbird (and I believe Songbird) should support the same command
>>> line handler interfaces. Therefore you can use exactly the same code
>>> to let you do
>>>
>>> thunderbird -chromebug
>>> songbird -chromebug.
>>>
>>> Standard8.
>>
>> Well its a nice theory anyway ;-)
>>
>> I ran into three problems:
>> 1) The install.rdf for has to have a stanza for thunderbird,
>> songbird, whatever. It does not seem possible to have a mozilla
>> platform tool using this technology. To use chromebug on a new app you
>> have to edit all of its install.rdf files and add your app to it.
> version (Toolkit version maps to Gecko version) to specify compatibility
> with a Toolkit.
> https://developer.mozilla.org/en/Extension_Versioning,_Update_and_Compatibility
Though it's not really all that useful if you want your addon to be
usefully represented on addons.mozilla.org -- you'll have to go
through and do the install.rdf hacking anyway for every toolkit app
you care about (and figuring out the right versions of that app that
correspond to the toolkit versions you're compatible with).
https://bugzilla.mozilla.org/show_bug.cgi?id=363877
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Robert Strong
Daniel Veditz
> Well its a nice theory anyway ;-)
>
> I ran into three problems:
> 1) The install.rdf for has to have a stanza for thunderbird, songbird,
> all of its install.rdf files and add your app to it.
> 3) chromebug fails to load because of xul errors.
Number 3 explains 1, right? Many addons "should" work for any XUL-based
app, and yet in practice they don't without mods/special-casing. There's
no way for the engine to know without the developer saying in some
explicit way "my addon is compatible with this app and not that one".
John J. Barton
No, #1 means you can't even load so you never get to #3. Surely there is
some code in chromebug specific to firefox, eg the locale strings
suggested by Robert Strong. I'm encourage to believe that the obstacles
could be over come with modest motivation.
jjb
Mark Finkle
wrote:
Using too...@mozilla.org, as suggested by Robert Strong, will allow
any xulrunner based app to load your extension as long as you use a
commandline handler, as suggested by Benjamin, and use no overlays
into the xul application. You could use overlays only if you make them
explicit per application in your chrome manifest using the
"application" manifest flag.
https://developer.mozilla.org/en/Chrome_Registration#application
The latest DOMi and Venkman use too...@mozilla.org and I am able to
load both into my xul-based apps from the commandline - including
Fennec on an n810.
John J. Barton
Sorry I guess I left one sentence out. Once I fixed the install.rdf I
still have a problem, so #3 does not explain #1.
I changed the install.rdf to use too...@mozilla.org; I changed the
command line handler to use -chromebug. This works on FF3.0, crashes on
FF3.1b2, and has some XUL problem on thunderbird. It's a work in progress...
John J. Barton
> On 12/23/2008 9:46 AM, John J. Barton wrote:
>> 3) chromebug fails to load because of xul errors.
> This is often caused by relying on app provided locale strings.
>
So...is there something like chrome://toolkit/locale/toolkit.dtd,
for platform bindings of things like undo, cut, paste, ...?
Shawn Wilsher
> So...is there something like chrome://toolkit/locale/toolkit.dtd,
> for platform bindings of things like undo, cut, paste, ...?
http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/chrome/global/
/sdwilsh
John J. Barton
Unfortunately:
thunderbird says Unrecognized chrome registration modifier
'contentaccessible=yes'
songbird 1.0 crashes
Its possible that a simpler XUL app would work.
jjb
Shawn Wilsher
> thunderbird says Unrecognized chrome registration modifier
> 'contentaccessible=yes'
covers this...
https://developer.mozilla.org/en/Chrome_Registration#contentaccessible
> songbird 1.0 crashes
You should file a bug on them then.
/sdwilsh
John J. Barton
> On 12/26/08 11:32 AM, John J. Barton wrote:
>> thunderbird says Unrecognized chrome registration modifier
>> 'contentaccessible=yes'
> I'm assuming Thunderbird 2? The devmo wiki page on contentaccessible
2.0.0.18
> covers this...
> https://developer.mozilla.org/en/Chrome_Registration#contentaccessible
Yes, actually we already had the work around in for FF2. The error
message was not stopping progress. Instead, it looks like Thunderbird is
not registering my command line handler. I deleted compreg.dat and
checked it: firebug components are registered but not chromebug command
line handler (which works in Firefox). Further evidence is a message in
the OS console:
Warning: unrecognized command line flag -chromebug
More hints?
jjb
Philip Chee
Here's one: The DOM Inspector command line handler component works in:
SeaMonkey 1.1 (a XPFE, non-toolkit application), SeaMonkey 2.0a+,
Firefox 2/3.0/3.1, Thunderbird 2/3.0a+ and any toolkit 1.9.0/1.9.1
application.
That may be a bit of overkill. For a simpler cross application
implementation you could have a look at some of our code in:
<http://www.mozdev.org/source/browse/console2/src/console2/components/console2-clhandler.js>
If you don't need to support the non-toolkit XPFE based SeaMonkey 1.1
then this version is even simpler:
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]Do not expose this tagline to direct sunlight.
* TagZilla 0.066.6
John J. Barton
> On Mon, 29 Dec 2008 18:36:52 -0800, John J. Barton wrote:
>>
>> More hints?
...
> then this version is even simpler:
>
> <http://www.mozdev.org/source/browse/console2/src/console2/components/console2-clhandler.js?rev=1.1;content-type=text%2Fplain>
Thanks Phil. I put that .js file in my components directory and it did
not load. So then I looked at TB > Addons: chromebug fails to be
compatible. So this install.rdf stanza fails:
<!-- too...@mozilla.org -->
<em:targetApplication>
<Description>
<em:id>too...@mozilla.org</em:id>
<em:minVersion>1.5</em:minVersion>
<em:maxVersion>99.0.0.*</em:maxVersion>
</Description>
</em:targetApplication>
Ideas why? But chromebug registers if I use:
<!-- Thunderbird -->
<em:targetApplication>
<Description>
<em:id>{3550f703-e582-4d05-9a08-453d09bdfdc6}</em:id>
<em:minVersion>1.5</em:minVersion>
<em:maxVersion>9.0.*</em:maxVersion>
</Description>
</em:targetApplication>
It registers but fails to run because it cannot find:
@mozilla.org/permissionmanager;1
@mozilla.org/autocomplete/controller;1
Are these FF only and not part of the 'platform'?
jjb
Dan Mosedale
> Thanks Phil. I put that .js file in my components directory and it did
> not load. So then I looked at TB > Addons: chromebug fails to be
> compatible. So this install.rdf stanza fails:
>
> <!-- too...@mozilla.org -->
> <em:targetApplication>
> <Description>
> <em:id>too...@mozilla.org</em:id>
> <em:minVersion>1.5</em:minVersion>
> <em:maxVersion>99.0.0.*</em:maxVersion>
> </Description>
> </em:targetApplication>
>
> Ideas why? But chromebug registers if I use:
>
> <!-- Thunderbird -->
> <em:targetApplication>
> <Description>
> <em:id>{3550f703-e582-4d05-9a08-453d09bdfdc6}</em:id>
> <em:minVersion>1.5</em:minVersion>
> <em:maxVersion>9.0.*</em:maxVersion>
> </Description>
> </em:targetApplication>
>
Maybe it's because the Gecko that Thunderbird 2 uses is really old.
Does that problem go away on trunk builds of Thunderbird?
> It registers but fails to run because it cannot find:
> @mozilla.org/permissionmanager;1
> @mozilla.org/autocomplete/controller;1
Thunderbird 2 used the ancient XPFE components for that functionality.
We're in the midst of modernizing the trunk; Standard8 can probably tell
you more about where we are in that process...
Dan
Mark Banner
>> <!-- too...@mozilla.org -->
>> <em:targetApplication>
>> <Description>
>> <em:id>too...@mozilla.org</em:id>
>> <em:minVersion>1.5</em:minVersion>
>> <em:maxVersion>99.0.0.*</em:maxVersion>
>> </Description>
>> </em:targetApplication>
>>
>> Ideas why? But chromebug registers if I use:
>>
>> <!-- Thunderbird -->
>> <em:targetApplication>
>> <Description>
>> <em:id>{3550f703-e582-4d05-9a08-453d09bdfdc6}</em:id>
>> <em:minVersion>1.5</em:minVersion>
>> <em:maxVersion>9.0.*</em:maxVersion>
>> </Description>
>> </em:targetApplication>
>>
>
> Maybe it's because the Gecko that Thunderbird 2 uses is really old. Does
> that problem go away on trunk builds of Thunderbird?
You need to remember that Thunderbird 2 is equivalent to Firefox 2. It
is on gecko 1.8.1. I'm fairly sure the generic toolkit target didn't
make it in until gecko 1.9, seeing as Thunderbird hasn't done a release
for gecko 1.9 there isn't a release build that supports it yet, only the
Thunderbird 3 alpha and beta builds.
>> It registers but fails to run because it cannot find:
>> @mozilla.org/permissionmanager;1
>> @mozilla.org/autocomplete/controller;1
>
> Thunderbird 2 used the ancient XPFE components for that functionality.
> We're in the midst of modernizing the trunk; Standard8 can probably tell
> you more about where we are in that process...
I'm not sure why the permission manager fails to register, afaik
Thunderbird 2 should have that - if you could try a trunk build that
would be useful.
The autocomplete controller was definitely not available in Thunderbird
2. Trunk builds have it available, note however that currently we're
still using the xpfe front-end for autocomplete, although that does
support the toolkit interfaces for searches. I'm not sure what will
happen with the controller - it probably depends on what you are doing
with it.
I am hoping to swap over to full toolkit autocomplete, but I'm not sure
if that will happen before or after Thunderbird 3 (see bug 360648).
Standard8
Philip Chee
> It registers but fails to run because it cannot find:
> @mozilla.org/permissionmanager;1
> @mozilla.org/autocomplete/controller;1
>
> Are these FF only and not part of the 'platform'?
Have you ever considered installing the XPCOMviewer to see exactly which
components and interfaces are supported by Thunderbird. For Thunderbird
specific questions I would suggest that you would be better servered in
mozilla.dev.thunderbird or the #maildev channel on irc://moznet/
Phil
p.s. I think Thunderbird (and SeaMonkey) are still using the XPFE
autocomplete if you are talking about branch releases.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]What is food to one, is to others bitter poison/Lucretius
* TagZilla 0.066.6
Mark Banner
> On Tue, 30 Dec 2008 09:44:02 -0800, John J. Barton wrote:
>
>> It registers but fails to run because it cannot find:
>> @mozilla.org/permissionmanager;1
>> @mozilla.org/autocomplete/controller;1
>>
>> Are these FF only and not part of the 'platform'?
>
> Have you ever considered installing the XPCOMviewer to see exactly which
> components and interfaces are supported by Thunderbird. For Thunderbird
> specific questions I would suggest that you would be better servered in
> mozilla.dev.thunderbird or the #maildev channel on irc://moznet/
That's mozilla.dev.apps.thunderbird.
> p.s. I think Thunderbird (and SeaMonkey) are still using the XPFE
> autocomplete if you are talking about branch releases.
My earlier email already explains the autocomplete situation.
Standard8
John J. Barton
> On 12/30/08 9:44 AM, John J. Barton wrote:
> Maybe it's because the Gecko that Thunderbird 2 uses is really old. Does
> that problem go away on trunk builds of Thunderbird?
Yes! Chromebug (my version) comes up and inspect works on Gecko/20090101
Shredder/3.0b2pre
I guess JS debugging will work too, once I get it working again on
Firefox...
Thanks to everyone for help. I hope Chromebug 0.5 (next week?) will work
with Thunderbird (and possibly other 1.9.1+ xul apps).
jjb
Dan Mosedale
That would be fantastic; it will make our front-end working environment
significantly less painful. Thanks so much for taking the time to make
this happen!
Dan