275992 - Javascript exception, possibly due to not following proper installation procedure

Status: RESOLVED DUPLICATE of bug 247862

(Toolkit :: Add-ons Manager, defect)

Description

[Ian]

In the JavaScript

Error: uncaught exception: [Exception... "Component returned failure code:
0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.copyTo]"  nsresult:
"0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)"  location: "JS frame ::
file:///usr/local/firefox/1.0/components/nsExtensionManager.js ::
nsInstalledExtensionReader_read :: line 800"  data: no]

This may have been caused by the way I installed Firefox 1.0
in SuSE 9.1

Being rather paranoid, I installed to an ordinary user account,
copied to /usr/local/firefox/1.0, and changed group:user to
root:root

Installing as user may have configured firefox to write temporary
files to a subdirectory, which will not be possible when running
as an ordinary user in a directory tree that can only be written to
by root.

If that is what is happening, you can close this report immediately,
because I would the cause of the problem.

Best regards and thanks for an excellent browser.

Comment 1

[Nickolay_Ponomarev]

did you run as root at least once before running as an ordinary user?

Comment 2

[Nickolay_Ponomarev]

From mail:
---

I did not run as root before running as ordinary user.

I installed as ordinary user, moved the files to /usr/local/firefox/1.0/
and changed the entire subtree owner:group to root:root

This is why the problem may have been caused by the user (me!).

I do things this way because I try to avoid the use of root privileges
whenever possible; I don't know a lot about security, but am quite
paranoid, and try to stick with simple methods.  In this case, I used
root privileges only to transfer the directory tree and change ownership,
thereby making it impossible for ordinary users to corrupt the files.
Unfortunately that also makes it impossible for firefox to make legitimate
use of files in the same tree, which may be why I found a problem.

Comment 3

[Nickolay_Ponomarev]

You should have (or at least you shouldn't have chown'ed firefox app dir before
first startup). That should fix your problem. I don't think Firefox is supposed
to break in this case though, so I won't close the bug now.

Comment 4

[Nickolay_Ponomarev]

It's in Known Issues, number one.
I can't find the bug however.

http://www.mozilla.org/products/firefox/releases/#issues

quote:
If you install Firefox on a multi-user system in an area in which there is
restricted access privileges, you must run Firefox as a user with access to that
location upon installation so that all initial startup files are generated. If
this is not done, when a user without write access to the install location
attempts to start Firefox, they will not have sufficient privileges to allow
Firefox to generate the initial startup files it needs to.

Comment 5

[Nickolay_Ponomarev]

*** This bug has been marked as a duplicate of 247862 ***

Comment 6

[Ian]

The comments tell me how to avoid the problem in the future.  If this 
information is already in a part of the install documentation that I 
missed, there is no bug to fix.  All I had to was run first from a user 
account, then move and chown the files. 
 
Thanks 
 
Ian