325791 - SeaMonkey: creates XUL.mfl outside of users Profile (creating a new Profile Hierarchy for it to reside in, at startup)

Status: RESOLVED INVALID

(Core :: Networking: Cache, defect)

Description

[Rolf Sponsel]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0

After installing SeaMonkey 1.0 for the first time, I noticed that SeaMonkey had created a new directory at C://Winnt/Mozilla. This this directory is populated with a Profile Hierarchy - which is not the users usual Profile Hierarchy - into which SeaMonkey nests a XUL.mfl file.

This directory structure seems to be (re-)created whenever SeaMonkey is launched, if one removes it (e.g. by renaming Mozilla to Mozilla-DISABLED).

Reproducible: Always

Steps to Reproduce:
1. Install SeaMonkey on Windows NT (using installer).
2. Once Profile Manager has been automatically launched: click Exit.
3. (Check if the new hierarchy has been created - I did not do that)
4. Lauch SeaMonkey (I did it by clicking it's short-cut icon on the Desktop).
5. Once SeaMonkey has been launched; look for where it has created the XUL.mfl file (this file used to reside / be created in the current Profile's directory).

Actual Results:  
SeaMonkey had created a new File Hierarchy under C://Winnt, according to this:

C://Winnt/Mozilla/Profiles/<NameOfCurrentProfile>/XUL.mfl


Expected Results:  
Having the XUL.mfl created in the default Profile directory (unless explicitly having configured it to reside somewhere else, in Mozilla), e.g. as:

C://Winnt/Profiles/Administrator/Application Data/Mozilla/Profiles/<NameOfCurrentProfile>/xxxxxxxx.slt/XUL.mfl


At install time, two Mozilla Profiles where defined for user Administrator.

To me this seems like a SeaMonkey 1.0 REGRESSION BUG, since this behaviour did not exist in Mozilla 1.7.12.

Comment 1

[Frank Wein [:mcsmurf]]

The idea behind this was to exclude XUL.mfl file and Cache from roaming in (Windows) profiles (for speed reasons, people have quotas, etc.). On Win2K/XP one could do that by using the Local Settings folder. On WinNT there is no such folder, so i guess they created a seperate folder for that.

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

well, it was not so intentional actually...

Comment 3

[OstGote!]

(In reply to comment #1)
> The idea behind this was to exclude XUL.mfl file and Cache from roaming in
> (Windows) profiles (for speed reasons, people have quotas, etc.). 

That was done in Bug 291033.

Comment 4

[Serge Gautherie (:sgautherie)]

(In reply to comment #3)
> (In reply to comment #1)
> > The idea behind this was to exclude XUL.mfl file and Cache from roaming in
> > (Windows) profiles (for speed reasons, people have quotas, etc.). 
> 
> That was done in Bug 291033.

I too thought this was intentional.

(In reply to comment #2)
> well, it was not so intentional actually...

Christian,
Do you confirm that this is a (WinNT [and I could add W98 for that matter]) bug ?

Comment 5

[Rolf Sponsel]

Since these files are temporary files I would expect them to reside in the temporary directory i.e. in C:/Temp for WinNT etc.

Comment 6

[therube]

Sounds like duplicate of:
Bug 296890 – XUL.mfl (FastLoad File) is not stored in specified Profile location

Explained here:
Bug 292075 – improve seamonkey's local profile support

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to therube from comment #6)
> Sounds like duplicate of:
> Bug 296890 – XUL.mfl (FastLoad File) is not stored in specified Profile
> location
> 
> Explained here:
> Bug 292075 – improve seamonkey's local profile support

This was fixed almost 7 years ago.

Do you still see the problem?

Comment 8

[therube]

I would think its immaterial at this point, so INVALID?

XUL.mfl is no longer, hasn't been for ages.

Comment 9

[Rolf Sponsel]

I have moved on long ago. Was surprised to see that I had filed it. Feel free to close this bug report.

Comment 10

[Wayne Mery (:wsmwk)]

(In reply to therube from comment #8)
> I would think its immaterial at this point, so INVALID?
> 
> XUL.mfl is no longer, hasn't been for ages.