Seamonkey 1.1.4 won't start for new users

[mathog]

Summary: With Seamonkey 1.1.4 (and possibly somewhat earlier) a new user cannot start
Seamonkey if the Administrator account has a "toxic" profile. The "toxic" profile works just
fine for the Administrator account though.

Long story:

This first showed up with new network Domain users, but it seems to be present for all new users,
and since it's simpler I'll present the problem for local users only.

When a new local account tries to run Seamonkey 1.1.4 this pops up:

XML Parsing Error: undefined entity
Location: chrome://communicator/content/profileSelection.xul?manage=true
Line Number 53, Column 1:

<dialog
^

This doesn't happen for:

1. The administrator account (local, machine domain)
2. LocalUser (existing local account, machine domain)

both of these accounts have been using Seamonkey since (much) earlier versions. They have
existing Profiles which have been around for a long time.

I tried copying
C:\Documents and Settings\LocalUser\Application Data\Mozilla\Profiles
to
C:\Documents and Settings\NewUser\Application Data\Mozilla\Profiles
after first deleting the NewUser Profiles. It didn't help, same error. The security showed
that ownership had transferred appropriately.


Then I hid ALL of the Profiles:
default User
LocalUser
Administrator

and ran Seamonkey as the Administrator. It created a new Profile. After that LocalUser
could start Seamonkey. It did have to create a default user profile though, and it still
had to first delete the "default" profile that Seamonkey sort of created, but then claimed it
couldn't open. (That is, it came up with "default" in the profile list, but couldn't open that.)

So...

Apparently there is some bizarre incompatibility between an existing Administrator Profile
and the creation of a new account's Profile, if the Administrator's Profile has been around since
well before Seamonkey 1.1.4. A newly created Administrator Profile, made with 1.1.4,
does not have this effect. Why a new regular user's account should care about the
Administrator's Profile I have no idea, but apparently it does.

[Ryo-Ohki]

Same error with 1.1.4 here (just upgraded from 1.1). However my context is a bit different. I have several users on my Windows XP PC (the default Windows admin, and two simple users) and one of the users has created quite some time ago several profiles for SeaMonkey (one for home, one for work).

After upgrading to 1.1.4 the user with two profiles gets the profileSelection.xul error where he should receive the dialog to choose a profile to start with. The user with the single profile still can use SeaMonkey as usual. Nothing has changed from 1.1 so the error must be 1.1.4 specific.

[Ryo-Ohki]

A little more digging with filemon.exe appears to indicate that when launching it with the "broken" account, SeaMonkey tries to create a chrome.rdf over the one which is already existing in the installation folder. This the account is a simple user, the operation fails, and loops over and over until the error is produced.

This behaviour with chrome.rds doesn't appear either with the admin account or the second user account, which is working normally.

[therube]

Change the permissions of the /chrome/ folder so that the Limited user can write to it?

[Philip Chee]

See Bug 389136 – XML errors when application chrome.rdf exists but is read-only

Phil