101271 - new button is the only button that works for non-root user

Status: RESOLVED WORKSFORME

(SeaMonkey :: Installer, defect)

Description

[Duaine Hechler]

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

Comment 1

[Kathleen :Brade]

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)

Comment 2

[Duaine Hechler]

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

Comment 3

[Syd Logan]

WFM.

Comment 4

[sujay]

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

Comment 5

[Duaine Hechler]

Broke again in the new version 0.9.5-1

Comment 6

[Syd Logan]

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?

Comment 7

[Duaine Hechler]

There ssems to be a trend in functionality of root and non-root users.

Reference my comments in bug 107443

Comment 8

[Charles Manske]

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.

Comment 9

[Syd Logan]

reassigning to me

Comment 10

[R.K.Aa.]

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

Comment 11

[Syd Logan]

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.

Comment 12

[Syd Logan]

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

Comment 13

[Syd Logan]

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.

Comment 14

[Daniel Veditz [:dveditz]]

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?

Comment 15

[Peter Trudelle]

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

Comment 16

[Brian Ryner (not reading)]

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.

Comment 17

[Syd Logan]

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?

Comment 18

[Brian Ryner (not reading)]

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).

Comment 19

[Daniel Veditz [:dveditz]]

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.

Comment 20

[John Morrison]

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?].

Comment 21

[Peter Trudelle]

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

Comment 22

[Peter Trudelle]

nsbeta1- per ADT triage team, ->1.2

Comment 23

[Alexander Opitz]

Reporter:

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

Comment 24

[Sven Krohlas]

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.