Closed Bug 389783 Opened 17 years ago Closed 14 years ago

Seamonkey 1.1.3 Navigator works for one user, broken for others.

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Version:
SeaMonkey 1.1 Branch
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: paul, Unassigned)

References

Details

Attachments

(1 file)

Screenshot of the breakage in 1.1.3
21.06 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.3

This problem has been observed on an iMac G5 running OS 10.3.9 and a MacBook Pro running OS 10.4.10.  Seamonkey 1.1.2 does not have this problem.

I installed 1.1.3 and Mail and Navigator worked fine while logged in as myself.  When I log is as any other users, Mail works OK, but Navigator is broken.  Most items disappear from the menu bar, Bookmarks are gone and there is extra space at the very bottom of the frame where fragments of text that look like HTML are displayed.  When I revert to 1.1.2 the problem goes away.

Reproducible: Always

Steps to Reproduce:
1.  Install Seamonkey 1.1.3
2.  Log in as a different user
3.  Observer problems with Navigator.
Actual Results:  
See Details.

Expected Results:  
Navigator should work the same for all user accounts on the computer.
Version: unspecified → SeaMonkey 1.1 Branch
I confirm this bug in SeaMonkey 1.1.3. 

The problem appears whenever you start SeaMonkey 1.1.3 with a new profile, or with a profile where a theme has not been set yet. If you go to View -> Apply Theme, select a theme (either Classic or Modern), and restart the browser, it appears as normal again. This has to be done every time a new profile is created for the browser to work (such as when adding a new user to the computer). 

In previous versions of SeaMonkey, the default theme was Classic. Now with 1.1.3 it appears that the default theme changed to Modern. Perhaps this change has something to do with the breakage? The Modern theme still works, you just have to select it in the theme chooser for it to stop breaking. 

Just to check, I also installed the latest Nightly of the 1.8 branch (20070730) and it is still broken there, too. 


Screenshot of the breakage. This is with a clean (new) profile after installing 1.1.3. No extensions have been installed. 

