Closed Bug 190732 Opened 19 years ago Closed 19 years ago

Cannot choose the location / directory of new profile

Categories

(Core Graveyard :: Profile: BackEnd, defect)

defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.3beta

People

(Reporter: ezh, Assigned: ccarlen)

References

Details

(Keywords: regression)

Attachments

(1 file)

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)
Summary: Cannot choose the locasion of new profile → Cannot choose the location of new profile
Keywords: regression
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
Sure I meant build 2003012508.
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.
*** Bug 190837 has been marked as a duplicate of this bug. ***
I hate default profile location on WinXP.
So this is critical for me.
Flags: blocking1.3b?
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...
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). 
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.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.3beta
*** Bug 191407 has been marked as a duplicate of this bug. ***
Summary: Cannot choose the location of new profile → Cannot choose the location / directory of new profile
QA Contact: ktrina → gbush
Happens on OS/2 as well.

Copying alecf who I think messed with some code that affected string bundles.
OS: Windows XP → All
Hardware: PC → All
At least upping severity. I have no doubt that nsPErsistentProperties changes
caused this.
Severity: normal → major
The issue appears to be whether or not there is a carriage return at the end of
the file.
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.
that seems like a reasonable assessment - making sure that you're actually in
the value state at that point of course...
Attached patch patchSplinter Review
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.
Attachment #113245 - Flags: superreview?(alecf)
Attachment #113245 - Flags: review?(mkaply)
Comment on attachment 113245 [details] [diff] [review]
patch

Fixes problem for me on OS/2 as well.
Attachment #113245 - Flags: review?(mkaply) → review+
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.
Attachment #113245 - Flags: superreview?(alecf)
Attachment #113245 - Flags: superreview+
Attachment #113245 - Flags: review?(mkaply)
Attachment #113245 - Flags: review+
Comment on attachment 113245 [details] [diff] [review]
patch

really marking r=mkaply

Asking for approval
Attachment #113245 - Flags: review?(mkaply)
Attachment #113245 - Flags: review+
Attachment #113245 - Flags: approval1.3b?
> Please don't check the IsEmpty() state of the string

You're right - removed it.
Comment on attachment 113245 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to 1.3beta.
Attachment #113245 - Flags: approval1.3b? → approval1.3b+
I went ahead and checked this in so it would make this mornings build.

Thanks for the help.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
thanks, mike!
this is fixed in mozilla build 2003020308 on Windows at least - but it is not
fixed in commercial builds on any platform
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
> 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.
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"
(Is this fixed?  If so, should it be marked fixed?)
Marking fixed again. Grace, now that we know this fix is in, can you verify?
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
verified on trunk builds- all platforms
Status: RESOLVED → VERIFIED
Flags: blocking1.3b?
*** Bug 189584 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.