New Add-Manager
Zorkzero
The API is asynchronous and asynchronous programming is very hard in
Javascript. There's also no debugger so I have to put print statements
everywhere. Firefox seems to cache the add-ons so a restart isn't
enough, I have to reinstall the add-on each time I make changes to it.
Documentation says this:
nsIURI getResourceURI(in string path)
Parameters
Edit section
path
A "/" separated path for the resource.
In fact the method is called getResourceURL and it takes a single file
name, which can't contain slashes. It also returns a string and not a
nsURI. I need it to take a path and not just a file name, the old API
worked like this.
The old API threw an exception when an add-on wasn't available. It was
the right thing to do and easy to handle. The new one passes null to
the callback. This is bad, but I can throw my own exception, right?
Wrong, doesn't work either because the add-on manager catches it.
I gave up at this point. I hope the API will be improved in future
versions.
Dave Townsend
> Documentation says this:
>
> nsIURI getResourceURI(in string path)
> Parameters
> Edit section
>
> path
> A "/" separated path for the resource.
>
> In fact the method is called getResourceURL and it takes a single file
> name, which can't contain slashes. It also returns a string and not a
> nsURI. I need it to take a path and not just a file name, the old API
> worked like this.
This changed recently, we replaced the old method getResourceURL with
the new one. Strange that it does not take a path though. Please file
bugs when you come across issues like these as it will help us fix them
faster, I only rarely get a chance to check the newsgroups.
> The old API threw an exception when an add-on wasn't available. It was
> the right thing to do and easy to handle. The new one passes null to
> the callback. This is bad, but I can throw my own exception, right?
> Wrong, doesn't work either because the add-on manager catches it.
I'm not sure where you would throw that exception too, the callback is
called normally after the outer code has completed so there is nothing
to catch that exception.
> I gave up at this point. I hope the API will be improved in future
> versions.
If you have particular suggestions then please make them. Unfortunately
we are fixed on using asynchronous APIs since it ensures that we keep
the application as responsive as possible for our users.
Zorkzero
> I'm not sure where you would throw that exception too, the callback is
> called normally after the outer code has completed so there is nothing
> to catch that exception.
Sorry, you are right of course. I don't have any suggestions that are
implementable in Javascript.
Dave Townsend
> On 6/24/10 12:35, Zorkzero wrote:
>> Documentation says this:
>>
>> nsIURI getResourceURI(in string path)
>> Parameters
>> Edit section
>>
>> path
>> A "/" separated path for the resource.
>>
>> In fact the method is called getResourceURL and it takes a single file
>> name, which can't contain slashes. It also returns a string and not a
>> nsURI. I need it to take a path and not just a file name, the old API
>> worked like this.
>
> This changed recently, we replaced the old method getResourceURL with
> the new one. Strange that it does not take a path though. Please file
> bugs when you come across issues like these as it will help us fix them
> faster, I only rarely get a chance to check the newsgroups.
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=574541 in response
to this issue. I have committed the fix and it should be available in
the next nightly or the first beta of Firefox 4.
johnjbarton
> I tried using the new add-on manager in Firefox 3.6alpha5.
>
> The API is asynchronous and asynchronous programming is very hard in
> Javascript. There's also no debugger so I have to put print statements
> everywhere. Firefox seems to cache the add-ons so a restart isn't
> enough, I have to reinstall the add-on each time I make changes to it.
Asynchronous programming is different, but in my experience Javascript
does not make it harder. The primary problem is debugging code that
does not get called.
Chromebug will probably be able to debug the new add-on manager:
http://getfirebug.com/wiki/index.php/Chromebug_User_Guide
You don't have to reinstall addons and they aren't cached. Far and a way
the best solution for addon development is to put a file-link in your
extensions/ directory, that is text file with the name of your extension
containing a single line giving the name of the directory containing
your extension.
jjb
Zorkzero
> Asynchronous programming is different, but in my experience Javascript
> does not make it harder. The primary problem is debugging code that
> does not get called.
You can read synchronous code from top to bottom. That doesn't work
with asynchronous code. You also can't use exceptions. You have to
make every method, that depends on an asynchronous method asynchronous
too.
> Chromebug will probably be able to debug the new add-on manager:http://getfirebug.com/wiki/index.php/Chromebug_User_Guide
Thanks, I'l try it.
> You don't have to reinstall addons and they aren't cached. Far and a way
> the best solution for addon development is to put a file-link in your
> extensions/ directory, that is text file with the name of your extension
> containing a single line giving the name of the directory containing
> your extension.
That's what I do, and it works in Firefox 3.6 but for some reason it
doesn't work with 3.7a5. I have to remove this file from the
extensions directory, then I restart Firefox, then I put it in again
and restart Firefox again.
Neil
>On 25 Jun., 17:02, johnjbarton <johnjbar...@johnjbarton.com> wrote:
>
>
>>Asynchronous programming is different, but in my experience Javascript does not make it harder. The primary problem is debugging code that does not get called.
>>
>>
>You can read synchronous code from top to bottom. That doesn't work with asynchronous code. You also can't use exceptions. You have to make every method, that depends on an asynchronous method asynchronous too.
>
Well, the generator paradigm alleviates this somewhat.
--
Warning: May contain traces of nuts.
Dave Townsend
> On 25 Jun., 17:02, johnjbarton<johnjbar...@johnjbarton.com> wrote:
>> Asynchronous programming is different, but in my experience Javascript
>> does not make it harder. The primary problem is debugging code that
>> does not get called.
>
> You can read synchronous code from top to bottom. That doesn't work
> with asynchronous code. You also can't use exceptions. You have to
> make every method, that depends on an asynchronous method asynchronous
> too.
That is largely a coding style issue, you can quite easily write
asynchronous code that still reads top to bottom by using inline
functions. It can get a little painful with all the indentation but it
works.
Eric H. Jung
> I tried using the new add-on manager in Firefox 3.6alpha5.
>
> The API is asynchronous and asynchronous programming is very hard in
> Javascript. There's also no debugger so I have to put print statements
> everywhere. Firefox seems to cache the add-ons so a restart isn't
> enough, I have to reinstall the add-on each time I make changes to it.
>
> Documentation says this:
>
> nsIURI getResourceURI(in string path)
> Parameters
> Edit section
>
> path
> A "/" separated path for the resource.
>
I'm curious what you were trying to do; were you trying to do
something with the Addon Manager API? (I'm thinking of my own
extensions and where I might run into these problems).
Thanks,
Eric
Zorkzero
> On Thu, Jun 24, 2010 at 3:35 PM, Zorkzero <zorkz...@hotmail.com> wrote:
> I'm curious what you were trying to do; were you trying to do
> something with the Addon Manager API? (I'm thinking of my own
> extensions and where I might run into these problems).
I was just trying to get the file path of a file in my add-on
directory. I tried using getResourceURI and the rest is written in my
first post.
BTW Chromebug really works. The article "Setting up an extension
development environment" in the MDN should say, that it is an
essential tool for extension development because it's impossible to
program without a debugger. Instead it just mentions it together with
many other tools. Actually developer tools like Chromebug should be a
high priority for Mozilla I think.
Nickolay Ponomarev
> > You don't have to reinstall addons and they aren't cached. Far and a way
> > the best solution for addon development is to put a file-link in your
> > extensions/ directory, that is text file with the name of your extension
> > containing a single line giving the name of the directory containing
> > your extension.
> That's what I do, and it works in Firefox 3.6 but for some reason it
> doesn't work with 3.7a5. I have to remove this file from the
> extensions directory, then I restart Firefox, then I put it in again
> and restart Firefox again.
>
What changes are not applied? Changes to install.rdf, chrome XUL/JS, or to
XPCOM components/modules?
The first one, I think, wasn't re-read even in 3.6. For chrome XUL/JS you
should set a disable_xul_cache pref <
https://developer.mozilla.org/en/Setting_up_extension_development_environment>
(I think it wasn't required to pick up the changes on restart before,
though), for and components/modules you have to delete the Firefox XUL/XPC
caches in Local Settings (win) / Library/Caches (mac).
See bug <https://bugzilla.mozilla.org/show_bug.cgi?id=531886>, the pending
fix is to provide a command line argument to invalidate caches.
Sigh.
Nickolay
Zorkzero
> What changes are not applied? Changes to install.rdf, chrome XUL/JS, or to
> XPCOM components/modules?
XUL/JS
> The first one, I think, wasn't re-read even in 3.6. For chrome XUL/JS you
> should set a disable_xul_cache pref <https://developer.mozilla.org/en/Setting_up_extension_development_env...>
> (I think it wasn't required to pick up the changes on restart before,
> though), for and components/modules you have to delete the Firefox XUL/XPC
> caches in Local Settings (win) / Library/Caches (mac).
Thank you, setting the option "disable_xul_cache" in Firefox 3.7
worked. Firefox 3.6 worked without this option.
Eric H. Jung
> I was just trying to get the file path of a file in my add-on
> directory. I tried using getResourceURI
Hm, I use the following from within my XPCOM components. Perhaps I
should change to getResourceURI()? Is getResourceURI() available
before FF 3.6.x?
let self;
let fileProtocolHandler =
Cc["@mozilla.org/network/protocol;1?name=file"].getService(Ci["nsIFileProtocolHandler"]);
if ("undefined" != typeof(__LOCATION__)) {
// preferred way
self = __LOCATION__;
}
else
self = fileProtocolHandler.getFileFromURLSpec(Components.Exception().filename);
var componentDir = self.parent; // the directory this file is in
> BTW Chromebug really works.
Interesting. Last time I tried it (maybe 6 months ago), it didn't work
in most cases. Time to give it another try
> The article "Setting up an extension
> development environment" in the MDN should say, that it is an
> essential tool for extension development
MDN is a community effort. You should edit the page with your comments
about Chromebug. Given how active you've been in the community over
the years, your comments have great value.
>because it's impossible to program without a debugger
How's that? You didn't have a debugger before Chromebug yet you were
doing OK :)
Eric
Zorkzero
> Hm, I use the following from within my XPCOM components. Perhaps I
> should change to getResourceURI()? Is getResourceURI() available
> before FF 3.6.x?
getResourceURI() is part of the new Add-on manager which is only
available since Firefox 3.7. See https://developer.mozilla.org/en/Addons/Add-on_Manager
.
For Firefox 3.6 and earlier I use this function. Given the extension
id and the file path which is relative to the extension directory it
returns the file.
function getFile (id, filepath) {
return Components.classes["@mozilla.org/extensions/manager;1"].
getService(Components.interfaces.nsIExtensionManager).
getInstallLocation(id).getItemFile(id, filepath)
}
> How's that? You didn't have a debugger before Chromebug yet you were
> doing OK :)
I exaggerated a bit. When I started working on my add-on I used
Venkman. Later Venkman stopped working for me for some reason. I
haven't tried it in a long time. Also Venkman isn't compatible with
Firefox 3.7a5.