Tracy Walker [:tracy] Reporter
	Description • 10 years ago

1) Install a version of Aurora from 20141107
2) launch it shut it down
3) change channel-prefs.js to "auroratest"
4) launch Aurora
5) wait for or trigger an update
6) The browser is updated to the Dev Edition as expected

However, no first run page is presented

7) shutdown and relaunch (I have profile manager, so selected the dev edition profile)

This launch (second of Dev editions life), the first run page is presented.

expected the first run page on the the first launch of the new browser edition.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 1 • 10 years ago

This is worse than "first run doesn't trigger" - the update triggered by the restart keeps the old profile. This has the potential to confuse people when they later restart and get the new dev edition profile :(

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 2 • 10 years ago

Fixing this also requires fixing builds that you update from, because the issue as past and I debugged it on IRC is that the restart-to-update code doesn't pass the special "don't re-use the same profile" flag, so we'd need to fix pre-devedition Aurora builds and update people to them to avoid this problem. Don't think that's going to happen.

	Panos Astithas (he/him) [:past] (please ni?)
	Comment 3 • 10 years ago

Just for reference, this is what we discussed, but doesn't seem like a good idea.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 4 • 10 years ago

I think it's too late to fix this, really. Since this only really affects this upgrade, I'm not sure there's much benefit to landing a fix for future cases (not sure we expect any).

	Jennifer Bertsch [:jbertsch]
	Comment 5 • 10 years ago

Gavin - will everyone be upgraded today?

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 6 • 10 years ago

Not all will, but even those who do not upgrade today would need to be updated to an updated "old" build first, and only then updated to Dev Edition. So we would need to pull Dev Edition updates and revert to "plain Aurora" updates, which I don't think we can do given the announcements.

	Axel Kratel
	Comment 7 • 10 years ago

So what's the work around? I was doing fine with the gum builds, then I downloaded the public build, and when i tried to start I got the familiar "you can only have one instance of Firefox" message.

	Axel Kratel
	Comment 8 • 10 years ago

Steps I took: 

Previous state: using some gum build (forget which one)

- Downloaded new version of developer edition and overwrote gum build. 
- turns out developer edition is using my old aurora profile, not the dev edition profile created while running gum builds. 

Cannot run dev edition with any other Firefox versions.

	Brian Grinstead [:bgrins]
	Comment 9 • 10 years ago

(In reply to Axel Kratel from comment #8)
> Steps I took: 
> 
> Previous state: using some gum build (forget which one)
> 
> - Downloaded new version of developer edition and overwrote gum build. 
> - turns out developer edition is using my old aurora profile, not the dev
> edition profile created while running gum builds. 
> 
> Cannot run dev edition with any other Firefox versions.

Can you test either using an existing Aurora build or a fresh download and see if you have the same problem?  The gum->dev edition upgrade is not really a 'normal' thing that would affect anyone who wasn't running gum builds.

	Tracy Walker [:tracy] Reporter
	Comment 10 • 10 years ago

restarting the dev-edition is the workaround.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 11 • 10 years ago

Actually... we could make the dev edition builds ignore the XRE_PROFILE_* environment variables, I suppose? Not sure what other impact that might have.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 12 • 10 years ago

(In reply to Axel Kratel from comment #7)
> So what's the work around? I was doing fine with the gum builds, then I
> downloaded the public build, and when i tried to start I got the familiar
> "you can only have one instance of Firefox" message.

This sounds like a separate issue - can you file a separate bug?

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 13 • 10 years ago

This is what I was thinking of. There are other quit() callers that should probably also set MOZ_RESTARTING_FOR_UPDATE. Perhaps ideally we would add a quit() reason for "restarting for update" (e.g. eForUpdate) and have the quit() implementation set MOZ_RESTARTING_FOR_UPDATE if it is specified.

We could only leave this in on Aurora for a short time (it's only really useful as more Aurora users update from pre-dev edition builds - I'm assuming there are still a significant number of such users not yet updated such that it's worth bothering).

I haven't tested this - perhaps you can take this and run with it, Panos?

	Benjamin Smedberg
	Comment 14 • 10 years ago

Hasn't this ship already sailed? Unless people are leaving dev edition open forever and only restarting for update, this doesn't seem like a particularly valuable thing to work on any more.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 15 • 10 years ago

I think it would have had some value if we landed it yesterday. I was hoping past would jump on this.

	Panos Astithas (he/him) [:past] (please ni?)
	Comment 16 • 10 years ago

I'm still swamped with other work and I'll need to take some time off next week to recover from the past month. It's unlikely that I can give this the proper attention in the imminent future. If you think there is still value in doing this some time next week, I'll be happy to pick it up then.