From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914 BuildID: 2001092020 Reproducible: Always Steps to Reproduce: 1.logon as non-root user 2.open composer 3.tried to open an html file with the open button Actual Results: Nothing, open button is grayed out Expected Results: Open button should open a file list window just like it does as a root user

Is this our focus bug? or our cache bug? or something else? Duaine Hechler--What is the Advanced > Cache preference set to? Once? Never? Always? (there are 4 radio buttons)

The cache preference is set to "Once per session". Also, I reported the bug on 0.9.4-3 and it seems to have fixed itself when I downloaded 0.9.4-4. Duaine

WFM.

marking VERIFIED-FIXED. Reopen if you can reproduce the bug or you think its still valid.

Broke again in the new version 0.9.5-1

Could you do me a favor and install mozilla or netscape as a non-root user in some different location than the currently installed browser, and try again, logged in as that same user? And tell me the results? Charley, do we do any permission checking-type stuff to enable or disable that button?

There ssems to be a trend in functionality of root and non-root users. Reference my comments in bug 107443

Just about all of the Composer commands check "window.editorShell.documentEditable". I suspect that that flag must become false for the "non-root user" case discussed in this bug. The "New" command is implemented in global code and thus is not checked. I'm not the right person to look into this problem.

reassigning to me

dup of bug 97663? If cache is set to compare "Every Time" or cache size is 0, buttons and menus are greyed out.

Reporter, need you to try my steps in comment 6. Also, please do an ls -l on the file you are opening and paste that here as a comment, along with the results.

I think one problem is the chrome directory after install is not writable except as root.

We also get horked in other ways, like the profile window comes up with no profiles, and buttons are missing in the profile creation wizard. I found out that the permissions on chrome.rdf are the problem, this needs to be readable and writable by everyone. Assigning to hyatt, marking nsbeta1+ since there are plenty of admins installing the product as root with the intention other users can then run the product.

hyatt: how can this be nsbeta1+ (i.e. desired by mgmt for this release) and Future at the same time? It's OK that non-root Linux users are screwed, and that it used to work? Is there something the installer can do to force the chrome registry to write out whatever it is that's missing on first run (as we used to), or did some recent change require chrome.rdf to always be writable?

Yeah - Why, Dave, why? ;-) cc bryner for possible assistance here.

I'm pretty sure this is all covered by the release notes <quoting from 0.9.7 release notes>" Multi-user installs: To install Mozilla for multiple users on Unix, install as normal, then create the following script in your Mozilla directory, make it executable (chmod u+x <scriptname>), and run it as root. #!/bin/sh dist_bin=`dirname $0` MOZILLA_FIVE_HOME=$dist_bin LD_LIBRARY_PATH=$dist_bin export MOZILLA_FIVE_HOME LD_LIBRARY_PATH $dist_bin/regxpcom $dist_bin/regchrome touch $dist_bin/chrome/user-skins.rdf $dist_bin/chrome/user-locales.rdf You should then be able to run that installation of Mozilla as any user who has permissions to access it.

Heh. Doesn't that seem a bit much to ask users to do? Better thing would be to hack the installer to realize it is running as root and have it to that just before it terminates. Or something. Of course, that wouldn't help the RPM installers any. Also, I found I was runnable after changing chrome.rdf, not any of the files in your script. What is the real story?

syd, when the installer runs mozilla after the install completes, that will have the same effect. The only case where I can imagine this happening is if the user installed from a tarball. I just tried on the just-posted 0.9.8 tarball and didn't see any problem like this either (which could happen if regchrome was run before it was packaged).

The installer launches Mozilla at the end, which will do the equivalent of regxpcom and regchrome. user-locales.rdf and user-skins.rdf no longer exist (merged into chrome.rdf) so those parts of the instructions are useless, although they do hint at what may be missing. RPMs ship with pre-generated chrome files in order to avoid this problem. Syd's experience, documented in the related profile manager bug I think, was that root could run the install fine, but even after that a non-root could not unless given write permission on chrome.rdf. So it's not a matter of the contents of the file it's simply a matter of someone failing if they don't get write permissions.

I just ran the current 0.9.8 candidate build installer as root on Linux, and after the initial run of the browser, I tried to run this build on the same system as ~jrgm. I had no problems with running this build: the open button in composer works, the correct profiles are visisble in profile manager and the UI for profile manager, composer and navigator appears correct (without trying every thing in the build). It is, in general, not true that anything is written to chrome/chrome.rdf and chrome/overlayinfo/* after the first run of the browser. If installed-chrome.txt is older than chrome.rdf, then chrome registration is not (redundantly) done. (See about line 2950 in nsChromeRegistry.cpp; correct me if I'm wrong). It is possible that if installed-chrome.txt is 'touched' then that would trigger the need for re-running chrome registration, but I'm not sure if that's ever the case (or, rather, that someone as 'root' causes this timestamp to be changed, but the next run of the app is as a non-root user). [What happens with xpi installs on linux; is there a way that this is possible?].

Mass move of nsbeta1+ bugs that didn't have a valid MachV milestone to mozilla1.0.

nsbeta1- per ADT triage team, ->1.2

Reporter: Does this bug exists in newer (1.5) builds? If not then please close this bug as WorksForMe.

WFM Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7a) Gecko/20040202 Reopen if your opinion is different and you can reproduce this with a current build.