Closed Bug 581518 Opened 9 years ago Closed 9 years ago

Profiles with absolute locations get nuked with Firefox 4 after downgrade/upgrade procedure

Categories

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

x86
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla2.0b3
Tracking Status
blocking2.0 --- beta3+
status1.9.2 --- unaffected

People

(Reporter: whimboo, Assigned: jaas)

References

Details

(Keywords: dataloss)

Attachments

(1 file)

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b3pre) Gecko/20100722 Minefield/4.0b3pre

Due to some magic, Firefox 3.6.x converts all clear text paths inside the profiles.ini into nsIFile.persistentDescriptor instances. That only happens when you i.e. have the above given extension installed in Minefield before. With the downgrade all paths get converted, and performing an upgrade to Minefield  afterward those entries can't be read and the profiles.ini gets nuked. Only the profiles under the default location will remain.

Steps:
1. Create some profiles outside of the default location, i.e. another partition
2. Start one of those profiles with a recent Minefield build
3. Install GrafxBot and restart Minefield
4. Check the profiles.ini => everything is ok
5. Close Minefield and start Firefox 3.6.x with the same profile
6. Check the profiles.ini => all paths have been converted
7. Close Firefox 3.6.x
8. Start Minefield again

With step 8 you will see that all of the profiles stored at other locations have been nuked from the profiles.ini file. Only the ones at the default location remain.

The question is what's that special on that extension that it causes this behavior. There is no way for me to reproduce without that extension installed.

For users without knowledge of the details it will be a dataloss, even the profile will remain. Not sure if it is enough for the dataloss keyword. Feel free to remove it again.
and a result of this causes bug 581482
Ok, please drop the part with the extension! It's not necessary. It's even simpler:

1. Start Minefield with a fresh profile
2. Restart Minefield with the same profile
3. Start a Firefox 3.6.x build
Looks like this is only a problem switching from branch to trunk as branch supports trunk's form of persistent descriptor.

Trunk lost branch's form with bug 571193
Assignee: nobody → joshmoz
Blocks: 571193
blocking2.0: ? → betaN+
I can also see this with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Firefox/3.6.7

As given by the build id it is quite some days before the first commit of the patch on bug 571193. Are you sure that this is the reason?
(In reply to comment #4)
> I can also see this with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
> rv:1.9.2.7) Gecko/20100713 Firefox/3.6.7
> 
> As given by the build id it is quite some days before the first commit of the
> patch on bug 571193. Are you sure that this is the reason?

Sorry, that was the wrong build id. And it's really caused by bug 571193. Beta 2 is working as expected. We simply converted the profiles.ini between clear paths and persistentDescriptor instances.

This regression makes it really hard for QA to run tests with Minefield on our own machine. Because any start of Minefield will nuke our profiles.ini file.
Whiteboard: [4b2]
In particular, the old behavior of SetPersistentDescriptor is what we need back: http://hg.mozilla.org/mozilla-central/annotate/5372b453a52e/xpcom/io/nsLocalFileOSX.mm#l1463
blocking2.0: betaN+ → beta3+
Whiteboard: [4b2]
Whiteboard: [4b2]
Attached patch fix v1.0Splinter Review
I haven't tested this yet but it compiles and probably works. Will request review when I've tested.
(In reply to comment #7)
> Created attachment 460115 [details] [diff] [review]
> fix v1.0
> 
> I haven't tested this yet but it compiles and probably works. Will request
> review when I've tested.

Tested with a debug build and the patch applied. Works fine for me. Thanks for this quick turnaround Josh!
Status: NEW → ASSIGNED
Attachment #460115 - Flags: review?(b56girard)
The patch looks good. Are we sure we don't need the NS_OBJC_BEGIN_TRY_ABORT_BLOCK_NSRESULT?
Attachment #460115 - Flags: review?(b56girard) → review+
The APIs being used here aren't going to throw Obj-C exceptions.
OS: Mac OS X → Windows 7
Attachment #460115 - Flags: review?(benjamin)
pushed to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/3559a37d183f
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Attachment #460115 - Flags: review?(benjamin) → review+
Looks good with todays Minefield build. Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b3pre) Gecko/20100726 Minefield/4.0b3pre
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla2.0b3
Blocks: 581482
You need to log in before you can comment on or make changes to this bug.