Note the missing title bar. The window cannot be moved or resized at all. The white area in the status bar is transparent.
(In reply to comment #1)
> I confirm this bug in SeaMonkey 1.1.3. 
> 
> The problem appears whenever you start SeaMonkey 1.1.3 with a new profile, or
> with a profile where a theme has not been set yet. If you go to View -> Apply
> Theme, select a theme (either Classic or Modern), and restart the browser, it
> appears as normal again. This has to be done every time a new profile is
> created for the browser to work (such as when adding a new user to the
> computer). 
> 
> In previous versions of SeaMonkey, the default theme was Classic. Now with
> 1.1.3 it appears that the default theme changed to Modern. Perhaps this change
> has something to do with the breakage? The Modern theme still works, you just
> have to select it in the theme chooser for it to stop breaking. 
> 
> Just to check, I also installed the latest Nightly of the 1.8 branch (20070730)
> and it is still broken there, too. 
> 

In my case, I saw the breakage for users who had already been added and who already had profiles.  I tried creating a new profile for one of the users and Seamonkey wouldn't start at all with that profile.  I also thought it might have something to do with the theme setting.  I noticed that the theme appeared to be unset for the other users.  Setting it didn't help.

Thanks for verifying the bug.
(In reply to comment #3)

> In my case, I saw the breakage for users who had already been added and who
> already had profiles.  I tried creating a new profile for one of the users and
> Seamonkey wouldn't start at all with that profile.  I also thought it might
> have something to do with the theme setting.  I noticed that the theme appeared
> to be unset for the other users.  Setting it didn't help.

It might be worth noting that I didn't use View->Apply Theme to try and set the theme.  I tried setting it through the Preferences->Appearance->Themes route.


(In reply to comment #1)

Actually, the broken theme looks like a mix between Classic and Modern. The dark gray color is from Modern, some of the icons are from Modern (Home, the bookmark icons, the halfway visible Print button), but some of them are from Classic (Back, Forward, Stop). 

Looks like the default theme was being changed to Modern (don't know whether this was the intention) but that it wasn't completely changed over yet. 

The problem remains in SeaMonkey 1.1.4. 

The problem still exists in SeaMonkey 1.1.5.
(In reply to comment #7)
> The problem still exists in SeaMonkey 1.1.5.
> 

and 1.1.6.
(In reply to comment #5)
> Actually, the broken theme looks like a mix between Classic and Modern.

Similar problem on Theme to Bug 394713 Comment #14? (problem on "language pack")
See also Bug 389136 for problem on chrome\chrome.rdf when "write protected program directory".
Note:
Bug 394713 itself is problem on chrome\chrome.rdf when "write protected program directory". And Bug 394713 Comment #14 is about different problem on "language pack" when "write protected program directory".

Is program directory set as "Read only" for the users?
Will "write permission" alter phenomenon?
This bug seems to be fixed in 1.1.7.  I have verified it on an iMac G5 running OS 10.3.9 and a MacBook Pro running OS 10.4.11.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
No reference to the specific bug or patch that fixed this.
Resolution: FIXED → WORKSFORME
(In reply to comment #11)
> No reference to the specific bug or patch that fixed this.
> 

See comment #9.
This bug is back in SeaMonkey 1.1.8.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
(In reply to comment #13)
> This bug is back in SeaMonkey 1.1.8.

Bug opener of Bug 389136 says following files were created in chrome by write-permitted user. Problem on chrome.rdf looks to be already resolved in Bug 389136. So it seems that remaining problem is on overlays.rdf(or stylesheets.rdf) when Bug 389136.
> /applications/SeaMonkey 1.1.8/SeamOnkey.app/Contents/MacOS/chrome
> -rw-r--r--  1 admin1  admin    48646 Feb 14 11:56 chrome.rdf
> -rw-r--r--  1 admin1  admin     6920 Feb 14 11:56 overlays.rdf
> -rw-r--r--  1 admin1  admin      490 Feb 14 11:56 stylesheets.rdf

What files were created by write-permitted user in your case?
(Check both chrome & components directory, please)
Do you use localized version of Seamonkey or lang-pack?
Do you add Theme(s) in program directory instead of profile directory?


(In reply to comment #14)

This problem still exists in SeaMonkey 1.1.9.

I checked the chrome and components directory on my installation and all files (including the three listed) in those directories are owned (and I assume created) by the write permitted user and are writeable only by that user.

/applications/SeaMonkey.app/Contents/MacOS/components
-rw-r--r--    1 pmd  admin    120138 Apr  2 21:38 xpti.dat
-rw-r--r--    1 pmd  admin    160040 Apr  2 21:39 compreg.dat

/applications/SeaMonkey.app/Contents/MacOS/chrome
-rw-r--r--   1 pmd  admin      490 Apr  2 21:39 stylesheets.rdf
-rw-r--r--   1 pmd  admin     6920 Apr  2 21:39 overlays.rdf
-rw-r--r--   1 pmd  admin    48646 Apr  2 21:39 chrome.rdf

I think I'm using the localized version.  I haven't added any themes.
I am seeing this exact same problem with SeaMonkey 1.1.9 running on a MacBook
with Mac OS X 10.5.2.  Does anyone know of a reliable work-around for this
problem?  As it is now, my son cannot run SeaMonkey any longer from the Mac OS X system-wide Applications folder.  He now has to run it directly from the downloaded .dmg file.

FYI, I reported bugs 389136 and 432327, which seem to have similar symptoms;  i.e. SeaMonkey cannot be run from a common system-wide copy and global SeaMonkey applications files that probably should be read-only can and are updated when SeaMonkey is run on the account that installed it.

(In reply to comment #16)

The workaround I'm using is to use version 1.1.7 until the problem is fixed.
You can download it here: http://www.seamonkey-project.org/releases/1.1.7
(In reply to comment #17)
> (In reply to comment #16)
> 
> The workaround I'm using is to use version 1.1.7 until the problem is fixed.
> You can download it here: http://www.seamonkey-project.org/releases/1.1.7
> 

The problem is still there in 1.1.7 if you are using Leopard (OS X 10.5.x).  This version worked OK with Tiger and Panther, but I've noticed the problem again after upgrading to Leopard (oh well).
This bug has been reported against SeaMonkey 1.1 which is no longer supported. Also no comment suggested that it is still valid against SeaMonkey 2. If you see the same or similar issue with SeaMonkey 2.0 or later please open a new bug. Thanks.

Since I don't know whether the underlying issue has been fixed (I don't even have a Mac) or would need fixing at all I'm closing this as INVALID instead of WONTFIX or WFM.

If you cannot update to SM 2.0 or later you could, as a last resort, try the latest version of the 1.1 branch, SeaMonkey 1.1.19. In any case this bug would never be fixed if it hasn't been already so please leave this bug alone. Again, if you can reproduce with SeaMonkey 2.0 or later, please open a new bug.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago → 14 years ago
Resolution: --- → INVALID
This problem has been fixed in SeaMonkey 2.0.  Thanks.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: