Closed Bug 389136 Opened 17 years ago Closed 15 years ago

XML errors when application chrome.rdf exists but is read-only

Categories

(SeaMonkey :: Startup & Profiles, defect)

Product:
SeaMonkey
Component:
Startup & Profiles
Version:
SeaMonkey 1.1 Branch
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: dickie, Assigned: neil)

References

Details

(4 keywords)

Attachments

(4 files)

Process Monitor log(CSV), write-permited pgm-dir, chrome.rdf exists, replaced by new one
57.68 KB, text/plain
Details
Failure starting 1.1.5 from a virgin OS X standard user acct. which did not install SM.
48.27 KB, image/png
Details
Proposed patch [(1.8 branch) Checkin: Comment 35]
1.71 KB, patch
ajschult784
: review+
kairo
: approval-seamonkey1.1.6-
kairo
: approval-seamonkey1.1.8+
Details | Diff | Splinter Review
Mac patch [(1.8 branch) Checkin: Comment 50 & 51]
2.14 KB, patch
rbgray
: review+
kairo
: approval-seamonkey1.1.8+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.3


After upgrading to SeaMonkey 1.1.3 this message is display and SeaMonkey does not prompt for the profile:

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

<dialog
^


Reproducible: Always

Steps to Reproduce:
1.  Upgrade to SeamOnkey 1.1.3 from 1.1.2
2.  Use multiple SeaMonkey Profiles
3.  Note that SeaMonkey does not prompt for a profile
4.  SeaMonkey display the error window and does not start
5.  SeaMonkey 1.1.2 still works fine
Actual Results:  
SewMonkey 1.1.3 does not start

Expected Results:  
SeaMonbkey 1.1.3 should prompt for one of the two available profiles
Seamonkey, thus no "-safe-mode"...

"seamonkey.exe -p"(-p but does't specify profile name) will kick profile manager even when single profile. Did you try it? What is the result when "-p"? 

Read following MozillaZine Knowledge Base article, and execute several steps in "step 5" first (deletion of "XUL FastLoad File" and "localstore.rdf").
http://kb.mozillazine.org/Standard_diagnostic_-_Mozilla_Suite
I tried these steps in step 5:

a)  Looked for "XUL FastLoad File" in both of my profiles, but it does not exist.

b)  Deleted "localstore.rdf" in each of my two profiles, but that did not fix the problem.

c)  Deleted the "chrome" folder in each of the profiles, but that did not fix the problem.  The "extensions" folder does not exist.

d)  I cannot try creating a new profile because SeaMonkey 1.1.3 will not start.


In addition to the steps I tried above, I also tried starting SeaMonkey 1.1.3 from a Mac OS X terminal window.  I can start SeaMonkey 1.1.3 with either of my profiles using these commands and I can switch between them using Tools->Switch Profile.

  ./seamonkey-bin -P A_DSL
  ./seamonkey-bin -P B_VPN


But these commands failed with the same error message as originally reported:

  ./seamonkey-bin -P
  ./seamonkey-bin -ProfileManager


