Closed Bug 808361 Opened 12 years ago Closed 2 years ago

/lib64/firefox/extensions/%7B972ce4c6-7e08-4474-a285-3208198ce6fd%7D/chrome.manifest not loading

Categories

(Core :: JavaScript Engine, defect)

16 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: eb30750, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20121026114414

Steps to reproduce:

Attempting to use the IDL Components.interfaces.nsILocalFile service.  In checking the current documentation of Aug 8, 2012 for nsIFile and nsILocalFile snippets for current usage show that the class needs to be instantiated and then it can be called.  There is no mention of enabling or adding any extensions in chrome. 


Actual results:

Previously it was necessary to use netscape.security.PrivilegeManager.  After removing these statements I now get a "Components.classes is undefined" error.  But yet when I open the javascript error log and enter "var inFile=Components.classes["@mozilla.org/file/local;1"].createInstance(Components.interfaces.nsILocalFile); if(inFile != "") alert("got to here " + inFile); " It returns "got to here [xpconnect wrapped nsILocalFile]" which indicates that it has been instantiated.

I am also receiving this error in the log:  Could not read chrome manifest 'file:///usr/lib64/firefox/extensions/%7B972ce4c6-7e08-4474-a285-3208198ce6fd%7D/chrome.manifest'.


Expected results:

If the class component instantiates correctly from the javascript error log then I would expect my javascript code to instantiate the class component too.  Not only have I used the javascript error log to instantiate nsILocalFile component but also added initPath with a valid local file name and it too has returned a valid handle.  If I can successfully invoke this class component from the javacript error log (using evaluate) then why can't I in my javacript code?
Reporter, could you please provide a testcase and/or some more detailed steps to reproduce this?
I am performed some basic testing here are the results.

1) I use a browser helper to read a comma delimited file, parse it and then write out to a file an html document.  The helper program then performs a excel() to start a new copy of FF.  This allows the user to only make one click to launch the datafile into FF.  Here are my two copies of FF running on Linux.  The second one is the copy that was created via excel().

EBxxxxx   1870     1 10 10:27 ?        00:11:10 /usr/lib64/firefox/firefox
EBxxxxx   6234     1  9 12:11 ?        00:00:11 /usr/lib64/firefox/firefox -no-remote -P AppProfile -new-window /usr/tmp/mimeMap/drf/drfLaunch.html

2) I have not seen the manifest loading error when using my "browsing" copy of FF.  And, I only see the manifest error when I launch the helper program.  If the I use "file open" from the File menu to open the html that the helper program created I do not see the manifest load error.

3) I have confirmed that the manifest loading error occurs early like before the user ever clicks in active html inputs I can go to the Error Console and see the manifest loading error.  I may need to drill down deeper and exit the code at different points and see if I can bracket where the loading error occurs.  It could be that is indeed occurring at launch as the error indicates.

4) Do you have any feedback on why the "Code" line of the Error Console can directly access the Mozilla XPCOM calls registered in the chrome and embedded javascript cannot?  I need to know how I can do this from javascript without creating my own set of extensions that mimic the existing Component.Classes due to the privilege manager being eliminated in FF17
I was able to confirm that the manifest loading error is originating when FF is started from an overlay using excel() within my helper program.

I added the two lines of code so that the first thing the my helper program did is to overlay FF.  When I examined the Error Console the manifest loading error was there.  The user "Profile" is not my default profile.  This is how I get two instances of FF running concurrently.

int main(int argc, char *argv[])
{

  execl("/usr/bin/firefox", "/usr/bin/firefox", "-no-remote", "-P", "AppProfile", "-new-window", "about:blank", (char* )0 );
  return 0;
I have completed additional tests where I open the output of the helper program from my conventional FF browser that I use for surfing the web.  In this case there is no manifest loading error.  When I open the HTML file that is the output of my helper file I do get permission errors but I do not get the components.classes undefined error.  The permission errors are due to the netscape privilege manager being deprecated and cross domain security being strictly enforced.  This is another issue that will potentially require building an extension and outside of the scope of this bug.  

Until FF 16 I did not encountered this manifest loading error.  Also, I do not experience the this manifest loading error when using an instance of FF 16 that has been launched by Applications->Internet->Firefox.
In performing subsequent FF debugging searches, I happened across this explanation for this error.

"{972ce4c6-7e08-4474-a285-3208198ce6fd} is the ID of the default Firefox theme. And sure enough - it doesn't have a chrome.manifest file so this warning comes up on every browser start. Just ignore the warning."

There are hundreds, maybe thousands, reports of this being a bug and it is confusing users and developers since if other FF features are not working they immediately believe this error is the cause when, in fact, it is not.  The FF software needs to fixed so that if this is not an error is it not reported as one.  If errors are to be ignored then they are not errors.
Assignee: nobody → general
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
I got this in an "error console" window on every restart when I had two conflicting add - ons at once (all in one gestures and firegestures).
Assignee: general → nobody
If this is to become the "fix default theme warnings" bug, this is also a console-spew issue:

1409764909591   addons.update-checker   WARN    Update manifest for {972ce4c6-7e08-4474-a285-3208198ce6fd} did not contain an updates property
See Also: → 1116223
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.