Closed Bug 44338 Opened 26 years ago Closed 26 years ago

Classic skin not appearing in Preferences

Categories

(Core Graveyard :: Skinability, defect, P3)

Product:
Core Graveyard
Component:
Skinability
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 43091

People

(Reporter: gabriel, Assigned: bugs)

Details

Linux build 2000062914. Very probably a dupe, but: The Classic skin is in this nightly build. I was hoping to see it appear in Prefs|Themes.
I believe this has been resolved. Reporter, can you verify?
Works for me on 2000070408 on Linux.
Status: UNCONFIRMED → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
Linux build 2000070508. Very definately does *not* work for me. I go into Prefs|Themes, I still don't see any skins listed at all. Perhaps I am missing something. Do I need to install the skin somehow before I see it ?
perhaps a problem with your chrome directory? ben, any ideas?
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
I've got a fresh install of 2000070508. I can see the /usr/local/package/chrome/skins/classic directory. In /usr/local/package/chrome there is a file: installed-chrome.txt which contains (amongst other things) skin,install,url,resource:/chrome/skins/classic/
Oh and I also tried downloading the 'Sullivan' skin from Alphanumerica, which froze Mozilla after it had loaded, so I don't necessarily expect the Classic skin to work (that would be a separate bug).
Reporter: so is your original bug still happening?
Yes, as of build 2000071108 I can confirm that 'classic' is appearing in Prefs, and what's more it works !!! Thanx !
wfm based on reporter's comments
Status: UNCONFIRMED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → WORKSFORME
Disappeared again from Linux build 2000071308. Reopening.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
with build 20000120 on linux, themes do not show up in the preferences dialog when mozilla is run by a non-root user. Cause: permissions in the chrome directory are wrong. Fix: chmod go+r /usr/local/package/chrome/*
Reporter: I imagine that you remember to do a fresh install this time?
sorry for the typo in my previous comment. my install is 200071720, not 20000120 so it's rather fresh! (the '7' key is screwed up my keyboard :-)
Ok, here is what I get with a build from yesterday (2000071810) after I reinstall mozilla from scratch, the /usr/local/package/chrome directory reads: total 24 drwxr-xr-x 5 8482 wheel 4096 Jul 18 20:15 . drwxr-xr-x 9 8482 wheel 4096 Jul 18 20:32 .. -rw-r--r-- 1 8482 wheel 537 Jul 18 20:32 installed-chrome.txt drwxr-xr-x 4 8482 wheel 4096 Jul 18 18:56 locales drwxr-xr-x 6 8482 wheel 4096 Jul 18 18:47 packages drwxr-xr-x 4 8482 wheel 4096 Jul 18 18:39 skins At this point if I run mozilla as non-root, the themes do not show up in the preference dialog. If I run it as root, they do, and the directory's content is modified: total 48 drwxr-xr-x 6 8482 wheel 4096 Jul 19 12:35 . drwxr-xr-x 9 8482 wheel 4096 Jul 18 20:32 .. -rwx------ 1 root root 5853 Jul 19 12:35 all-locales.rdf -rwx------ 1 root root 3934 Jul 19 12:35 all-packages.rdf -rwx------ 1 root root 7003 Jul 19 12:35 all-skins.rdf drwxr-xr-x 4 8482 wheel 4096 Jul 18 18:56 locales drwx------ 6 root root 4096 Jul 19 12:35 overlayinfo drwxr-xr-x 6 8482 wheel 4096 Jul 18 18:47 packages drwxr-xr-x 4 8482 wheel 4096 Jul 18 18:39 skins -rwx------ 1 root root 1114 Jul 19 12:35 user-locales.rdf so the file installed-chrome.txt seems to be converted into the new files, with root-only permissions. After this, if I run mozilla as non-root, themes still do not show up. In order to have them show up for non-root users, I need to do a 'chmod go+r *' in the chrome directory (as root). So these files are probably given wrong permissions when generated.
Bug 45107 lists some cases where this might happen. Please read through the comments there...
Severity: minor → normal
Noticed skins are now appearing on the second and subsequent startup. Could this now be a duplicate of bug 46013 ?
No, ignore that. Just noticed I went in as root the first time. Can confirm that going in as root is necessary to create the .rdf files though.
I'm going to be lazy. 41057 is the meta for this sort of stuff. If someone wants to figure out if this is a dupe or otherwise, feel free to follow the dependency tree.
Blocks: 41057
Can I suggest that you release note the fact that you need to fire up Mozilla as root before themes appear, if it's not resolved in time for beta2.
try 'chmod -R go+r /usr/local/package/chrome/'
This is a dup of bug 43091 *** This bug has been marked as a duplicate of 43091 ***
Status: UNCONFIRMED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → DUPLICATE
I think the fix for bug 43091 may only solve half the problem. The other problem is that the chrome directory has these permissions: drwxr-xr-x 6 8482 wheel 1024 Jul 31 20:14 chrome/ so it might still be necessary to run mozilla once as root to create the .rdf files.
Depends on: 43091
Yes, currently it is necessary for mozilla to be run once as root as part of the normal install process so that the rdf files can be created. See my comments in bug 41057 about this. Also, bug 42184 is a bug that is attempting to fix this. Please add any comments about this to that bug. Removing dependencies since this bug has been marked as a dup which already has those dependencies. Gabriel, also when you unpacked the files for some reason they were owned by a user with uid 8482. This is fairly common with *nix tarballs, that whoever created the tarball had a user with this uid that the files belonged to. So you should probably do a chown -R root.root bin/ or chown -R root.wheel bin/ depending on your setup.
No longer blocks: 41057
No longer depends on: 43091
vrfy dup
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.