Components.utils.import and modules
John J Barton
Components.utils.import("resource://firebug/storageService.js");
to the firebug js debugging component. It works some times. When it
fails, there is no error message or exception. Even trusty
Components.utls.reportError() gives no output. The only way I can tell
that it failed is by accessing the debugging component and the
getService call fails.
Is it required that this statement be at top-level?
Components.utils.import("resource://firebug/storageService.js");
Any ideas? This is normal experience for modules? I have to say I have
been disappointed...
jjb
John J Barton
> I created firebug/modules/storageService.js and then added
> Components.utils.import("resource://firebug/storageService.js");
> to the firebug js debugging component. It works some times. When it
> fails, there is no error message or exception. Even trusty
> Components.utls.reportError() gives no output. The only way I can tell
> that it failed is by accessing the debugging component and the
> getService call fails.
>
> Is it required that this statement be at top-level?
> Components.utils.import("resource://firebug/storageService.js");
By random permutations, I found a combination that works.
1) The call to
Components.utils.import("resource://firebug/storageService.js");
must *not* be at the top level, I guess it is called too early in that case.
2) You can't test for an exported object from the service like normal:
if (StorageService)
becaues you get an exception. This seems to be a component feature,
since the line fails independent of any module. This test works:
if (typeof(StorageService) != "undefined")
3) Component.utils.reportErrors() is not trustworthy after all. This works:
if (!consoleService)
consoleService = ConsoleService.getService(nsIConsoleService);
consoleService.logStringMessage(text + "");
jjb
Benjamin Smedberg
> By random permutations, I found a combination that works.
>
> 1) The call to
> Components.utils.import("resource://firebug/storageService.js");
> must *not* be at the top level, I guess it is called too early in that
> case.
Yes. I believe that when we load JS components, we haven't yet read the
chrome manifests, so things like resource://firebug doesn't exist yet.
I'm disappointed that there isn't any error console message in that case
though, please file a bug about that.
> 2) You can't test for an exported object from the service like normal:
>
> if (StorageService)
>
> becaues you get an exception. This seems to be a component feature,
> since the line fails independent of any module. This test works:
What's the exception?
> 3) Component.utils.reportErrors() is not trustworthy after all. This works:
Can you be more specific? What doesn't work? If you have a testcase, let's
just get a bug and fix it.
--BDS
johnjbarton
...
>> 2) You can't test for an exported object from the service like normal:
>>
>> if (StorageService)
>>
>> becaues you get an exception. This seems to be a component feature,
>> since the line fails independent of any module. This test works:
>
> What's the exception?
Sorry I misspoke. I should have said "because it fails somehow and
(based on indirect evidence) causes the component getService() call to
fail, but you only get to see that if you delete the files in your
profile starting with "extension.*" just before you run".
Or to say this in the direct way: with the statement above, the
getService() call fails and if you force component registration by
deleting "extension.*" files, you can see the getService call failure
exception (but not the if () failure message).
(This is all different from my experience in FF 3.0/3.5 so I think
something changed, perhaps related to Ts work but also perhaps related
to the way I work now).
>
>> 3) Component.utils.reportErrors() is not trustworthy after all. This
>> works:
>
> Can you be more specific? What doesn't work? If you have a testcase,
Calls to Component.utils.reportErrors() have no visible result.
> let's just get a bug and fix it.
These problems cost me a day, but creating the test cases will cost me
two days. Based on past experience, I don't think this will get fixed,
even if we would all like it to be. The most likely people to fix it,
especially including you Ben, are all working on replacing this system.
And I would much rather have more discussion about the new directions
than fixes for the old one.
I hope these newsgroup posts will help someone else find a workaround,
including me in some future time.
jjb
>
> --BDS
Benjamin Smedberg
> Sorry I misspoke. I should have said "because it fails somehow and
> (based on indirect evidence) causes the component getService() call to
> fail, but you only get to see that if you delete the files in your
> profile starting with "extension.*" just before you run".
The general rule is that you cannot import JS modules from the top level of
a JS component because when the component JS is evaluated, we're still
registering components and you may not be able to use getService effectively.
> Or to say this in the direct way: with the statement above, the
> getService() call fails and if you force component registration by
> deleting "extension.*" files, you can see the getService call failure
> exception (but not the if () failure message).
Yes, what's different about this case is that we re-register all the
components, so they aren't already registered. After the first time, the
component registration info is cached, so we don't load the component until
somebody asks for it.
>>> 3) Component.utils.reportErrors() is not trustworthy after all. This
>>> works:
>>
>> Can you be more specific? What doesn't work? If you have a testcase,
>
> Calls to Component.utils.reportErrors() have no visible result.
>
>> let's just get a bug and fix it.
>
> These problems cost me a day, but creating the test cases will cost me
> two days. Based on past experience, I don't think this will get fixed,
> even if we would all like it to be. The most likely people to fix it,
> especially including you Ben, are all working on replacing this system.
> And I would much rather have more discussion about the new directions
> than fixes for the old one.
This kind of defeatist attitude really makes people not want to help you: I
can't even begin to solve the problem without a better description of what's
going on! And all of this infrastructure is going to exist, because Firefox
uses all of it, entirely independent of questions about new directions like
jetpack. There's serious motivation to fix it if it's broken.
--BDS
johnjbarton
> On 4/20/10 10:11 AM, johnjbarton wrote:
>
>> Sorry I misspoke. I should have said "because it fails somehow and
>> (based on indirect evidence) causes the component getService() call to
>> fail, but you only get to see that if you delete the files in your
>> profile starting with "extension.*" just before you run".
>
> The general rule is that you cannot import JS modules from the top level
> of a JS component because when the component JS is evaluated, we're
> still registering components and you may not be able to use getService
> effectively.
Can Components.utils.import() throw or fail so we don't have to guess?
>
>> Or to say this in the direct way: with the statement above, the
>> getService() call fails and if you force component registration by
>> deleting "extension.*" files, you can see the getService call failure
>> exception (but not the if () failure message).
>
> Yes, what's different about this case is that we re-register all the
> components, so they aren't already registered. After the first time, the
> component registration info is cached, so we don't load the component
> until somebody asks for it.
Unfortunately this mechanism is quite mysterious. I always have to
remind myself to start deleting profile files when things are acting
weirdly. The exact ways update works varies from time to time. Makes
development tedious.
I wish there was a way to 1) force re-register via command line and 2)
insure that the OS console does not get disconnected on re-register.
>
>>>> 3) Component.utils.reportErrors() is not trustworthy after all. This
>>>> works:
>>>
>>> Can you be more specific? What doesn't work? If you have a testcase,
>>
>> Calls to Component.utils.reportErrors() have no visible result.
>>
>>> let's just get a bug and fix it.
>>
>> These problems cost me a day, but creating the test cases will cost me
>> two days. Based on past experience, I don't think this will get fixed,
>> even if we would all like it to be. The most likely people to fix it,
>> especially including you Ben, are all working on replacing this system.
>> And I would much rather have more discussion about the new directions
>> than fixes for the old one.
>
> This kind of defeatist attitude really makes people not want to help
> you: I can't even begin to solve the problem without a better
> description of what's going on! And all of this infrastructure is going
> to exist, because Firefox uses all of it, entirely independent of
> questions about new directions like jetpack. There's serious motivation
> to fix it if it's broken.
Ben, if you or anyone else wants to explore these issues and see if we
can make improvements in any of this, I am happy to stop what I am doing
to help. But it's unfair to ask me to invest a lot of up front time to
enter a bug report with the expectation that it will just join all of
the other bug reports I've filed. I am not say you or anyone else here
is responsible for my past experience; I am saying that I have this
experience and it makes no sense to keep repeating it.
jjb
>
> --BDS
johnjbarton
Bug 560843 - jetpack breaks platform
jjb
>
> --BDS