247427 - "pluginreg.dat" & "registry.dat" should be stored in %APPDATA%/Mozilla/Firefox

Status: VERIFIED FIXED

(Toolkit :: Startup and Profile System, defect, P3)

Description

[MW]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 (ax)
Build Identifier: 

Recently the folder the FireFox stores Plugin & registry info changed from
"Phoenix" to "Mozilla/FireFox". But that implementation is not consistent in
regards to "pluginreg.dat" & "registry.dat" files.
The files "pluginreg.dat" & "registry.dat" should be also be placed in
%APPDATA%/Mozilla/Firefox. Now FireFox places them in %APPDATA%/Mozilla/ That is
a  big problem since the 2 files, registry.dat & pluginreg.dat, are also put in
that SAME location by Mozilla Suite/Netscape 7.1 ... This means u can not use
Mozilla Suite/Netscape 7.1 on the same machine as FF 0.9 as they will overwrite
each others versions "pluginreg.dat" & "registry.dat".

Note I am refering to pluginreg.dat & registry.dat and NOT the actual profiles's
data files (cookies.txt, prefs.js etc) which indeed are stored in
%APPDATA%/Mozilla/Firefox/Profiles .

I am using On Win98 OS. Can anyone confirm on other OS's

Reproducible: Always
Steps to Reproduce:


Actual Results:  
"pluginreg.dat" & "registry.dat" stored in %APPDATA%/Mozilla/

Expected Results:  
"pluginreg.dat" & "registry.dat" should be stored in preferably in 
%APPDATA%/Mozilla/Firefox.

Comment 1

[MW]

obviously disregard my UA on the bug as I posted using FF 0.8

Comment 2

[Jordan Callicoat]

This bug applies to Linux as well -- mozver.dat and pluginreg.dat (in
~/.mozilla) are overwritten by Firefox 0.9.

Comment 3

[MW]

more info in this thread http://forums.mozillazine.org/viewtopic.php?t=85973

Comment 4

[Steffen Wilberg]

OS -> all per comment 2.

Comment 5

[Mark Dowling]

Is there a reason Firefox is not getting an Appdata dir of its own, rather than
association with Moz which it is being gradually separated from?

If Firefox is intended to be standalone as an App and from the Mozilla
predecessor, having data in a dir such as /mozilla/firefox/ is not geared for
clarity. 

Comment 6

[Benjamin Smedberg]

Fixed on trunk and branch

Comment 7

[Zachariah]

(In reply to comment #5)
> Is there a reason Firefox is not getting an Appdata dir of its own, rather than
> association with Moz which it is being gradually separated from?
> 
> If Firefox is intended to be standalone as an App and from the Mozilla
> predecessor, having data in a dir such as /mozilla/firefox/ is not geared for
> clarity. 

Its common practice to put users data in the
%APPDATA%/"OrganizationName"/"ProgramName"/ directory.

Comment 8

[Dave Wascavage]

(In reply to comment #6)
> Fixed on trunk and branch

In what release of Firefox is (will be) the fix included?

Comment 9

[Zachariah]

(In reply to comment #8)
> (In reply to comment #6)
> > Fixed on trunk and branch
> 
> In what release of Firefox is (will be) the fix included?

I'd assume 1.0PR, since that's the next release.

Comment 10

[Daniel Ross]

Creating a new profile on the below-mentioned build once again places
registry.dat in %appdata%/Mozilla (as opposed to %appdata%/mozilla/firefox).
Pluginreg.dat remains in its proper place. Could somebody with appropriate
permissions please reopen this bug?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041001
Firefox/0.10

Comment 11

[Peter van der Woude [:Peter6]]

multiple users confirming wrong location
->REOPEN

Comment 12

[Peter van der Woude [:Peter6]]

for AVIARY builds that is, don't know about trunk

Comment 13

[Jim Ginn]

I can confirm that this is not fixed on the Aviary Branch as well (same problem
as comment 10). Removing the fixed-aviary1.0 keyword.

Comment 14

[Stefan Pietschmann]

fresh install of 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041007
Firefox/0.10.1

pluginreg.dat resides under %APPDATA%/Mozilla/Firefox
cannot find registry.dat anywhere

Comment 15

[Koobs]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041014
Firefox/0.10

- Branch ZIP build
- Deleted old profile/app dir completely prior to install.

Results:

- pluginreg.dat in %APPDATA%/Mozilla/Firefox/
- registry.dat in %APPDATA%/Mozilla/

-----------------------
And my 2c, I think all products should go with the convention:

%APPDATA%/"OrganizationName"/"ProgramName"/

While Firefox/Thunderbird/Everything else reside on mozilla.org servers, I think
that should be the case. And even if theyre not to be quite honest.

Comment 16

[Zachariah]

It appears to me that this actually is fixed -- can someone please sort this out?

Comment 17

[Ravenous Bugblatter Beast]

Using the 1.0 release on windows, if you use the -p command line option to move
the profile, or the PortableFirefox (http://portablefirefox.mozdev.org)
bootstraper to run firefox from a USB device, it still writes pluginreg.dat to
the application data folder of the machines hard disk.

Apart from talkback this seems to be the only corruption to the host machine
when you run firefox from a USB device.

Comment 18

[David Janes]

Shouldn't these files be in the Firefox program directory, as they are for all
users?

Comment 19

[Jonathan Swaringen]

(In reply to comment #18)
> Shouldn't these files be in the Firefox program directory, as they are for all
> users?

well at least with the instance of Plug-ins there is a bug filed for moving the
plug-ins to the profile so it would fit with

why different reg for different profiles... i suppose it keeps some profile
specific things in the registry not sure about that

Comment 20

[Fred Collier]

(In reply to comment #18)
> Shouldn't these files be in the Firefox program directory, as they are for all
> users?
This problem seems to have morphed into something entirely different - the
original problem has been fixed. The files in question are now properly located in
C:\Windows\...\Mozilla\Firefox.

Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8a6) Gecko/20041207 Firefox/1.0+ ZIP
build with a totally clean install. Profile located in:
C:\Program Files\Mozilla Firefox\firefox\Users.

Profile.ini is placed in the location listed above.
Registry.dat can not be located.
Pluginreg.dat can not be located.

This should be marked as FIXED.
The big question is now, "Should profile.ini be located in 
C:\Windows\...\Mozilla\Firefox"?  I think not, but that is a whole new story -
Maybe a new bug?

Comment 21

[Worcester12345]

Maybe this one should be marked "INVALID" since those files no longer exist (is
that right?).

In that case, I'd say do a new, more specific bug on the other issues.

Comment 22

[Christian Stadler]

There in %APPDATA%\Firefox on my box.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b)
Gecko/20050217 Firefox/1.0+

FIXED? WORKSFORME?

Comment 23

[Jean-Marc]

I confirm the entire Fred Collier's comment #18 with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050224
Firefox/1.0+
(new profile, no pre-existing %APPDATA%\Mozilla directory)

Comment 24

[Victor Luchits]

Sorry for bugspamming, but is this old issue ever going to be fixed? The
inconsistency between Firefox which creates profiles in
%APPDATA%\Mozilla\Firefox, Thunderbird (%APPDATA%\Thunderbird) and Mozilla is a
bit odd. Also, confirming with FF 1.0.1

Comment 25

[Caleb]

registry.dat is _still_ not in the %APPDATA%\Mozilla\Firefox folder, it's in
%APPDATA%\Mozilla\.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050421
Firefox/1.0+

Comment 26

[Daniel Veditz [:dveditz]]

Not the type of change we'd take on a bugfix branch.

Comment 27

[Mike Connor [:mconnor]]

Benjamin, is this really regressed or is this just old files floating around?  I
can't reproduce here.  Please add to the b4 blocker list if it has, or resolve
if it hasn't.

Comment 28

[Vignir G.]

This is tested with a fresh install of: Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.8b3) Gecko/20050708 Firefox/1.0+

The pluginreg.dat is created in %APPDATA%/Mozilla/Firefox/, this file will
however not show up until a plugin has been installed and used (install Flash
Player and visit www.cnn.com).
 
The registry.dat is created in %APPDATA%/Mozilla/.
 - if you do a fresh install with no pre-existing profiles and let the installer
launch Firefox, which creates a new profile the registry.dat file is created.
 - if you have an existing profile or create one from the profile manager
without letting the installer start Firefox, then no registry.dat is created.

Comment 29

[hhh]

Can confirm Vignir's comment using Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.8b4) Gecko/20050722 Firefox/1.0+, fresh install via. installer

Comment 30

[runner23]

I can confirm Vignir's comment. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.10) Gecko/20050716. Tested on a new virtual PC as a new install with no
pre-existing profiles. I let the installer launch Fx and registry.dat was placed
in the Mozilla directory instead of in the Fx folder.

Why has this not been fixed? I have a mess on my host machine as I have Fx
1.0PR, Mozilla 1.6 and Netscape 7.2 on that machine. My profiles are constantly
being overwritten. When I installed Netscape the first thing I saw was a list of
my profiles for Fx and Mozilla. I have three profiles all used by all three
browsers. If I have Fx open using one profile and go to open Mozilla or
Netscape, I cannot choose the profile that Fx is using and vice versa. I am
unable to upgrade Mozilla from 1.6. If I do, I cannot run both Fx and Mozilla at
the same time. I like to have at least two browsers open at the same time.
 
On my W98SE box, this bug causes Mozilla and Fx to crash if I try to run them at
the same time. I have found that I can run Mozilla 1.5 and Fx 1.0PR together on
that box but if I upgrade Mozilla to 1.6 or above, I cannot run them together as
both will crash. 

On my host machine (XP Pro SP1a) my profiles on all three browsers are
constantly getting corrupted and I think this bug is the reason. This needs to
be fixed!    

Comment 31

[O. Atsushi (Torisugari)]

I believe this is not a profile's issue, but a migrator's.

nsNetscapeProfileMigratorBase::GetProfileDataFromRegistry
(strictly speking, nsRegistry::Open in that fucntion)
creates registry.dat for some reason. I guess checking whether
the regfile exists or not before calling nsRegistry::Open
would fix this problem.

Comment 32

[O. Atsushi (Torisugari)]

Attachment: Patch

This patch would fix the problem described at comment #28

Comment 33

[Benjamin Smedberg]

Comment on attachment 191048 [details] [diff] [review]
Patch

Good catch!

Since it is reasonably likely that the registry file may not exist, we
shouldn't be using the NS_ENSURE_TRUE macro for the "regFileExists" check (the
NS_ENSURE_* macros display a debug warning on failure); use

if (!regFileExists)
  return NS_ERROR_FAILURE;

instead

Comment 34

[O. Atsushi (Torisugari)]

Attachment: Patch

> we shouldn't be using the NS_ENSURE_TRUE macro
I see.

Comment 35

[:Gavin Sharp [email: [e-mail]]]

Checking in nsNetscapeProfileMigratorBase.cpp;
/cvsroot/mozilla/browser/components/migration/src/nsNetscapeProfileMigratorBase.cpp,v
 <--  nsNetscapeProfileMigratorBase.cpp
new revision: 1.15; previous revision: 1.14
done