1491305 - The update scenario through channels doesn't work

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[ovidiu boca[:Ovidiu]]

[Affected platforms]:

Tested on Mac OS X 10.12 and Windows 10


[Steps to reproduce]:

1. Open an FF Nightly 64 without the fix - in about:profiles there is the default profile 
2. Overwrite the FF Nightly 64 with FF Nightly 65 with the fix 
3. Open FF Nightly 65

[Expected result]:

The build should open with the default profile

[Actual result]:

The 65 build is open with a new "default" profile

Note: We consider this case as a blocker for now because it will affect all the users that will do the update from the older build without the feature to the newest one that has the feature.

Comment 1

[Dave Townsend [:mossop]]

Aside from a startup crash on the OSX 65 build which seems unrelated I've been unable to reproduce this issue. The previous default profile correctly gets migrated to be the new default for the 65 build.

Can you give some more detailed steps to reproduce and also provide copies of compatibility.ini from the original default profile and the profile that 65.0a1 ends up using.

Comment 2

[ovidiu boca[:Ovidiu]]

Steps to reproduce:

1. Install an Fx 62 release and open it, in my case I didn't have any other FF build installed, so you have only the default profile. 
2. I downloaded an Fx 64 with the fix (didn't open)
3. Go to FX 62 "Show Package Contents" and delete the "Content" folder. 
4. Go to FX 64 "Show Package Contents" copy the "Content" folder and past it into Fx 62 folder. 
5. Open FX 62 and verify in about:profiles how many profiles have been created. 

Here are the results from proifles.ini    ---- https://docs.google.com/document/d/1tR2GVhgvWu27ms299W6KStKxZxLpV1_wtzRNnO2h4Do/edit

Please let me know if these steps are clear enough.

Comment 3

[ovidiu boca[:Ovidiu]]

Please note that the same behaviour is generated if I run this steps using a Nightly 64 without the fix and a Nightly 65 with the fix.

Comment 4

[Dave Townsend [:mossop]]

Seems straightforward enough, not sure why I can't reproduce this.

Can you attach profiles.ini from before you run the updated build and profiles.ini and installs.ini from after you run it?

Comment 5

[ovidiu boca[:Ovidiu]]

Hi Dave, here is a screen recording: https://streamable.com/hj59g
I will provide the other data tomorrow, thanks.

Comment 6

[ovidiu boca[:Ovidiu]]

I updated the gdoc with the information from comment 4, here: https://docs.google.com/document/d/1tR2GVhgvWu27ms299W6KStKxZxLpV1_wtzRNnO2h4Do/edit

Comment 7

[Dave Townsend [:mossop]]

(In reply to ovidiu boca[:Ovidiu] from comment #6)
> I updated the gdoc with the information from comment 4, here:
> https://docs.google.com/document/d/
> 1tR2GVhgvWu27ms299W6KStKxZxLpV1_wtzRNnO2h4Do/edit

installs.ini looks bigger than I'd expect after only running a single build with the dedicated profiles feature. Are you clearing that before attempting to reproduce?

Comment 8

[ovidiu boca[:Ovidiu]]

The results using the latest custom Nightly build 64 send us on email

https://docs.google.com/document/d/1oP62JpClJwxPjLU-DibgMZjgEzPIHWzlAcDQCykNxAo/edit

Comment 9

[Adrian Florinescu [:aflorinescu]]

Dave, based on our latest tests, I think this bug is fixed now and can be marked as resolved.

Comment 10

[Dave Townsend [:mossop]]

Fixed in the latest builds.

Comment 11

[ovidiu boca[:Ovidiu]]

I retested this issue with the latest try builds send by Dave via email and the issue is reproducible again. Based on this result I will reopen the bug. Please note that 

The try builds where the issue is reproducible (the latest ones): 

Trunk 64.0a1: https://treeherder.mozilla.org/#/jobs?repo=try&revision=4156ab7b5c10014cfc21727e86a2924cdc84b0ba
Trunk 65.0a1: https://treeherder.mozilla.org/#/jobs?repo=try&revision=df779b4756a29cdb504e90b4d062bca4f5b62be0
Beta 64.0: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3b39c723398f6765325e68eb60c3ae49f40c3aed
Devedition 64.0: https://treeherder.mozilla.org/#/jobs?repo=try&revision=877402c322d6c150e1516a83f376afae27cfbaf5


The try builds where the issue is not reproducible: 

Trunk 64.0a1: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e67cb60333b9b8458bae808f75ba41cd250edaa9 (the OSX build failure is ignorable here)
Trunk 65.0a1: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f742723910a814c8a4db7915240eaadeb083c245
Beta 64.0: https://treeherder.mozilla.org/#/jobs?repo=try&revision=4f5f75083d310234541e6afa1506265cce810013
Devedition 64.0: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b3480c31a066f70465694d1d24703b6e69688555 (I'm investigating the linux build failure here)

Comment 12

[Dave Townsend [:mossop]]

I'm struggling to figure out a way to reproduce this. Is it reproducible in a VM? If so getting it into the state immediately before running the new build and then getting it to me might help a lot. Alternatively do the following:

1. Wipe the Firefox profiles location (including any profiles.ini and installs.ini).
2. Launch and exit Firefox 62.
3. zip up the entire profiles location (including profiles.ini).
4. Run and exit the updated build.
5. zip up the entire profiles location (including profiles.ini and installs.ini).

Then send me both the zip files and let me know the exact OS you were running on.

Comment 13

[ovidiu boca[:Ovidiu]]

The link from the folder with the entire profiles location (including profiles.ini)from Fx 62 

https://drive.google.com/drive/folders/1WZ21GrRoQQ8qH6aaBa_LdBxX1sKNb_o5?usp=sharing

The entire profiles location (including profiles.ini and installs.ini) after the update to Try build 65: Trunk 65.0a1: https://treeherder.mozilla.org/#/jobs?repo=try&revision=df779b4756a29cdb504e90b4d062bca4f5b62be0


https://drive.google.com/drive/folders/1_IfxF_r38l5WrHOJ-Jpzq-wKsIW74gt4?usp=sharing


I used iMac OS X 10.12, I don't have access to a VM.

Comment 14

[Dave Townsend [:mossop]]

Marking as fixed per email.