Location of "XUL FastLoad File" and Cache directory is changed to outside of profile directory.
See Bug 216204 Comment #14.
(In reply to comment #0)
> XML Parsing Error: undefined entity
> Location: chrome://communicator/content/profile/profileSelection.xul
> Line Number 53, Column 1:

This error of Seamonkey is being processed by Bug 376173, but Bug 376173 has keyword of "fixed-seamonkey1.1.3" (still open though).
Setting 376173 in "Depends on:".
Please DUP to 376173 and remove dependency if it'll be found to be DUP.
Depends on: 376173
I deleted the XUL.mfasl file from both of the profiles in ~/Library/Caches/Mozilla/Profiles/, but that did not fix the problem.

Dick, this is supposed to be fixed in bug 376173 - can you please give a detailed description of how you installed 1.1.3?
I installed SeaMonkey 1.1.3 by downloading it from the Version Tracker site.  The disk image mounts and I copy the SeaMonkey application to a new folder in my system Applications folder.

You should note that I have migrated from Netscape to Mozilla and then to SewMonkey allowing each version to copy and upgrade my preferences and profiles.  And SeaMonkey 1.1.3 works fine with my other user accounts that have only one profile.  Ang going back to 1.1.2 works fine with my two profiles.

Something is wrong with this one installation then...

Are you sure you are not launching SeaMonkey from the disk image itself but did drag the SeaMonkey app out of the image before launching it?
(In reply to comment #3)
> In addition to the steps I tried above, I also tried starting SeaMonkey 1.1.3
> from a Mac OS X terminal window.  I can start SeaMonkey 1.1.3 with either of my
> profiles using these commands and I can switch between them using Tools->Switch
> Profile.
> 
>   ./seamonkey-bin -P A_DSL
>   ./seamonkey-bin -P B_VPN

Hmm, so in this case you can bring up the profile manager from "Tools-->Switch profile..."? This is odd.
Yes, I am launching SeaMonkey from a folder in the system Application folder.  The installation disk image is no longer mounted, and as I recall, the installation disk image file has been deleted from my download folder.  So yes, it is being launched from the Applications folder.

Since this problem is easily reproducible, let me know if you want me to run some debug version of SeaMonkey to further track down the cause of this problem.


I tried to work-around this problem by moving these files out of my ~/Library folder, and SeaMonkey 1.1.3 then starts.  But the browser window displays what looks like some kind of XML text along the bottom of its window and the Mac OS menu bar shows only SeaMonkey.  So at this point I must have missed something and I cannot even start from scratch.  Here is what I moved out:

~/Library/Caches/Mozilla
~/Library/Mozilla
~/Library/Preferences/org.mozilla.seamonkey.plist

If this problem cannot be fixed soon, could someone help me start from scratch and then copy back my original two profiles?

Thanks.

OK, I think I know what is happening.

It looks like SeaMonkey 1.1.3 is updating a global file or resource when it is executed on an administrator account on Mac OS X.

When I install a fresh copy of SeaMonkey it works fine on my normal user account with two profiles.  But as soon as I execute the same copy of SeaMonkey on my administrator account, the normal user account with two profiles starts getting the error and will not start.  By refreshing the SeaMonkey application, the problem  goes away until I again run that copy of SeaMonkey on an administrator account.

Note that running SeaMonkey on another normal user account does not cause the error, probably because a normal user account does not have permission to update the SeaMonkey application.

Let me know if I can help track down exactly what file or resource is involved.


Does the administrator account use the same profiles or different ones?
If it's the same, then we have the problem, as SeaMonkey always needs write access to the profiles.
If not, I'd suspect that chrome/chrome.rdf in the .app is heavily involved in the problem.
No, the administrator account has its own profiles in ~/Library/Mozilla/Profiles, as do all users on Mac OS X.

As a work-around, I changed the administrator account's owner permission on the SeaMonkey application to read-only.  This corrected the problem with the normal user account with two profiles without having to refresh the SeaMonkey application.  But it does not show which global file is being updated that probably should be read-only.

When Win version of Seamonkey, following files are found in write-permitted program directory only(all other files have same timestamp and same file size.)
 A. Seamonkey 1.1.4 (ZIP build)
    chrome\chrome.rdf      (also in chrome in profile) 
    components\compreg.dat (not found in profile)
    components\xpti.dat    (not found in profile)
 B. Seamonkey trunk 2007/9/17 build
    chrome\app-chrome.manifest (not found in profile)
    components\compreg.dat     (found in profile)
    components\xpti.dat        (found in profile)
Trunk still writes compreg.dat & xpti.dat in program directory if write-permitted, and trunk writes them in profile too.

The .dat files are usually not the problem, they only cache data and get even only created in memory if no possibility to write is there. You could try to delete them as an admin and try if it changes anything, but I'd suppose not.

chrome.rdf is probably something that plays into this, as I said in comment #14 already.

This is a bug about branch, so the statement about trunk is useless, I'd suspect that trunk behaves completely differently due to different chrome and profile management.
Problem is re-produced on Win too.
 (1) Environment
     Program library for Seamonkey 1.1.4 :
       Newly unzip'ed from Seamonkey 1.1.4 ZIP build(no files of comment #16) 
       Admin user=full control, non-Admin user=read-only
     Profile of Seamonkey : Admin="default" only, non-Admin=two profiles
 (2) seamonkey.exe at Admin     => files in comment #16 are created
 (3) seamonkey.exe at non-Admin => Following error after Seamonkey Logo
> XML Parsing Error: undefined entity
> Location: chrome://communicator/content/profile/profileSelection.xul
> Line Number 53, Column 1:
> <dialog
 (4) Change permission for non-Admin
 (4-A) \...\chrome directory  : non-Admin is modifiable/writable and readable
       (don't propagate this change to already existing files)
 (4-B) \...\chrome\chrome.rdf : non-admin is writable/modifiable/readable
 (5) seamonkey.exe at non-admin => Profile manager starts up normally
     (If (4-A) is not executed, problem remains. So I guess access to this )
     (chrome.rdf is not read/write only, rename/create/write/delete instead)

Looks to be OS independent problem.
It seems that "no problem when MS Win" is simply because directory of "Program Files" is usually not read-only when MS Win.

To Robert Kaiser:
Will trace such as Process Monitor log(file access sequence/status can be tracked) on MS Win be helpful/required for deeper problem analysis?
Bug 393455 and Bug 394455 sounds to be report of this problem on MS Win.
What if you delete chrome.rdf, does it run then? This is just for double-checking.
Neil:
Does comment #18 here help us to solve the issues surrounding writing of RDFs on branch?
(In reply to comment #20)
> What if you delete chrome.rdf, does it run then?
Yes it runs.
Seamonkey starts up normally when the chrome.rdf is deleted from read-only program directory (delete \...\chrome\chrome.rdf after step (3) of comment #18)
Thanks, I think that helps a lot.
So, from what I see if we detect a chrome.rdf not being present, we just do everything in-memory and are happy.
If chrome.rdf is present though, we try to write a new version of it, apparently by trying to write a new file and deleting the old one or such, that fails and makes chrome registry as a whole fail, resulting in those XML errors.
Sorry, I couldn't reproduce this.

I tested using a user with only Read (Deny Write) permissions to dist/bin.

I tested without a chrome.rdf, with an out-of-date chrome.rdf and with a current chrome.rdf, and I did get 4 assertions about being unable to write xpti.dat, but I was always able to open the profile manager.
Same problem occuring on Windows XP platform, SeaMonkey 1.1.4, using a restricted account with two profiles. I did notice the same behaviour regarding chrome.rds through Filemon.

1375	10:06:40	seamonkey.exe:2924	QUERY INFORMATION	C:\Program Files\SeaMonkey\chrome\en-win.jar	SUCCESS	Attributes: A	
1376	10:06:40	seamonkey.exe:2924	QUERY INFORMATION	C:\Program Files\SeaMonkey\chrome\chrome.rdf	SUCCESS	Attributes: A	
1377	10:06:40	seamonkey.exe:2924	QUERY INFORMATION	C:\Program Files\SeaMonkey\chrome\chrome.rdf	SUCCESS	Attributes: A	
1378	10:06:40	seamonkey.exe:2924	QUERY INFORMATION	C:\Program Files\SeaMonkey\chrome\chrome.rdf	SUCCESS	Attributes: A	
1379	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files	NAME COLLISION	Options: Create Directory  Access: 00100001	
1380	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files\SeaMonkey	NAME COLLISION	Options: Create Directory  Access: 00100001	
1381	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files\SeaMonkey\chrome	NAME COLLISION	Options: Create Directory  Access: 00100001	
1382	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files\SeaMonkey\chrome\chrome.rdf	NAME COLLISION	Options: Create  Access: Read	
1383	10:06:40	seamonkey.exe:2924	QUERY INFORMATION	C:\Program Files\SeaMonkey\chrome\chrome-1.rdf	NOT FOUND	Attributes: Error	
1384	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files	NAME COLLISION	Options: Create Directory  Access: 00100001	
1385	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files\SeaMonkey	NAME COLLISION	Options: Create Directory  Access: 00100001	
1386	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files\SeaMonkey\chrome	NAME COLLISION	Options: Create Directory  Access: 00100001	
1387	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files\SeaMonkey\chrome\chrome-1.rdf	ACCESS DENIED	WASHU\EDS-User	
1388	10:06:40	seamonkey.exe:2924	QUERY INFORMATION	C:\Program Files\SeaMonkey\chrome\chrome-2.rdf	NOT FOUND	Attributes: Error	
1389	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files	NAME COLLISION	Options: Create Directory  Access: 00100001	
1390	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files\SeaMonkey	NAME COLLISION	Options: Create Directory  Access: 00100001	
1391	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files\SeaMonkey\chrome	NAME COLLISION	Options: Create Directory  Access: 00100001	
1392	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files\SeaMonkey\chrome\chrome-2.rdf	ACCESS DENIED	WASHU\EDS-User	
1393	10:06:40	seamonkey.exe:2924	QUERY INFORMATION	C:\Program Files\SeaMonkey\chrome\chrome-3.rdf	NOT FOUND	Attributes: Error	
1394	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files	NAME COLLISION	Options: Create Directory  Access: 00100001	
1395	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files\SeaMonkey	NAME COLLISION	Options: Create Directory  Access: 00100001	
1396	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files\SeaMonkey\chrome	NAME COLLISION	Options: Create Directory  Access: 00100001	
1397	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files\SeaMonkey\chrome\chrome-3.rdf	ACCESS DENIED	WASHU\EDS-User	
1398	10:06:40	seamonkey.exe:2924	QUERY INFORMATION	C:\Program Files\SeaMonkey\chrome\chrome-4.rdf	NOT FOUND	Attributes: Error	
1399	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files	NAME COLLISION	Options: Create Directory  Access: 00100001	
1400	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files\SeaMonkey	NAME COLLISION	Options: Create Directory  Access: 00100001	
1401	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files\SeaMonkey\chrome	NAME COLLISION	Options: Create Directory  Access: 00100001	
1402	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files\SeaMonkey\chrome\chrome-4.rdf	ACCESS DENIED	WASHU\EDS-User	
1403	10:06:40	seamonkey.exe:2924	QUERY INFORMATION	C:\Program Files\SeaMonkey\chrome\chrome-5.rdf	NOT FOUND	Attributes: Error	
1404	10:06:40	seamonkey.exe:2924	CREATE	C:\Program Files	NAME COLLISION	Options: Create Directory  Access: 00100001	


So as you can see it first tries to create chrome.rds over the existing one, fails since the install dir is read-only for restricted users, then tries to create chrome-1.rds, fails, and so on. It does bail out around chrome-1700.rds.

I've got a second restricted account and the local admin account for which SeaMonkey is running fine, but they only use the default profile (and I can't see them trying to overwrite chrome.rds at start up either)
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Case-1) Write-permitted Program Directory, chrome.rdf exists
         (chrome.rdf was generated by other user with different theme)
 Attached process monitor log is for next flow.
 1. Read chrome\chrome.rdf
 2. Create chrome\chrome-1.rdf
    (try to replace new one, because not-usable or mismatch or error in it)
 3. Erase chrome\chrome.rdf, then rename chrome-1.rdf to chrome.rdf
 4. Profile manager starts normally

(Case-2) Read-only Program Directory, chrome.rdf exists
         (chrome.rdf was generated by other user with different theme)
 Same as Comment #25, except chrome-1.rdf to chrome-9999.rdf.
 1. Read chrome\chrome.rdf
 2. Try to create chrome\chrome-X.rdf => ACCESS DENIED (X=1 to 9999)
    (try to replace new one, because not-usable or mismatch or error in it)
 3. XML Parse error

(Case-3) Write-permitted Program Directory, chrome.rdf exists
         (chrome.rdf was generated by myself, then no need to replace)
 1. Read chrome\chrome.rdf only, no trying of chrome.rdf update
 2. Profile manager starts normally
Changing summary and several fields so that this can be used correctly as a followup to bug 376173 for addressing the remaining issues.
Severity: critical → major
OS: Mac OS X → All
Hardware: Macintosh → All
Summary: SeaMonkey Will Not Start With Multiple Profiles → XML errors when application chrome.rdf exists but is read-only
Version: unspecified → SeaMonkey 1.1 Branch
Depends on: 375102
Keywords: regression
See:

http://forums.mozillazine.org/viewtopic.php?t=588442

I've seem this bug in a different context.  On XP the presence of a preexisting
profile in the Administrator account causes new normal accounts to be unable to start Seamonkey.  Normal users with preexisting profiles were still able to use SeaMonkey.   Eliminating the Administrator's profile and then creating a new one, allowed a new regular user to start SeaMonkey.  Is this because the protections were changed somehow on the 
C:\Program files\Mozilla.org\SeaMonekey....\chrome.rdf, or because of changes to the Administrator's profile?  Seems like it might be the latter, since simply deleting the problematic Administrator's profile (in C:\Documents and Settings\)
let the normal user start Seamonkey.  Deleting that profile should in no way affect file protections in C:\Program Files\Mozzilla.org\SeaMonkey.  

So why should a normal user's SeaMonkey ever look in the Administrator's profile?  Default User's maybe, but not Administrator's.
Is this problem fixed in SeaMonkey 1.1.5?  If not, any idea when if will be fixed?

(In reply to comment #29)
> Is this problem fixed in SeaMonkey 1.1.5?  If not, any idea when if will be
> fixed?
> 
Don't think so.  I pulled 1.1.5 when KaiRo announced the candidate and it ran fine, simply replacing 1.1.4.  But I attempted to test it from a brand new standard account and it fails to launch, displaying

<key id="key_savePage"   key="&savePageCmd.commandkey;" command="Browser:SavePage" modifiers="[edge of screen]

Also, the OS X menu bar was not populated with File, Edit, etc.  (See attached image.)  

If it would help, I'd be willing to run a series of installs to try to detail what combinations of one user installing and another running work and don't work.  Check perms and ownership, etc.

But is further investigation necessary?   Isn't the problem understood - that in a multi-user environment, users can't write to chrome.rdf or any other file in the app directories?  I honestly don't know enough about the innards of SM to understand what is trying to happen around chrome.rdf, but is there no way to hack branch to get through to SM2 where the problem is properly fixed?   Can the file be "renamed" such that it is located in the user's profile somewhere, hence can always be created?  Some other hack? 

I'll be happy to do more digging on OS X if that's what's needed.

OK, so bug 376173 covers the case where Flush() returns NS_ERROR_ACCESS_DENIED but unfortunately when we try to overwrite an existing but stale chrome.rdf in a read-only directory the error code turns out to be NS_ERROR_FILE_TOO_BIG instead. This is because nsLocalFile::Create sucks, and never returns useful error codes to nsLocalFile::CreateUnique.

Note that this patch doesn't affect bug 394713.
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #287307 - Flags: review?(ajschult)
Attachment #287307 - Flags: review?(ajschult) → review+
Comment on attachment 287307 [details] [diff] [review]
Proposed patch
[(1.8 branch) Checkin: Comment 35]

A bit close for 1.1.6 I guess...
Attachment #287307 - Flags: approval-seamonkey1.1.7?
Attachment #287307 - Flags: approval-seamonkey1.1.6?
Comment on attachment 287307 [details] [diff] [review]
Proposed patch
[(1.8 branch) Checkin: Comment 35]

1.1.6 is only missing the announcement, everything else is done, I don't think we really want to go back to the start and respin from here.

We very much want this in normal 1.8 branch for 1.1.7, though. Thanks for working on that!
Attachment #287307 - Flags: approval-seamonkey1.1.7?
Attachment #287307 - Flags: approval-seamonkey1.1.7+
Attachment #287307 - Flags: approval-seamonkey1.1.6?
Attachment #287307 - Flags: approval-seamonkey1.1.6-
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
(Adding keywords)
Keywords: fixed-seamonkey1.1.7
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.10) Gecko/20071119 SeaMonkey/1.1.7
Mozilla/5.0 (Macintosh; U; Intel Mac OS X Mach-O; en-US; rv:1.8.1.10) Gecko/20071119 SeaMonkey/1.1.7

Same result on both platforms (10.4.11):
- I installed the 1.1.7 RC as an administrator user, but did not run it.
- Successfully started the new version from a standard (non-administrator) account where 1.1.6 had been used.
- Successfully started the new verson in a newly created standard account.

These were previously OS X failure cases (see comment #31.)  So I think as far as practical usage, this fix is verified, but....

To humor KaiRo, I tried execution out of a dmg from virgin standard user accounts and it FAILED on both platforms, with the XML error noted in comment #31.   I am completely baffled by this.   It makes me wonder if the above fix is really good, or if there is yet something not understood which can bite under certain circumstances.  Read-only should be read-only...

KaiRo: I said I'd take a shot at relnote text, but I want to mull this over a little first.   (Note BTW that my e-mail is screwed up, haven't seen bugmail this month.   I'll try to check back on this bug.)

I did some digging and could be wrong, but it seems that Flush() performed against write protected media will eventually produce an EROFS errno on the open which gets translated to PR_READ_ONLY_FILESYSTEM_ERROR in the pthread io routines and then translated to NS_ERROR_FILE_READ_ONLY for eventual return by Flush().  Perhaps this is why execution from dmgs doesn't work, it is a different error.

Suggested relnote text:

The problem on [some | Unix-like] systems, which erroneously required users to have write access to the installation directory has been fixed.  This caused SeaMonkey to start incorrectly, showing XML errors.  The problem with executing from write-protected filesystems, such as Mac .dmg images, remains.  (Bug 389136).

VERIFIED with same test scenario as comment #18 (1)/(2)/(3), using Sm 1.8 branch latest nightly on MS Win XP.
 - seamonkey-1.1.7pre (2007/11/19 build)
 - seamonkey-1.1.8pre (2007/11/24 build)
When chrome.rdf existed(generated by write permitted user), seamonkey.exe on read-only user tried to write chrome-1.rdf only once(ACCESS DENIED was returned for it), and further access to chrome-N.rdf(N>=2) was not observed(checked by Process Monitor).

> The problem on [some | Unix-like] systems, which erroneously required users to

Hmm... AFAICT, the bug that got fixed here affected Windows and Mac (not linux).  Mac is Unix-like, but Windows isn't (and Linux is :)).  So, I'd suggest either "some" or "Mac and Windows".
Can someone with a Mac try this patch out please?
Attachment #290090 - Flags: review?(rbg_bz2)
Attachment #290090 - Flags: review?(mnyromyr)
Bug 394713 covers #18, #25 etc.
As the original poster of this bug, I will be happy to test a fix.  Can someone provide me with a fully built binary of SeaMonkey?  I don't have a SeaMonkey build environment.

Thanks.

Reworded the 1.1.7 relnotes to leave the .dmg problem intact, using parts of the proposal in comment #38
Keywords: relnote
(In reply to comment #41)
> Created an attachment (id=290090) [details]
> Mac patch
> 
> Can someone with a Mac try this patch out please?
> 

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.11pre) Gecko/20071127 SeaMonkey/1.1.8pre

Executed straight out of .dmg in account that had previously run an earlier 1.1.x.     WFM  :)

It did seem to take a long time to start, perhaps doing that 1000 tries thing, but subsequent startup was fine.

(In reply to comment #45)
> Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.11pre)
> Gecko/20071127 SeaMonkey/1.1.8pre

To clear up the comment of Rich, I added Neil's patch to the 1.8 branch tinderboxen to get build he can test - those are not nightlies, just tinderbox-builds, so inofficial builds from the official tinderbox or such ;-)
Comment on attachment 290090 [details] [diff] [review]
Mac patch
[(1.8 branch) Checkin: Comment 50 & 51]

Thoroughly tested once...
Attachment #290090 - Flags: review?(rbg_bz2)
Attachment #290090 - Flags: review?(mnyromyr)
Attachment #290090 - Flags: review+
I can confirm the build with the attachment 290090 [details] [diff] [review] patch working directly from the DMG directly on phlox. This has a-1.1.7 from me is it gets granted approval for the relbranch.
Comment on attachment 290090 [details] [diff] [review]
Mac patch
[(1.8 branch) Checkin: Comment 50 & 51]

a1.1.8=me for normal 1.8 branch
Attachment #290090 - Flags: approval-seamonkey1.1.8+
Fix checked in to the branch for SeaMonkey 1.1.8, leaving it up to KaiRo to work out if and how to include the fix in SeaMonkey 1.1.7.
Keywords: fixed-seamonkey1.1.8
I also checked in attachment 290090 [details] [diff] [review] to the release branch for Gecko 1.8.1.11 and included it in the 1.1.7 release tag, so I got to reword the relnotes again but we should fully have fixed this bug there now.

Current 1.1.8pre nightlies should also be fixed already.
Ran a successful smoketest from dmg using the 1.1.7 20071128 RC in an OS X 10.5.1 Leopard guest account.  (Handy way to get a virgin test environment.)

I am the original poster of this bug.  I just upgraded to SeaMonkey 1.1.7 and it has the exact same problem as I originally reported against SeaMonkey 1.1.3.  So this problem has not been fixed for me.

The error reported is:

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

<dialog
^
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I've experienced the failure as in comment 30 a couple times since the 1.1.7 RCs were announced.  It seems to involve installation and running by one user and then running by another, but despite several days of trying on and off to nail down an absolutely repeatable case, I can't do so.   I also had a case of SM silently hanging on startup this afternoon. Ktrace showed it doing this loop:

   623 seamonkey-bin CALL  select(0x7,0xf0080840,0xf00808c0,0xf0080940,0)
   623 seamonkey-bin CALL  write(0x7,0x20031e08,0x1)
   623 seamonkey-bin GIO   fd 7 wrote 1 byte
       "8"
   623 seamonkey-bin RET   write 1
   623 seamonkey-bin RET   select 1
   623 seamonkey-bin CALL  read(0x6,0xf00808d0,0x400)
   623 seamonkey-bin GIO   fd 6 read 1 byte
       "8"
   623 seamonkey-bin RET   read 1
   back to select...

It would sit in the select for about 15 seconds, then blast around the loop and back to the select.  

I'm beginning to wonder if Dick's case, my #30 case, the DMG case and the loop are all different bad things that can happen to SM at startup.  I have only a single profile currently.  The loop may be something entirely different.

Just to be clear, this problem is still totally reproducible for me, just as I first reported it.

The installed SeaMonkey package is corrupted when SeaMonkey is launched by the administrator account that installed it.

Changed severity.
Severity: major → critical
Is this bug still being worked on?
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → INCOMPLETE
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Is this bug, or a duplicate of it, fixed in SeaMonkey 1.1.8?

Parts of this have been fixed for 1.1.6 and 1.1.7, not sure if we had any more work going into 1.1.8 specifically, as we are out of ideas what code is causing any remaining problems or what those remaining problems are specifically.
Robert,

Thanks for the update.

This problem still exists for me.  And the problem did not exist in 1.1.5. 

I use two profiles on a machine with 5 accounts, so this is a real problem for me.  Are you still trying to fix the problem or is SeaMonkey dead wrt multiple profiles and accounts on the same machine?

Dick, if you can give us debug information like we got for the last problems, and give us info about what exactly is the failing scenario on what platform and what permission settings, etc. we might be able to find a fix and get it into a future 1.1.x release. Most important and helpful probably is the debug information.
SeaMonkey 2 should work without problem when it's released, for 1.1.x we will only care about finding such fixes if we get very specific and detailed information on what the exact problem is.
Robert,

I can provide any debug information you need.  I summarized the problem in comment 13, but I don't have any details about which global resource is being corrupted.  Let me know how I can help diagnose this problem.

Thanks.

(In reply to comment #62)
>I can provide any debug information you need.
Well, there's debug information, and there's debug information... ideally, you would compile SeaMonkey 1.1.8 yourself with symbolic debugging information, so that you could trace to see which function was failing.

Wile you might be able to use FileMon or Process Monitor to trace which files SeaMonkey is trying to create or write when it starts up, that won't necessarily translate into usable internal error codes - for example, bug 394713 was caused by an internal XPCOM function returning the wrong error code.
Short of doing SeaMonkey development, is there something I can do as a user to help isolate this problem and get if fixed?

Thanks.

Well, let's start with some basics.
Make two fresh installs of SeaMonkey. Test them both using the user account to verify that they both work. Come back tomorrow and run one using the administrative account. Then do a search by date to find the files that were created or changed by running SeaMonkey. I'd like to know the list of new or newer files (compare with the other install to see which files are new).

I'd also quite like to know the permissions on all the files although the procedure for this differs somewhat on Windows XP Home versus Professional.
(In reply to comment #0)
> (snip) (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.4)

"Permission Denied" is not handled well, if big endian?
Or affected by Bug 385221(landed on trunk at 2007/7/17)? (see Bug 409849)

I installed a fresh copy of SeaMonkey 1.1.8 under the "admin1" account.  After launching SeaMonkey under that account, these files were modified:

Riegner-iMac2:seamonkey 1.1.8 admin1$ ls -l
total 0
drwxr-xr-x@ 3 admin1  admin  102 Feb  2 07:37 SeaMonkey.app
-rw-r--r--  1 admin1  admin    0 Feb 13 21:34 now
Riegner-iMac2:seamonkey 1.1.8 admin1$ ls -ld  $(find . -newer now)
drwxr-xr-x@  29 admin1  admin     986 Feb 13 21:36 ./SeaMonkey.app/Contents/MacOS/chrome
-rw-r--r--    1 admin1  admin   48646 Feb 13 21:36 ./SeaMonkey.app/Contents/MacOS/chrome/chrome.rdf
-rw-r--r--    1 admin1  admin    6920 Feb 13 21:36 ./SeaMonkey.app/Contents/MacOS/chrome/overlays.rdf
-rw-r--r--    1 admin1  admin     490 Feb 13 21:36 ./SeaMonkey.app/Contents/MacOS/chrome/stylesheets.rdf
drwxr-xr-x@ 247 admin1  admin    8398 Feb 13 21:35 ./SeaMonkey.app/Contents/MacOS/components
-rw-r--r--    1 admin1  admin  160040 Feb 13 21:35 ./SeaMonkey.app/Contents/MacOS/components/compreg.dat
-rw-r--r--    1 admin1  admin  120771 Feb 13 21:35 ./SeaMonkey.app/Contents/MacOS/components/xpti.dat


The new chrome.rdf is newer than the existing installed-chrome.txt I hope!
If (as admin) you rename installed-chrome.txt can you then start as a user?
I renamed "installed-chrome.txt" to "dickie_installed-chrome.txt" and started SeaMonkey under the "admin1" account.  It did not completely start-up:  it only displayed its application name "SeaMonkey" in the menu bar;  there was nothing else in the menu bar.

I then renamed the file back and SeaMonkey started-up normally.  And here are the files in the "chrome" directory after the successful start-up using "installed-chrome.txt" under the "admin1" account:

Riegner-iMac2:chrome admin1$ pwd
/applications/SeaMonkey 1.1.8/SeamOnkey.app/Contents/MacOS/chrome
Riegner-iMac2:chrome admin1$ ls -lt
total 27792
-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
-rw-r--r--@ 1 admin1  admin     2670 Feb  2 07:55 inspector.manifest
-rw-r--r--@ 1 admin1  admin       63 Feb  2 07:55 reporter.manifest
-rw-r--r--@ 1 admin1  admin  1009809 Feb  2 07:37 toolkit.jar
-rw-r--r--@ 1 admin1  admin   845658 Feb  2 07:37 venkman.jar
-rw-r--r--@ 1 admin1  admin  2289207 Feb  2 07:37 messenger.jar
-rw-r--r--@ 1 admin1  admin   890380 Feb  2 07:37 modern.jar
-rw-r--r--@ 1 admin1  admin      721 Feb  2 07:37 pipnss.jar
-rw-r--r--@ 1 admin1  admin   303138 Feb  2 07:37 pippki.jar
-rw-r--r--@ 1 admin1  admin    53874 Feb  2 07:37 reporter.jar
-rw-r--r--@ 1 admin1  admin   222465 Feb  2 07:37 sroaming.jar
-rw-r--r--@ 1 admin1  admin  3353369 Feb  2 07:37 comm.jar
-rw-r--r--@ 1 admin1  admin    14463 Feb  2 07:37 content-packs.jar
-rw-r--r--@ 1 admin1  admin    26293 Feb  2 07:37 embed-sample.jar
-rw-r--r--@ 1 admin1  admin  2103312 Feb  2 07:37 en-US.jar
-rw-r--r--@ 1 admin1  admin     8629 Feb  2 07:37 en-mac.jar
-rw-r--r--@ 1 admin1  admin     8870 Feb  2 07:37 en-unix.jar
-rw-r--r--@ 1 admin1  admin     8935 Feb  2 07:37 en-win.jar
-rw-r--r--@ 1 admin1  admin    49517 Feb  2 07:37 help.jar
-rw-r--r--@ 1 admin1  admin   770081 Feb  2 07:37 inspector.jar
-rw-r--r--@ 1 admin1  admin     7698 Feb  2 07:37 installed-chrome.txt
-rw-r--r--@ 1 admin1  admin  1148612 Feb  2 07:37 chatzilla.jar
-rw-r--r--@ 1 admin1  admin   263593 Feb  2 07:37 chromelist.txt
-rw-r--r--@ 1 admin1  admin   635082 Feb  2 07:37 classic.jar
-rw-r--r--@ 1 admin1  admin    86180 Feb  2 07:37 US.jar



Do you need any more debugging information from me?  Is there anything else I can do to help resolve this problem?

Does anyone know if Firefox 2.0.0.14 and Thunderbird 2.0.0.14 have this same problem?  Is converting from SeaMonkey to Firefox and Thunderbird a way to permanently fix this problem?

Thanks.

(In reply to comment #69)
> -rw-r--r--@ 1 admin1  admin     7698 Feb  2 07:37 installed-chrome.txt

To Dick Riegner(bug opener):
Do you use lang-pack? If yes, see Bug 412549.
No, I don't use lang-pack.  This problem occurs with SeaMonkey 1.1.3 and later and does not occur with SeaMonkey 1.1.2 and earlier.  It clearly looks like a regression to me.
Attachment #287307 - Attachment description: Proposed patch → Proposed patch [(1.8 branch) Checkin: Comment 35]
Attachment #290090 - Attachment description: Mac patch → Mac patch [(1.8 branch) Checkin: Comment 50 & 51]
(Without having read the whole bug)
I would suggest to resolved this bug,
and open a new/separate bug for the remaining issue...
In a mozilla.support.seamonkey thread "No 2nd machine Users for SM? Mac" started on Fri, 06 Feb 2009 19:23:00 -1000, Geoff Welsh posted:

>User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.19) Gecko/20081204 not Firefox/2.0.0.15 SeaMonkey/1.1.14

>on both my Macs (G4, and G5 PPC OSX 10.4)...

>When you create a second (machine) User account, the new user can launch 
>any App loaded on the machine and it starts up in a virgin state, and 
>they can customize it as they please.  This works for FF, Camino, 
>iTunes, Safari...

>But SM doesn't work!
>It brings up a funny old style looking window with a bottom pane saying 
>"parsing error...." and there are no functions across the menu bar. 
>It's totally blank.

When pointed at this bug, he wrote:

>> That sounds exactly like the problem!  I am always running from my admin account which obviously ruins the second user SM.  I'll dig into that permissions modification later and report my result.


>It seems I have fixed the problem, although not by modifying read/write privileges.

>Trashing the chrome.rdf in the chrome folder of the Application "package contents" (NOT the chrome.rdf in the chrome folder of the User's profile folder) causes SM to function normally in the second (machine's) User acct..  Launching SM in the main user acct, creates a new chrome.rdf but the SM in the second user acct still works.
From what I see, as much as we can fix has been fixed here, and on trunk this is obsolete anyways, so let's mark it FIXED for good.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 15 years ago
Resolution: --- → FIXED
I still get it from time to time on updates.   Haven't quite figured it out.  Shouldn't 1.x branch bugs get marked WONTFIX if they are fixed in 2.0?
Rich, there are cases in here which we actually fixed, even though some edge cases might be left. Therefore, FIXED is correct here.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: