190732 - Cannot choose the location / directory of new profile

Status: VERIFIED FIXED

(Core Graveyard :: Profile: BackEnd, defect)

Description

[Eugene Savitsky]

It seems this is not yet reported.

1. Open Profile manager
2. Choose "create profile"
3. Press "Choose folder" - nothing hapends.

You are able to create profiles only in default folder.

moz 2002012508
Win XP (Prof anf Home)

Comment 1

[Hermann Schwab]

I think reporter means Build ID: 2003012508, not 2002....
I´m seeing same error in this Build ID
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030125

Comment 2

[Eugene Savitsky]

Sure I meant build 2003012508.

Comment 3

[Hermann Schwab]

My first broken version: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b)
Gecko/20030122
My last working version: Build ID 2003012108

BTW, the path displayed shifts the top button to the right, so it is clipped.
But that is another bug listed elsewhere.

Comment 4

[Joe Infla]

*** Bug 190837 has been marked as a duplicate of this bug. ***

Comment 5

[u69748]

I hate default profile location on WinXP.
So this is critical for me.

Comment 6

[Eugene Savitsky]

I also have a logical disk for all my internet profiles, mail (The Bat!) etc. If
you already have a profile it works. You cannot just create a new one in other
directory.

I believe this can be in a _beta_ release...

Comment 7

[Gregor Larson]

I agree, this bug makes it difficult to use a Profile kept on a network drive or
an encrypted PGP drive (I do both). Workaround note: Run Mozilla 1.2.1 and
create the profile (I still think this should be fixed for 1.3b, seeing as it is
reciently broken). 

Comment 8

[Conrad Carlen (not reading bugmail)]

tao, has something changed recently with the string bundle code? This code:
http://lxr.mozilla.org/seamonkey/source/profile/resources/content/newProfile1_2.js#89
fails due to:
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)
[nsIStringBundle.GetStringFromName]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"
 location: "JS frame :: XStringBundle.getString() :: getString :: line 2"  data: no]

Stepping into nsStringBundle::GetStringFromName(), the properties hash table for
this string bundle has only 1 entry, whereas it should have 2.

Comment 9

[Matthias Versen [:Matti]]

*** Bug 191407 has been marked as a duplicate of this bug. ***

Comment 10

[Mike Kaply [:mkaply]]

Happens on OS/2 as well.

Copying alecf who I think messed with some code that affected string bundles.

Comment 11

[Mike Kaply [:mkaply]]

At least upping severity. I have no doubt that nsPErsistentProperties changes
caused this.

Comment 12

[Mike Kaply [:mkaply]]

The issue appears to be whether or not there is a carriage return at the end of
the file.

Comment 13

[Conrad Carlen (not reading bugmail)]

Looking at the code, you're so right. It seems that after hitting EOF, the
parser should call FinishValueState() if it has any chars in the value.

Comment 14

[Alec Flett]

that seems like a reasonable assessment - making sure that you're actually in
the value state at that point of course...

Comment 15

[Conrad Carlen (not reading bugmail)]

Attachment: patch

Comment 16

[Conrad Carlen (not reading bugmail)]

Comment on attachment 113245 [details] [diff] [review]
patch

I checked not only the parser state but whether there's anything in the value
string. Fixes it for me on OSX.

Comment 17

[Mike Kaply [:mkaply]]

Comment on attachment 113245 [details] [diff] [review]
patch

Fixes problem for me on OS/2 as well.

Comment 18

[Alec Flett]

Comment on attachment 113245 [details] [diff] [review]
patch

Please don't check the IsEmpty() state of the string... that will prevent empty
values at the end of a file from being added to the properties file.

sr=alecf with just the GetState() check.

Comment 19

[Mike Kaply [:mkaply]]

Comment on attachment 113245 [details] [diff] [review]
patch

really marking r=mkaply

Asking for approval

Comment 20

[Conrad Carlen (not reading bugmail)]

> Please don't check the IsEmpty() state of the string

You're right - removed it.

Comment 21

[Asa Dotzler [:asa]]

Comment on attachment 113245 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to 1.3beta.

Comment 22

[Mike Kaply [:mkaply]]

I went ahead and checked this in so it would make this mornings build.

Thanks for the help.

Comment 23

[Alec Flett]

thanks, mike!

Comment 24

[Grace Bush]

this is fixed in mozilla build 2003020308 on Windows at least - but it is not
fixed in commercial builds on any platform

Comment 25

[Conrad Carlen (not reading bugmail)]

> but it is not fixed in commercial builds on any platform

Mike checked this in this morning at 07:00. Depending on what time the
commercial builds were made, the fix may not have been in.

Comment 26

[Gregor Larson]

Dialog now opens correctly now on Win2K using nightly build:
"Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030203"

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(Is this fixed?  If so, should it be marked fixed?)

Comment 28

[Conrad Carlen (not reading bugmail)]

Marking fixed again. Grace, now that we know this fix is in, can you verify?

Comment 29

[Grace Bush]

verified on trunk builds- all platforms

Comment 30

[Grace Bush]

*** Bug 189584 has been marked as a duplicate of this bug. ***