'Local Settings/x.y' directory not created/used immediately after account creation when using '-profilemanager', for XPC.mfl/XUL.mfl/Cache/...

NEW
Unassigned

Status

()

defect
P4
normal
12 years ago
2 years ago

People

(Reporter: sgautherie, Unassigned)

Tracking

(Blocks 1 bug, {regression})

Trunk
Future
x86
Windows 2000
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 -
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

12 years ago
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070310 SeaMonkey/1.5a] (nightly) (W2Ksp4)

(No bug.)


[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007031004 Minefield/3.0a3pre] (nightly) (W2Ksp4)
[Mozilla Thunderbird, version 3 alpha 1 (20070310)] (nightly) (W2Ksp4)

1. Start FF/TB with '-profilemanager'.
2. Create a new account.
3. Start with it. (Don't Exit now !)
3r. XPC.mfl, XUL.mfl (and the Cache directory) are created in the user profile dir.. (wrong)

4. Stop FF/TB.
5. Restart with the same profile.
5r. The 2 files (and the Cache directory) are moved/recreated in the Local Settings dir.. (right)

If you exit between steps 2 and 3, then you immeditely get the correct 5b instead of the wrong 3b.
Flags: blocking1.9?

Comment 1

12 years ago
If this is the only manifestation of this bug, then it's not a blocker. If it shows up in default situations, then it should be.
Flags: blocking1.9? → blocking1.9-
Reporter

Comment 2

12 years ago
(In reply to comment #1)
> If it shows up in default situations, then it should be.

What would be these "default situations" ?
So I could test them.

Comment 3

12 years ago
The first time somebody uses the app when there are no profiles, and during profile migration.
Reporter

Comment 4

12 years ago
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/2007090602 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Confirming bug, with new "toolkit based SeaMonkey".
<_:\Documents and Settings\___\Local Settings\Application Data\mozilla.org\SeaMonkey\Profiles\___> is only created, and populated, on profile second use.
Summary: 'Local Settings' directory not created/used immediately after account creation, for XPC.mfl/XUL.mfl/Cache → 'Local Settings/x.y' directory not created/used immediately after account creation, for XPC.mfl/XUL.mfl/Cache
Reporter

Comment 5

12 years ago
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/2007090504 Minefield/3.0a8pre] (nightly) (W2Ksp4)

This affects new <urlclassifier3.sqlite> file too.
Furthermore, this file is not moved, only (re)created:
this leaves the old/first file in the profile directory :-(

*****

(In reply to comment #3)
> The first time somebody uses the app when there are no profiles, and during
> profile migration.

Confirming that this bug happens "The first time somebody uses the app when there are no profiles" too:
Only <_:\Documents and Settings\___\Local Settings\Application Data\Mozilla\Firefox\> is created on first launch,
<...\Profiles\> is only created, and populated, on
"application/profile" second use.

NB: I didn't try "migration" but don't know why it would be different either.

(In reply to comment #1)
> If this is the only manifestation of this bug, then it's not a blocker. If it
> shows up in default situations, then it should be.

Then, resetting/asking for 'blocking1.9=?'.
Flags: blocking1.9- → blocking1.9?
Reporter

Updated

12 years ago
Keywords: regression
Reporter

Comment 6

12 years ago
(In reply to comment #5)
> Confirming that this bug happens "The first time somebody uses the app when
> there are no profiles" too:

Sorry, I was still using '-profilemanager'.
Without it, and selecting "Don't import anything", this bug does not occur.

> Then, resetting/asking for 'blocking1.9=?'.

I leave this yet, for you to consider the new <urlclassifier3.sqlite> part...
Summary: 'Local Settings/x.y' directory not created/used immediately after account creation, for XPC.mfl/XUL.mfl/Cache → 'Local Settings/x.y' directory not created/used immediately after account creation when using '-profilemanager', for XPC.mfl/XUL.mfl/Cache/...

Comment 7

12 years ago
Could I get somebody from QA to test this? STR:

1) Windows XP or above: start with a clean machine on which Firefox has never been installed and there are no profiles
2) install and launch Firefox: do not import any profile data
3) Look for these files:

* Cache
* XUL.mfl
* urlclassifier3.sqlite

in these locations:

c:\Documents and Settings\User\Application Data\Mozilla\Firefox\Profiles\salt.default
c:\Documents and Settings\User\Local Settings\Application Data\Mozilla\Profiles\salt.default
Keywords: qawanted
Reporter

Comment 8

12 years ago
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007092605 Minefield/3.0a9pre] (nightly) (W2Ksp4)

(Testing W2K, not WXP...)
All 3 files/dir are in "Local Settings".
They end up in the wrong dir only when using '-profilemanager';
in that case, only <urlclassifier3.sqlite> is not removed on restart.

Updated

12 years ago
Flags: blocking1.9? → blocking1.9-

Updated

11 years ago
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup

Comment 9

11 years ago
I'm experiencing this bug and it's very annoying.  The only difference in my case is that Cache, XPC.mfl, nor XUL.mfl remain stuck in my profile directory.  Further every new profile I create is having this exact same problem.

I'm experiencing this with the 3.1 Trunk builds on XP.  I would really appreciate a fix for this.
Flags: blocking1.9.2?
(In reply to comment #9)
Where are you creating the profile on your file system?

Comment 11

11 years ago
(In reply to comment #10)
> Where are you creating the profile on your file system?

Under the Firefox profile root.  I have been using an extension called ProfileSwitcher (v. 0.3.5) to call Profile Manager and create and launch new profiles without terminating my active Firefox session.

It seems like that is triggering this bug and causing all my Firefox profiles to then permanently switch to using my profile directory for all those temp files.

So I guess because ProfileSwitcher allows the new session to be used without terminating the calling Firefox session, the bug gets triggered and not only do the temp files for the created profile (and all subsequent profiles) end up in the new profile folder, the temp files for the profile through which Profile Manager was launched (via the ProfileSwitcher extension), gets switched also.  And once this happens, the temp files remain stuck in the profile folders.
I suspect that profile switcher creates absolute profile paths vs. relative profile paths and absolute profile paths are suppose to have those files in the profile.

Comment 13

11 years ago
I doubt it.  When I run ProfileSwitcher, it calls the actual Firefox Profile Manager.   But even if what you stated could be true, it would not explain why my active profile, which is previously operating normally, subsequently also experiences the switch--even though it was originally created, standalone, using Profile Manager.
With the additional info. it does sound like ProfileSwitcher is triggering this bug.

Comment 15

11 years ago
I realize ProfileSwitcher must be triggering the bug, but the bug is in Profile Manager to trigger, which is why I'm hoping Profile Manager gets fixed.

Updated

10 years ago
Flags: blocking1.9.2? → blocking1.9.2-
Priority: -- → P4
Target Milestone: --- → Future
Reporter

Updated

10 years ago
Flags: wanted1.9.2?
Reporter

Updated

8 years ago
Flags: wanted1.9.2?
Bug 606575 is similar, but has more info, so resolve this as duplicate?

Comment 17

6 years ago
Confirming this with Aurora 23, using the Profile Manager tool.

Comment 18

5 years ago
Mozilla/5.0 (Windows NT 5.1; rv:29.0) Gecko/20100101 Firefox/29.0
After a fresh install, Cache is in Local Settings, but the other two are missing. Same after creating a new profile with the Profile Manager.

Updated

5 years ago
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.