1455707 - Warn when starting a profile that last ran with a newer build

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, enhancement, P1)

Comment 1

[Dave Townsend [:mossop]]

Attachment: Bug 1455707: Add UI allowing the user to choose what to do when a downgrade is detected.

Review commit: https://reviewboard.mozilla.org/r/238568/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/238568/

Comment 2

[Dave Townsend [:mossop]]

Attachment: Screenshot

This is a screenshot of the current implementation. It triggers whenever an older version (including build ID) is run with the selected profile. What are your thoughts on this?

Comment 3

[Joe Hildebrand [:jhildebrand] (UTC-6)]

I am fine with this as a starting point.  Do we need to gather metrics?  I'm also very interested in pdol's opinion on whether "subtly corrupt my profile" is an ok option, or whether we'd like to replace that with "create a new profile" or "start profile manager" or both.

Comment 4

[Dave Townsend [:mossop]]

I think I can give us some metrics with a little more work. Counting the case where the user quits is a little tricky!

Comment 5

[Joe Hildebrand [:jhildebrand] (UTC-6)]

I'm more interested in counting the case where the users says "I don't care if my browser is corrupted."  There's an argument that if we let them take that choice, some of their other telemetry on stability (e.g.) is suspect.

Comment 6

[Dave Townsend [:mossop]]

(In reply to Joe Hildebrand  [:hildjj] (UTC-6) from comment #5)
> I'm more interested in counting the case where the users says "I don't care
> if my browser is corrupted."  There's an argument that if we let them take
> that choice, some of their other telemetry on stability (e.g.) is suspect.

That's true. I was mostly thinking that without instrumenting the other case we wouldn't know relative numbers.

Comment 7

[Romain Testard [:RT]]

Saptarshi, could you please help understand how frequently users would see this?
It's somehow similar to the analysis you did on profile switching although this now ignores whether you're a cross profile user:
- How many unique profiles (regardless of the channel used) are used on an older Firefox version when compared to the previous session daily?

This previous analysis done by Benjamin showed 2.19% of users reverting to an older version while staying on the release channel. Is this still up to date and indeed reflective of how frequently this prompt would be see by users?
https://gist.github.com/bsmedberg/1af70857106bfe29128a0e8d0b656804

Comment 8

[Romain Testard [:RT]]

(In reply to Dave Townsend [:mossop] from comment #2)
> Created attachment 8969761 [details]
> Screenshot
> 
> This is a screenshot of the current implementation. It triggers whenever an
> older version (including build ID) is run with the selected profile. What
> are your thoughts on this?

My thoughts:
- New profile creation and profile manager are likely too complicated concepts for average users to make informed decisions. Hitting "Create a new profile" would effectively hide the user data from himself without an easy way to recover. I NI Bram here who we discussed these concepts with before to see if he has thoughts on the UX.
- How harder would it be for the "Quit" button to be "Quit and instead run most up to date Firefox"?
- I agree Telemetry would be valuable. It would have to be run on release since Beta data would be likely non representative
- Per previous data we had on cross channel usage where most downgrades occured for ESR users, I'd assume this feature would be would be most frequently used on the next ESR

Comment 9

[Dave Townsend [:mossop]]

(In reply to Romain Testard [:RT] from comment #8)
> - How harder would it be for the "Quit" button to be "Quit and instead run
> most up to date Firefox"?

"Most up to date" is very difficult, we don't have a definitive list on the machine for all the installed Firefoxes and their versions. What we can do though is offer to launch with the last install that ran this profile (assuming it's not the current instance already and it still exists on disk).

Comment 10

[Dave Townsend [:mossop]]

I've confirmed that we have a path for recording telemetry data from this UI. It's a bit more complex than normal since we always restart the app after showing this UI but it is doable.

What questions about this UI do we want to answer with data here? Some thoughts:

What percentage of startups see this UI?
What percentage of displays result in a click on Quit and on Continue?

Comment 11

["Saptarshi Guha[:joy]"]

My initial reaction, seeing the screenshot, is for a given release profile
- inspect the times series of appBuildID contained in their Unified telemetry profile
- sort by calendar date
- see if any of the appbuildids are "out of order" i.e. goes back in time (substr(appbuildid,1,8) is YYYYMMDD) which would correspond to someone getting that prompt

Does that make sense?

Comment 12

[Dave Townsend [:mossop]]

(In reply to "Saptarshi Guha[:joy]" from comment #11)
> My initial reaction, seeing the screenshot, is for a given release profile
> - inspect the times series of appBuildID contained in their Unified
> telemetry profile
> - sort by calendar date
> - see if any of the appbuildids are "out of order" i.e. goes back in time
> (substr(appbuildid,1,8) is YYYYMMDD) which would correspond to someone
> getting that prompt
> 
> Does that make sense?

I don't know if that might have some false positives because we compare both the version and build ID, so: 59.0_20180404 -> 60.0a1_20180303 would be considered an upgrade as the version number increased but your proposal considers it a downgrade based on the build ID.

Comment 13

["Saptarshi Guha[:joy]"]

good point. Sort 

- inspect the times series of appBuildID contained in their Unified telemetry profile
- sort by calendar date and version major
- within version major, see if any of the appbuildids are "out of order" i.e. goes back in time (substr(appbuildid,1,8) is YYYYMMDD) which would correspond to someone getting that prompt

Though is downgrading within a major version a case for the above prompt? if not, and we only want to consider downgrading a major version the above would change to

- inspect the times series of appBuildID contained in their Unified telemetry profile
- sort by calendar date 
- see if major versions are out of order

Comment 14

[Dave Townsend [:mossop]]

(In reply to "Saptarshi Guha[:joy]" from comment #13)
> good point. Sort 
> 
> - inspect the times series of appBuildID contained in their Unified
> telemetry profile
> - sort by calendar date and version major
> - within version major, see if any of the appbuildids are "out of order"
> i.e. goes back in time (substr(appbuildid,1,8) is YYYYMMDD) which would
> correspond to someone getting that prompt

If I'm reading this right it will only catch build-id downgrades within a major version (what does major version mean here?)

So would this count as a downgrade?

60.0 20180404
59.0 20180405
60.0 20180406

> Though is downgrading within a major version a case for the above prompt?

Yes the UI will show if the version (61.0a1 f.e.) remains the same but the build id drops.

> if not, and we only want to consider downgrading a major version the
> above would change to
>
> - inspect the times series of appBuildID contained in their Unified
> telemetry profile
> - sort by calendar date 
> - see if major versions are out of order

Do we happen to have an implementation of the toolkit version comparison code in a place that telemetry can use it? What the code is actually doing is building a version number as <version>_<buildid> for the previous build to run against the profile and the current build, then doing a version comparison based on that. If the last build is newer by that metric then we show the UI. If we can just do that in the same way in telemetry then it should give a perfect comparison.

Comment 15

["Saptarshi Guha[:joy]"]

(In reply to Dave Townsend [:mossop] from comment #14)
> (In reply to "Saptarshi Guha[:joy]" from comment #13)
> > good point. Sort 
> > 
> > - inspect the times series of appBuildID contained in their Unified
> > telemetry profile
> > - sort by calendar date and version major
> > - within version major, see if any of the appbuildids are "out of order"
> > i.e. goes back in time (substr(appbuildid,1,8) is YYYYMMDD) which would
> > correspond to someone getting that prompt
> 
> If I'm reading this right it will only catch build-id downgrades within a
> major version (what does major version mean here?)
> 

major is the prefix before the decimal i.e. 60.0 -> 60

> So would this count as a downgrade?
> 
> 60.0 20180404
> 59.0 20180405
> 60.0 20180406
> 

it depends on whether your example is sorted by calendar
assuming you have

201800501 60.0 20180404
201800502 59.0 20180405
201800502 60.0 20180406

then sorting by calendar and version produces

201800501 60.0 20180404
201800502 59.0 20180405
201800502 60.0 20180406

then this is a downgrade because it went from 60 -> 59

downgrades, as i'm understanding it is 

the profile went to an older version e.g. 60.* -> 59.* or 60.x to 60.y where y was 60.y was released *before* 60.x.
I am assuming this prompt is shown iff these conditions occur.


> Do we happen to have an implementation of the toolkit version comparison
> code in a place that telemetry can use it? What the code is actually doing
> is building a version number as <version>_<buildid> for the previous build
> to run against the profile and the current build, then doing a version
> comparison based on that. If the last build is newer by that metric then we
> show the UI. If we can just do that in the same way in telemetry then it
> should give a perfect comparison.


This would be perfect. Who ever does the analysis can just implement the same logic used by the UI prompt uses
bypassing the need of me trying to infer the logic above!

Comment 16

[Dave Townsend [:mossop]]

(In reply to "Saptarshi Guha[:joy]" from comment #15)
> (In reply to Dave Townsend [:mossop] from comment #14)
> > (In reply to "Saptarshi Guha[:joy]" from comment #13)
> > > good point. Sort 
> > > 
> > > - inspect the times series of appBuildID contained in their Unified
> > > telemetry profile
> > > - sort by calendar date and version major
> > > - within version major, see if any of the appbuildids are "out of order"
> > > i.e. goes back in time (substr(appbuildid,1,8) is YYYYMMDD) which would
> > > correspond to someone getting that prompt
> > 
> > If I'm reading this right it will only catch build-id downgrades within a
> > major version (what does major version mean here?)
> > 
> 
> major is the prefix before the decimal i.e. 60.0 -> 60

Do we need to see cases where someone goes from 60.0 -> 60.0a1?

> > Do we happen to have an implementation of the toolkit version comparison
> > code in a place that telemetry can use it? What the code is actually doing
> > is building a version number as <version>_<buildid> for the previous build
> > to run against the profile and the current build, then doing a version
> > comparison based on that. If the last build is newer by that metric then we
> > show the UI. If we can just do that in the same way in telemetry then it
> > should give a perfect comparison.
> 
> 
> This would be perfect. Who ever does the analysis can just implement the
> same logic used by the UI prompt uses
> bypassing the need of me trying to infer the logic above!

I'm not sure I follow, is this a yes or a no?

Comment 17

["Saptarshi Guha[:joy]"]

Im asking if there exists code in place that determines when to show the UI and can this be replicated using the Unified Telemetry variables. If such a code exists, i can confirm whether this can be implemented using the telemetry data.

If such code exists, then we wont need to create the logic im trying to describe above.

Comment 18

[Dave Townsend [:mossop]]

(In reply to "Saptarshi Guha[:joy]" from comment #17)
> Im asking if there exists code in place that determines when to show the UI
> and can this be replicated using the Unified Telemetry variables. If such a
> code exists, i can confirm whether this can be implemented using the
> telemetry data.
> 
> If such code exists, then we wont need to create the logic im trying to
> describe above.

Right, and I was asking if the toolkit version comparison code has been implemented in whatever we use to get telemetry data, this thing: https://developer.mozilla.org/en-US/docs/Mozilla/Toolkit_version_format

Comment 19

["Saptarshi Guha[:joy]"]

I see, not that i'm aware of. Rather than trying to implement this, do we have python code available? 
I'm hoping it will have a function that can order two versions.

Comment 20

[Dave Townsend [:mossop]]

(In reply to "Saptarshi Guha[:joy]" from comment #19)
> I see, not that i'm aware of. Rather than trying to implement this, do we
> have python code available? 
> I'm hoping it will have a function that can order two versions.

How about this: https://github.com/kmaglione/amo-validator/blob/master/validator/version.py

Comment 21

["Saptarshi Guha[:joy]"]

Yes this looks good.

Comment 22

[Dave Townsend [:mossop]]

Attachment: Screenshot for launch previous

This is what it looks like when we detect that the previous Firefox to run with this profile is different to the current one and still exists on disk. Look ok?

Comment 23

[Dave Townsend [:mossop]]

Comment on attachment 8969760 [details]
Bug 1455707: Add UI allowing the user to choose what to do when a downgrade is detected.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/238568/diff/1-2/

Comment 24

[Peter Dolanjski [:pdol]]

Removing my NI - I'll defer to :rtestard

Comment 25

[Dave Townsend [:mossop]]

(In reply to Peter Dolanjski [:pdol] from comment #24)
> Removing my NI - I'll defer to :rtestard

Looks like Romain is on PTO till May 9th and we'd like to get something moving before then. Specific questions I'm looking to get answered:

* Should we proceed with this at all?
* Should we be offering a way to continue anyway (may cause profile corruption)?
* Should we offer a way to create a new profile or launch the profile manager instead?

Comment 26

[Bram Pitoyo [:bram]]

Sorry for the late response to the NI, as I was away on a user research trip.

TL;DR

* If we know that starting a profile on an older build doesn’t cause too much brokenness, or has relatively low risk, then we don’t need to show a UI.
* If we know that it can potentially cause a lot of problem, then show the UI, but which action should be the default? See below.



From my very limited (but daily) experience of running Nightly and release using the same profile, it seems as if opening a profile in an older version of Firefox doesn’t cause any brokenness. All my data and settings remained intact so far.

This is an experience mirrored by Verdi, quoted below:

> …I've done that kind of thing all the time for years on both Windows and Mac and have never run into an issue from what I can tell.

If we assume that both of our experiences are – in some ways – representative of the experiences of many other users who like to switch versions, we wonder: assuming we show a notification UI, then of all the users who would see that notification, how many of them would actually run into an issue?

If there aren’t many, then we don’t need to have a UI. Because whatever option they pick in that UI, they will probably not run into any issue.



Ok. Now let’s assume that corrupted profiles is a real risk for us, so we want to show the UI to be absolutely safe. Which option do we want to highlight as a recommended path for most users to take?

* Run the newer version of Firefox, or
* Run the older version, understanding that there may be risk involved?



Quoting Verdi again:

> I'm trying to think of the big cases where this would happen outside of Mozillians switching between Nightly and Release.
> 
> It would happen if you try out beta and switch back to release (maybe the largest group?).
> 
> It would happen if you use the same profile for dev-edition and release (though you’d have to jump through a lot of hoops to make that happen).
> 
> And I guess this happens if you are switching between ESR and release (maybe that's the one with the most potential for something to go wrong?)


Reading those scenarios, it seems that the largest potential group, other than users who run Nightly and Release, would be users who run Beta and want to switch back to Release – maybe because Beta had broken something. We can reasonably infer this fact, because beta has a significant number of users (second only to release). So the logic goes that some of our beta users must want to switch back to release, or have regretted their decision to run the Beta version.

In that case, if the dialogue UI is shown, then the preferred action to take should be “Run the older version”.



But instead of emphasising the risk and the things that could go wrong, I recommend changing our tone a bit to be more reassuring, and to provide a troubleshooting step should anything happens.

For example, it can be something like this (caveat: strawman message – feedback welcome):

> Older version detected
> 
> Your Firefox profile was previously used to run a newer version of Firefox, but the version you are trying to run is older.
> 
> While there may be a risk of Firefox behaving unexpectedly if you run this version, Firefox Reset can help fix anything that may go wrong.
> 
> [Quit and launch newer version] [Continue launching older (this) version]



What do you think?

Comment 27

[Dave Townsend [:mossop]]

The main challenge here is that we (currently) don't know if a given downgrade will cause a problem. We know the recent indexed-db change caused problems, it made websites unable to save data which showed up, probably well after the user downgraded, as broken websites. I'm not convinced that users will remember at that point to try a profile reset. Additionally a profile reset may not work in this circumstance if, for example, we've significantly changed their bookmarks/history database.

Comment 28

[Dave Townsend [:mossop]]

(In reply to "Saptarshi Guha[:joy]" from comment #21)
> Yes this looks good.

Is there anything further you need from me to do the analysis from comment 7?

Comment 29

[Bram Pitoyo [:bram]]

(In reply to Dave Townsend [:mossop] from comment #27)
> […] We know the recent indexed-db change caused
> problems, it made websites unable to save data which showed up, probably
> well after the user downgraded, as broken websites.

This sounds like a big problem. Based on this data, maybe we should offer the UI, and have the least potentially destructive choice – “Run newer version” – as a preferred/highlighted option.

Comment 30

["Saptarshi Guha[:joy]"]

(In reply to Dave Townsend [:mossop] from comment #28)
> (In reply to "Saptarshi Guha[:joy]" from comment #21)
> > Yes this looks good.
> 
> Is there anything further you need from me to do the analysis from comment 7?


- There were 824,858,600 release profiles active between 2017-11-14 and 2018-04-01(nearly 6 months)
- of which there were 581,145,700 profiles who were active for more than one day (70.454%)
    - of these, 29,939,300 profiles were seen on an older version compared to the version observed on their previous day of use (5.152% )
    - for the profiles who did ‘downgrade’, the average number of times we saw this happen is 2.665 (75% percentile is 2)


Code: https://metrics.mozilla.com/protected/sguha/version_switch.html (behind lDAP but i can keep it on my personal website if you would like this public).

Comment 31

[Romain Testard [:RT]]

I'm now back from leave, apologies for the delay here.
My recollection of the thread:
- A significant share of users downgrade. We cannot predict the impact of downgrades but the impact can be bad enough that we want to warn users.
- We know from previous analysis that most downgrades happen between ESR and release (*see below). Given the proposed UI would be displayed on the older version, this allows testing at lower scale until the next ESR hits release in 1 year.
- We technically can offer the option to launch the last install that ran this profile
- We can collect telemetry to address the following questions:
---What percentage of startups see this UI?
---What percentage of displays result in a click on Quit and on Continue?
---What is the impact on retention of the UI?
- The least destructive UI seems to be:
> Older version detected
> 
> Your Firefox profile was previously used to run a newer version of Firefox, but the version you are trying to run is older.
> 
> While there may be a risk of Firefox behaving unexpectedly if you run this version, Firefox Reset can help fix anything that may go wrong.
> 
> [Quit and launch newer version](referred/highlighted option) [Continue launching older (this) version]
Firefox reset is although hard to find and may be not useful at all. I think it also makes the message hard to read and I feel like not confusing users with Firefox reset will get more of them to select the default provided option. I would propose the following variation based on this:

> Older version detected
> 
> Your Firefox profile was previously used to run a newer version of Firefox, but the version you are trying to run is older.
> 
> There may be a risk of Firefox behaving unexpectedly if you run this version.
> 
> [Quit and launch newer version](referred/highlighted option) [Continue launching older (this) version]

I updated the user story field accordingly.

Bram - what do you think?

*Data Saptarshi shared before on profile switching between channels:
- 17.34% of Nightly profiles switch
- 3.28% of Beta profiles switch
- 2.24% of ESR profiles switch
- 0.36% of release profiles switch
For example, 17.34% of nightly users switched greater than 3 times (e.g. nightly -> release -> nightly -> release) in a 60 day period. A profile is nightly if it ever was on nightly during that 60 day period.
Given relative user numbers on different channels, ESR users are the largest switchers

Comment 32

[Bram Pitoyo [:bram]]

My initial thought is that your proposed solution looks good.

However, I will NI Michelle for advise on wording, since mine may run too long.

---

Michelle, here’s our background story of why we needed your team’s help:

When you install a different Firefox product (Nightly, Beta or ESR), that product doesn’t always create a fresh new profile for you. As a result, two or more products can all share the same profile.

The problem: when you run a product with a newer version number, your profile will be “upgraded”. Once “upgraded”, running the same profile in an older version may cause significant problems like altered bookmarks/history.

Our users revert to older versions for many reasons. A lot of it is due to the fact that rolling back is a legitimate way to solve issues. Websites or features may work properly on an experimental version like Nightly. The solution? Revert to Release, where things are guaranteed to work.

Because altered bookmarks/history is a problem, we’d like to warn our users who switch to an older version. We’d like to say “If you’re rolling back to fix issue, be aware of the risk. If you’re rolling back unintentionally, it’s best to run the newest version.

This warning will appear before our users start the older version. At the moment, we’ve come up with:

> Title: Older version detected
> 
> Your Firefox profile was previously used to run a newer version of Firefox, but the version you are trying to run is older.
> 
> There may be a risk of Firefox behaving unexpectedly if you run this version.
> 
> [Quit and launch newer version] -> highlighted    [Continue launching older (this) version]

Does this sound okay as a warning dialogue, and would you recommend a better, more accurate wording? We can afford to write a more technical explanation.

---

I will also CC Verdi on the issue because he’s interested in seeing some numbers and may have some insights to offer. As expected, most of the use is to switch between Nightly and Release versions. However, I didn’t expect switching more than 3 times. This may indicate the fact that some users continually run both versions deliberately – for testing purposes?

Comment 33

[mheubusch]

@bram - what do you think of: 
Title: You’ve launched an older version of Firefox
> 
> Your Firefox profile is designed to work with a newer version of Firefox, but you are about to use it with an older version. 
If you use your profile with this older version, you may experience problems with Firefox and may not have full access to your bookmarks and browsing history. 


> [Cancel and launch newer version] -> highlighted    [Launch this version anyway]

Obviously we cant include a link to SUMO to learn more about how to safely downgrade b/c they don't have a browser open yet, but does it make sense to include a note that says: Search support.mozilla.org for more information on using older versions of Firefox safely

Comment 34

[Joe Hildebrand [:jhildebrand] (UTC-6)]

The likelihood of having problems is not "may".  It's "almost certainly".  We need this restriction to be pretty adamant if we're going to depend on it going forward.  For example, when we change the storage mechanism for things in your profile, do we have to keep both versions around for multiple ESR releases?  How do we keep them in sync?  Which one do we read?

The only rational way to make forward progress on storage is to make it nearly-impossible (e.g. require a command line flag) to use a profile on an older version, and to use FxS to sync data that people really need in their new profile.

Comment 35

[Bram Pitoyo [:bram]]

(In reply to mheubusch from comment #33)
> […] does it make sense to
> include a note that says: Search support.mozilla.org for more information on
> using older versions of Firefox safely

Thanks for your very quick reply, Michelle!

As far as I know, we don’t have a SUMO article explaining this issue.

But if, as Joe wrote in comment #34,
> The likelihood of having problems is not "may".  It's "almost certainly".

Then we definitely want this article. And we want it to explain a few things:

1. Why it’s nearly impossible to run profile in an older version. There should be something here about version incompatibility.
2. What happens if you choose to do so. No access to bookmarks and history, what else?
3. How to solve the problem
   * Export bookmarks, start new profile on older version, import bookmarks? But your history won’t be restored.
   * Use the command line if you really know what you’re doing (not recommended)?

Joe’s comment also made me think that we want another option that will provide a “clean” way out, which is:
> Launch this version using a new profile

Or, even better:
> Launch this version using a new profile (your bookmarks will be restored)

Either way, our two options become:
> [Cancel and launch newer version] -> highlighted   [Launch this version using a new profile]

And if we still want to provide a way of doing the unsafe action, we can include it as a note:
> Launching this version using your existing profile is possible but will almost certainly corrupt your bookmarks and history.

What are your thoughts, Romain?

Comment 36

[Joe Hildebrand [:jhildebrand] (UTC-6)]

We also have sync as an option.  If you use FxS, bookmarks, history, open tabs, logins, addresses, credit cards, add-ons, and preferences can all be restored easily.

Here is a list of all of the incompatibilities we know about as of 57: https://public.etherpad-mozilla.org/p/quota-manager-schema-change-log

Note that there is at least one per version, that we don't have any process for keeping these from happening, and that the doc hasn't been updated since 57.

Comment 37

[Dave Townsend [:mossop]]

(In reply to Romain Testard [:RT] from comment #31)
> - We technically can offer the option to launch the last install that ran
> this profile

This is not always the case. The previous install may no longer be present on the system or may have been overwritten with the current, older version. We can detect both those cases before offering this option to the user though.

(In reply to Joe Hildebrand  [:hildjj] (UTC-6) from comment #34)
> The likelihood of having problems is not "may".  It's "almost certainly".

In the case of a full version downgrade this is true. Currently though the patch shows the UI even for minor version downgrades or even a simple build ID change (meaning if you switch from one Nightly to the previous day's Nightly it will trigger). In these cases I think the likelihood is much lower, I would expect Nightly users switching around to be one of the main cases too. Do we want to show the UI in those cases and do we want it to have an easier bypass option in those cases? I'm a little worried that we'll really burn some nightly users with this as it stands.

(In reply to Bram Pitoyo [:bram] from comment #35)
> Either way, our two options become:
> > [Cancel and launch newer version] -> highlighted   [Launch this version using a new profile]

One concern here is that if users are doing this switching frequently and keep launching with a new profile they could end up with a lot of unused profiles sitting around on their disk, and profiles can get quite large. We might need some kind of way to expire unused profiles in the future.

Comment 38

[Joe Hildebrand [:jhildebrand] (UTC-6)]

(In reply to Dave Townsend [:mossop] from comment #37)
> In the case of a full version downgrade this is true. Currently though the
> patch shows the UI even for minor version downgrades or even a simple build
> ID change (meaning if you switch from one Nightly to the previous day's
> Nightly it will trigger). In these cases I think the likelihood is much
> lower, I would expect Nightly users switching around to be one of the main
> cases too. Do we want to show the UI in those cases and do we want it to
> have an easier bypass option in those cases? I'm a little worried that we'll
> really burn some nightly users with this as it stands.

I'd be ok with having a command line option to force an overrides to this dialog. Firefox developers might want that when doing a bisect, for example.  Any Nightly user that might be switching back and forth will either welcome the warning (crud!  I launched the wrong binary!) or will know what they're doing enough to use the flag.

> One concern here is that if users are doing this switching frequently and
> keep launching with a new profile they could end up with a lot of unused
> profiles sitting around on their disk, and profiles can get quite large. We
> might need some kind of way to expire unused profiles in the future.

Pushing the user into the Profile Manager might make that more clear, as would ensuring that the total size of each profile was shown in the Profile Manager.

Comment 39

[Bram Pitoyo [:bram]]

Sounds like a solution is emerging: run the older version with a new profile, then sync it to restore data.

If that’s the case, what if we do something like this?

> Title: You’ve launched an older version of Firefox
>
> To avoid problem accessing your bookmarks and browsing history, this version will start with a new profile.
>
> You can restore your bookmarks and browsing history by signing into Firefox Account and performing a sync.
>
> [Cancel and launch newer version] -> highlighted   [Launch this version using a new profile]

The older version can start with about:preferences#sync open in the first tab.


(In reply to Dave Townsend [:mossop] from comment #37)
> One concern here is that if users are doing this switching frequently and
> keep launching with a new profile they could end up with a lot of unused
> profiles sitting around on their disk, and profiles can get quite large.

Is there a way for us to detect whether there is already a unique profile associated with that version of Firefox?

If the older version is already running a profile that’s different from the one running in the newer version, then we don’t need to show any warning dialogue.

If the older version doesn’t have a unique profile yet, then show the warning.

Comment 40

[Joe Hildebrand [:jhildebrand] (UTC-6)]

(In reply to Bram Pitoyo [:bram] from comment #39)

> If that’s the case, what if we do something like this?
> 
> > Title: You’ve launched an older version of Firefox
> >
> > To avoid problem accessing your bookmarks and browsing history, this version will start with a new profile.
> >
> > You can restore your bookmarks and browsing history by signing into Firefox Account and performing a sync.
> >
> > [Cancel and launch newer version] -> highlighted   [Launch this version using a new profile]
> 
> The older version can start with about:preferences#sync open in the first
> tab.

Really like that.

Comment 41

[Dave Townsend [:mossop]]

Attachment: Screenshot with previous instance detected

Here is the current implementation where a previous instance was detected and the profile we attempted to use was signed in to sync.

Comment 42

[Dave Townsend [:mossop]]

Attachment: Screenshot with no previous instance

Here is a shot where the previous instance is gone or overwritten and the existing profile was not signed in to sync.

Comment 43

[Dave Townsend [:mossop]]

You'll note that I've sent the users to the profile manager rather than simply creating a new profile, it was somewhat easier and I think gives users more insight into what is going on.

(In reply to Bram Pitoyo [:bram] from comment #39)
> Is there a way for us to detect whether there is already a unique profile
> associated with that version of Firefox?
> 
> If the older version is already running a profile that’s different from the
> one running in the newer version, then we don’t need to show any warning
> dialogue.
> 
> If the older version doesn’t have a unique profile yet, then show the
> warning.

This is challenging to implement but its something I want to do later as it is really part of a better solution.

Comment 44

[Bram Pitoyo [:bram]]

Comment 41:
> attachment 8976003 [details]
> Screenshot with previous instance detected

This looks great.

Would it be possible to avoid doubling up the window title and copy heading?

Secondly, let’s amend the body copy. It will still explain the same thing, but stresses the safety of the procedure:

> If you use your profile with this older version, you may experience problems with Firefox and may not have full access to your bookmarks and browsing history.
>
> To launch this version safely, open Profile Manager and choose a different profile. Afterwards, sign into Firefox Account and perform a sync to restore your bookmarks and browsing history.
> 
> [Open Profile Manager]   [Exit and launch newer version]


Comment 43:
> attachment 8976004 [details]
> Screenshot with no previous instance

Even in this situation, is it still a good idea to promote FxA Sync in the copy?

If not, we can keep the strings above and just cut the last sentence out.

Comment 45

[Dave Townsend [:mossop]]

(In reply to Bram Pitoyo [:bram] from comment #44)
> Comment 41:
> > attachment 8976003 [details]
> > Screenshot with previous instance detected
> 
> This looks great.
> 
> Would it be possible to avoid doubling up the window title and copy heading?

I need to investigate. So early in startup we're a little limited with what we can do but I think I can make it work.

> Secondly, let’s amend the body copy. It will still explain the same thing,
> but stresses the safety of the procedure:
> 
> > If you use your profile with this older version, you may experience problems with Firefox and may not have full access to your bookmarks and browsing history.
> >
> > To launch this version safely, open Profile Manager and choose a different profile. Afterwards, sign into Firefox Account and perform a sync to restore your bookmarks and browsing history.
> > 
> > [Open Profile Manager]   [Exit and launch newer version]

Easy enough!

> Comment 43:
> > attachment 8976004 [details]
> > Screenshot with no previous instance
> 
> Even in this situation, is it still a good idea to promote FxA Sync in the
> copy?
> 
> If not, we can keep the strings above and just cut the last sentence out.

We can promote sync but it doesn't get them their bookmarks and history back, so I'm not sure it's a good sell IMO. I'll do it without that for now.

Comment 46

[Bram Pitoyo [:bram]]

Sounds like a plan. At this point, the design is in a good place, and its most important goal have been reached: to get users where they want to go without losing data (FxA sync), and to default to the least destructive action (run newer version). Thank you, Dave!

Comment 47

[Romain Testard [:RT]]

Alex, can you please help clarify the share of our users on desktop who are signed into Sync? My understanding is that this share is marginal. This would imply that the majority of our users will see 
> > attachment 8976004 [details]

Are we not missing the most frequent scenario that is "a previous instance was detected and the profile we attempted to use was NOT signed in to sync"? Options would be "Cancel and launch newer version" (default) and "Launch profile manager"

I agree that "Launch profile manager" is not ideal as a fall-back given it's not very user friendly though it sounds better than what we currently offer to users. Given ESR/release switching is what drives most downgrades, we have until the next ESR to get this message right for most switching scenarios and telemetry is probably critical, here is what I think is valuable to collect along with this implementation:
---What percentage of startups see each variation of the UI?
---What is the version/channel distribution of users who see each variation of the UI?
---What percentage of displays result in a click on each of the 2 options offered?
---What is the impact on retention for users coming across each of the UIs?

Comment 48

[Joe Hildebrand [:jhildebrand] (UTC-6)]

(In reply to Romain Testard [:RT] from comment #47)
> Are we not missing the most frequent scenario that is "a previous instance
> was detected and the profile we attempted to use was NOT signed in to sync"?
> Options would be "Cancel and launch newer version" (default) and "Launch
> profile manager"

"Cancel and launch newer version" doesn't always work.  I'm ok with having a third button in the unlikely event that the newer version still exists on their machine and that we can find it.

Comment 49

[Dave Townsend [:mossop]]

(In reply to Romain Testard [:RT] from comment #47)
> Alex, can you please help clarify the share of our users on desktop who are
> signed into Sync? My understanding is that this share is marginal. This
> would imply that the majority of our users will see 
> > > attachment 8976004 [details]
> 
> Are we not missing the most frequent scenario that is "a previous instance
> was detected and the profile we attempted to use was NOT signed in to sync"?
> Options would be "Cancel and launch newer version" (default) and "Launch
> profile manager"

Yeah, this is supported now, I just didn't do a screenshot of it.

> I agree that "Launch profile manager" is not ideal as a fall-back given it's
> not very user friendly though it sounds better than what we currently offer
> to users. Given ESR/release switching is what drives most downgrades, we
> have until the next ESR to get this message right for most switching
> scenarios and telemetry is probably critical, here is what I think is
> valuable to collect along with this implementation:
> ---What percentage of startups see each variation of the UI?
> ---What is the version/channel distribution of users who see each variation
> of the UI?
> ---What percentage of displays result in a click on each of the 2 options
> offered?
> ---What is the impact on retention for users coming across each of the UIs?

I'll get working on telemetry next.

Comment 50

[Dave Townsend [:mossop]]

Bram, the UI currently has a window-level close button. At the moment it launches the profile manager but that doesn't seem right to me. Should it just cancel launching anything?

Comment 51

[Joe Hildebrand [:jhildebrand] (UTC-6)]

(In reply to Romain Testard [:RT] from comment #47)
> Given ESR/release switching is what drives most downgrades, we
> have until the next ESR to get this message right for most switching
> scenarios and telemetry is probably critical, here is what I think is
> valuable to collect along with this implementation:
> ---What percentage of startups see each variation of the UI?
> ---What is the version/channel distribution of users who see each variation
> of the UI?
> ---What percentage of displays result in a click on each of the 2 options
> offered?
> ---What is the impact on retention for users coming across each of the UIs?

Some of the telemetry might be more difficult than others (since we won't finish starting up the bad version, and we can't count on the good version having hooks to report any hints we leave behind).  Can we look at gathering the easy stuff first, so we have a shot of getting this landed more quickly?

Comment 52

[Bram Pitoyo [:bram]]

(In reply to Dave Townsend [:mossop] from comment #50)
> Bram, the UI currently has a window-level close button. At the moment it
> launches the profile manager but that doesn't seem right to me. Should it
> just cancel launching anything?

Yes. The window-level close button should close everything. It shouldn’t launch the profile manager or the newer version of Firefox.

Comment 53

[Romain Testard [:RT]]

(In reply to Joe Hildebrand  [:hildjj] (UTC-6) from comment #51)
> (In reply to Romain Testard [:RT] from comment #47)
> > Given ESR/release switching is what drives most downgrades, we
> > have until the next ESR to get this message right for most switching
> > scenarios and telemetry is probably critical, here is what I think is
> > valuable to collect along with this implementation:
> > ---What percentage of startups see each variation of the UI?
> > ---What is the version/channel distribution of users who see each variation
> > of the UI?
> > ---What percentage of displays result in a click on each of the 2 options
> > offered?
> > ---What is the impact on retention for users coming across each of the UIs?
> 
> Some of the telemetry might be more difficult than others (since we won't
> finish starting up the bad version, and we can't count on the good version
> having hooks to report any hints we leave behind).  Can we look at gathering
> the easy stuff first, so we have a shot of getting this landed more quickly?

Sure, that makes sense.
I summarized where I think we are now in the user story field. Dave, do you have all you need?
Please clarify if this would make it to 62 or 63 and I'll follow-up with EPM for tracking and PI for testing accordingly.
Bram, is the copy I summarized in the US field final?

Comment 54

[Dave Townsend [:mossop]]

I have what I need and would expect to be able to get this landed for 62 assuming QA has the ability to sign-off for that version. Going to talk to the telemetry folks to understand what is straightforward to collect first.

One addition to the story: After opening a new profile from the profile manager we can show the sync preferences if that is desirable.

Comment 55

[Romain Testard [:RT]]

(In reply to Dave Townsend [:mossop] from comment #54)
> I have what I need and would expect to be able to get this landed for 62
> assuming QA has the ability to sign-off for that version. 

I'll send a PI request and get this on the program management Trello board for 62 since it's best to get it early on their radar even if they cannot start testing now.
Going to talk to
> the telemetry folks to understand what is straightforward to collect first.
> 
> One addition to the story: After opening a new profile from the profile
> manager we can show the sync preferences if that is desirable.
I like the idea of making it easier to sign into Sync for scenarios 2 and 4 of the user story.
How about using the current firstrunpage (new profiles currently open https://mozilla.org/firefox/60.0.1/firstrun) that is a more user friendly way to get users to sign into sync?

Comment 56

[Dave Townsend [:mossop]]

> ---What is the version/channel distribution of users who see each variation of the UI?

Is this the version/channel of the Firefox they are attempting to launch? That is easy. Getting the version/channel that previously ran the profile is very difficult and impossible in the case that it has been uninstalled/overwritten.

Comment 57

[Romain Testard [:RT]]

(In reply to Dave Townsend [:mossop] from comment #56)
> > ---What is the version/channel distribution of users who see each variation of the UI?
> 
> Is this the version/channel of the Firefox they are attempting to launch?
> That is easy. Getting the version/channel that previously ran the profile is
> very difficult and impossible in the case that it has been
> uninstalled/overwritten.

I was mostly thinking about the version/channel of the Firefox they are attempting to launch to categorize ESR users (likely switching from release, likely an enterprise user) VS Release users (likely switching from a pre-release build, likely someone who'd find it easier to use the profile manager) to understand if behaviors are different based on why you switch versions.

If collecting the newer version/channel as well is possible in the scenario where it was not uninstalled/overwritten it sounds like it could give us further insights and your comment also makes me think that quantifying the scenario where the newer build was uninstalled/overwritten would be valuable (technical issue troubleshooting).

How about changing this to:
---What is the version/channel distribution of the Firefox being launched for each variation of the UI?
---What is the version/channel distribution of the Firefox that previously ran the profile (version and channel being marked as null in case it was uninstalled/overwritten) for each variation of the UI?

Comment 58

[Dave Townsend [:mossop]]

(In reply to Romain Testard [:RT] from comment #57)
> (In reply to Dave Townsend [:mossop] from comment #56)
> > > ---What is the version/channel distribution of users who see each variation of the UI?
> > 
> > Is this the version/channel of the Firefox they are attempting to launch?
> > That is easy. Getting the version/channel that previously ran the profile is
> > very difficult and impossible in the case that it has been
> > uninstalled/overwritten.
> 
> I was mostly thinking about the version/channel of the Firefox they are
> attempting to launch to categorize ESR users (likely switching from release,
> likely an enterprise user) VS Release users (likely switching from a
> pre-release build, likely someone who'd find it easier to use the profile
> manager) to understand if behaviors are different based on why you switch
> versions.
> 
> If collecting the newer version/channel as well is possible in the scenario
> where it was not uninstalled/overwritten it sounds like it could give us
> further insights and your comment also makes me think that quantifying the
> scenario where the newer build was uninstalled/overwritten would be valuable
> (technical issue troubleshooting).
> 
> How about changing this to:
> ---What is the version/channel distribution of the Firefox being launched
> for each variation of the UI?
> ---What is the version/channel distribution of the Firefox that previously
> ran the profile (version and channel being marked as null in case it was
> uninstalled/overwritten) for each variation of the UI?

I can get the version string easily enough, the channel is very difficult so I'm going to put together the patch without that for now. We can often infer the channel from the version number.

Comment 59

[Dave Townsend [:mossop]]

Attachment: Bug 1455707: Remove CanShowProfileManager().

Review commit: https://reviewboard.mozilla.org/r/245550/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/245550/

Comment 60

[Dave Townsend [:mossop]]

Comment on attachment 8969760 [details]
Bug 1455707: Add UI allowing the user to choose what to do when a downgrade is detected.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/238568/diff/2-3/

Comment 61

[Dave Townsend [:mossop]]

Attachment: Bug 1455707: Detect when running an older version than previously ran with the selected profile.

Use the information in compatibility.ini to detect that the current running
application is an older version than previously ran with the profile and in
that cause open a UI allowing the user to launch the profile manager, launch
the previous instance of the application or quit.

Review commit: https://reviewboard.mozilla.org/r/245776/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/245776/

Comment 62

[Dave Townsend [:mossop]]

Comment on attachment 8969760 [details]
Bug 1455707: Add UI allowing the user to choose what to do when a downgrade is detected.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/238568/diff/3-4/

Comment 63

[:Gijs (he/him)]

Comment on attachment 8969760 [details]
Bug 1455707: Add UI allowing the user to choose what to do when a downgrade is detected.

https://reviewboard.mozilla.org/r/238568/#review252084

Clearing review because I think it'd be easier if we could just use the prompt service. Does that not work? If it did, all the logic could be in one place (the C++) and we wouldn't need custom styling and a bunch of MOZ_BUILD_APP goop to make all the pieces fit together - I didn't see a note in the bug when skimming through it to indicate you'd tried this and it didn't work for some reason; apologies if I missed it...

In case we do need to stick with this approach, some review comments follow...

::: toolkit/profile/content/profileDowngrade.js:5
(Diff revision 4)
> +/* This Source Code Form is subject to the terms of the Mozilla Public
> + * License, v. 2.0. If a copy of the MPL was not distributed with this
> + * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
> +
> +let params;

Nit: prefix to indicate this is a global (gParams?) please.

::: toolkit/profile/content/profileDowngrade.js:8
(Diff revision 4)
> +  params = window.arguments[0].QueryInterface(Ci.nsIDialogParamBlock);
> +  let hasSync = params.GetInt(0) == 1;
> +  let hasBinary = params.GetInt(1) == 1;

While it's obvious to me reading the rest of the commits on this bug, for posterity it's probably a good idea to add a few lines of comment here indicating what's going on. The C++ code passes an nsIDialogParamBlock, the first 2 values contain input and the third is used as output by this dialog to tell compiled code what to do when the dialog closes.

::: toolkit/profile/content/profileDowngrade.js:17
(Diff revision 4)
> +  // By default cancel if the user clicks the window close button
> +  params.SetInt(2, 0);
> +
> +  let button = document.getElementById(hasBinary ? "launchLast" : "cancel");
> +  button.hidden = false;
> +  button.setAttribute("default", "true");

Not being in a position to try this out myself, I'm a little concerned about how this works with keyboard access. Convention is that [return] accepts the default action on the dialog on macOS, and on all other platforms activates the focused button (I think), whereas [esc] should "cancel" the dialog on all platforms.

So making a cancel button the default may be confusing... and I don't see any handling for [esc] (or [return]).

Thinking about this more generally, is it not possible to use the prompt service this early in startup, or something? Its `confirmEx` helper should allow you to pick arbitrary strings for the buttons and pass a message, and would probably make things more straightforward in that you wouldn't need custom styling or manual passing of results...

::: toolkit/profile/content/profileDowngrade.xul:20
(Diff revision 4)
> +<!ENTITY % profileDTD SYSTEM "chrome://mozapps/locale/profile/profileDowngrade.dtd">
> +%profileDTD;
> +]>
> +
> +<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
> +        title="&window.title;" onload="init()" style="&window.style;">

Can we avoid the localized-width hack in this case, and use `sizeToContent()` instead?

::: toolkit/themes/shared/profileDowngrade.css:6
(Diff revision 4)
> +/* This Source Code Form is subject to the terms of the Mozilla Public
> + * License, v. 2.0. If a copy of the MPL was not distributed with this
> + * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
> +
> +window {
> +  padding: 14px;

Should this be in em?

::: toolkit/themes/shared/profileDowngrade.css:7
(Diff revision 4)
> + * License, v. 2.0. If a copy of the MPL was not distributed with this
> + * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
> +
> +window {
> +  padding: 14px;
> +  font: menu;

This is an interesting choice for what I assume just needs to be body text for the window. I think we generally use message-box for text, and sometimes (e.g. https://dxr.mozilla.org/mozilla-central/source/toolkit/themes/windows/global/dialog.css#23 ) menu for buttons (!?). Could we avoid this bit of styling by using <dialog> instead of <window> (which might simplify some other stuff anyway)?

Comment 64

[Nathan Froyd [:froydnj]]

Comment on attachment 8979391 [details]
Bug 1455707: Remove CanShowProfileManager().

https://reviewboard.mozilla.org/r/245550/#review252180

Makes sense.

Comment 65

[Dave Townsend [:mossop]]

Comment on attachment 8969760 [details]
Bug 1455707: Add UI allowing the user to choose what to do when a downgrade is detected.

https://reviewboard.mozilla.org/r/238568/#review252084

> Can we avoid the localized-width hack in this case, and use `sizeToContent()` instead?

This makes the window as wide as the widest string which won't look good in localized builds. the size is to force wrapping.

Comment 66

[Dave Townsend [:mossop]]

Comment on attachment 8969760 [details]
Bug 1455707: Add UI allowing the user to choose what to do when a downgrade is detected.

https://reviewboard.mozilla.org/r/238568/#review252084

We discussed this on IRC, the prompt service doesn't give the sorts of layout options we need here so we're going to clean this up and land with a follow-up to maybe make this easier with the common dialog stuff.

Comment 67

[Dave Townsend [:mossop]]

Comment on attachment 8969760 [details]
Bug 1455707: Add UI allowing the user to choose what to do when a downgrade is detected.

https://reviewboard.mozilla.org/r/238568/#review252084

> Not being in a position to try this out myself, I'm a little concerned about how this works with keyboard access. Convention is that [return] accepts the default action on the dialog on macOS, and on all other platforms activates the focused button (I think), whereas [esc] should "cancel" the dialog on all platforms.
> 
> So making a cancel button the default may be confusing... and I don't see any handling for [esc] (or [return]).
> 
> Thinking about this more generally, is it not possible to use the prompt service this early in startup, or something? Its `confirmEx` helper should allow you to pick arbitrary strings for the buttons and pass a message, and would probably make things more straightforward in that you wouldn't need custom styling or manual passing of results...

I've switched to using a <dialog> which I think solves this.

Comment 68

[Dave Townsend [:mossop]]

Attachment: no-sync binary.png

Comment 69

[Dave Townsend [:mossop]]

Attachment: no-sync no-binary.png

Comment 70

[Dave Townsend [:mossop]]

Attachment: sync binary.png

Comment 71

[Dave Townsend [:mossop]]

Attachment: sync no-binary.png

Comment 72

[Dave Townsend [:mossop]]

Comment on attachment 8979391 [details]
Bug 1455707: Remove CanShowProfileManager().

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/245550/diff/1-2/

Comment 73

[Dave Townsend [:mossop]]

Comment on attachment 8979639 [details]
Bug 1455707: Detect when running an older version than previously ran with the selected profile.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/245776/diff/1-2/

Comment 74

[Dave Townsend [:mossop]]

Comment on attachment 8969760 [details]
Bug 1455707: Add UI allowing the user to choose what to do when a downgrade is detected.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/238568/diff/4-5/

Comment 75

[:Gijs (he/him)]

Comment on attachment 8969760 [details]
Bug 1455707: Add UI allowing the user to choose what to do when a downgrade is detected.

https://reviewboard.mozilla.org/r/238568/#review252282

LGTM, thanks!

::: toolkit/locales/en-US/chrome/mozapps/profile/profileDowngrade.dtd:6
(Diff revision 5)
> +<!-- This Source Code Form is subject to the terms of the Mozilla Public
> +   - License, v. 2.0. If a copy of the MPL was not distributed with this
> +   - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
> +
> +<!ENTITY window.title "You’ve launched an older version of &brandShortName;">
> +<!ENTITY window.style "width: 40em;">

Nit: this should have an l10n comment, I guess.

Comment 76

[Alex Davis [:adavis]]

Romain, 

Here are the desktop Sync/FxA MAU:
https://analytics.amplitude.com/org/31251/chart/4lb6o01

It's a non-trivial proportion of desktop users.

Note that these are very active users too and you can see it by looking at WAU which is very similar to MAU:
https://analytics.amplitude.com/org/31251/chart/4lb6o01/edit/ajwzfgm

Comment 77

[Dave Townsend [:mossop]]

Comment on attachment 8979391 [details]
Bug 1455707: Remove CanShowProfileManager().

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/245550/diff/2-3/

Comment 78

[Dave Townsend [:mossop]]

Comment on attachment 8979639 [details]
Bug 1455707: Detect when running an older version than previously ran with the selected profile.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/245776/diff/2-3/

Comment 79

[Dave Townsend [:mossop]]

Comment on attachment 8969760 [details]
Bug 1455707: Add UI allowing the user to choose what to do when a downgrade is detected.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/238568/diff/5-6/

Comment 80

[Bram Pitoyo [:bram]]

(In reply to Romain Testard [:RT] from comment #53)
> Bram, is the copy I summarized in the US field final?

I have checked out attachment 8980016 [details], attachment 8980017 [details], attachment 8980018 [details] and attachment 8980019 [details].

There are only two very small amendments:

1. There’s a comma in the middle of the first sentence.

> To avoid problem accessing your bookmarks and history, you must choose a different profile.

2. The button captions should be capitalised: [Launch Profile Manager], [Exit and Launch Newer Version].

That’s all!

Comment 81

[Romain Testard [:RT]]

(In reply to Alex Davis [:adavis] [PM FxA+Sync] from comment #76)
> Romain, 
> 
> Here are the desktop Sync/FxA MAU:
> https://analytics.amplitude.com/org/31251/chart/4lb6o01
> 
> It's a non-trivial proportion of desktop users.
> 
> Note that these are very active users too and you can see it by looking at
> WAU which is very similar to MAU:
> https://analytics.amplitude.com/org/31251/chart/4lb6o01/edit/ajwzfgm
Thanks Alex, I agree, definitely a use case worth supporting. We're covered here per the description in the user story where users who were signed into sync are told to sign-in again to FxA to restore bookmarks and browsing history.

Comment 82

[Alex Davis [:adavis]]

Markh: any objections or flags here around the instructions given to Sync users?

While I'm not fond of the flow, it is better than nothing and is prob an edge case experienced by power users going back and forth with Nightly, Dev Edition and Release.

Comment 83

[Mark Hammond [:markh] [:mhammond]]

(In reply to Alex Davis [:adavis] [PM FxA+Sync] from comment #82)
> Markh: any objections or flags here around the instructions given to Sync
> users?

As a grammar nit, attachment 8980018 [details] says "sign into Firefox Account" - it seems as though it should say "sign in with a Firefox Account". There's also no real need to say "and perform a sync" as that happens automatically after signing in.

So maybe something like "Afterwards, sign in with a Firefox Account to sync your bookmarks and browsing history between these profiles" is better?

Also, the wording also doesn't make it particularly clear that they need to sign in to their account on *both* the old profile and any new profiles they create, but that's going to be tricky to convey in this kind of dialog.

> While I'm not fond of the flow, it is better than nothing and is prob an
> edge case experienced by power users going back and forth with Nightly, Dev
> Edition and Release.

Yeah - all in all, this seems like significantly worse UX than bug 1373244 would offer, but I'm sure that's not news to anyone. Apart from nits over the wording, I see no engineering issues with having this operate as described.

Comment 84

[Nathan Froyd [:froydnj]]

Comment on attachment 8979639 [details]
Bug 1455707: Detect when running an older version than previously ran with the selected profile.

https://reviewboard.mozilla.org/r/245776/#review252186

I guess this all works, even if this is some gnarly code.  I don't suppose there's any way that some of this (new) code can be refactored so we could add some gtests on it?  The logic in `CheckCompatibility`, at least; `CheckDowngrade` is a little harder to test.

::: commit-message-2126f:5
(Diff revision 3)
> +Bug 1455707: Detect when running an older version than previously ran with the selected profile. r?froydnj
> +
> +Use the information in compatibility.ini to detect that the current running
> +application is an older version than previously ran with the profile and in
> +that cause open a UI allowing the user to launch the profile manager, launch

Nit: "that case".

::: toolkit/xre/nsAppRunner.cpp:1587
(Diff revision 3)
>           "  --no-remote        Do not accept or send remote commands; implies\n"
>           "                     --new-instance.\n"
>           "  --new-instance     Open new instance, not a new window in running instance.\n"
>           "  --UILocale <locale> Start with <locale> resources as UI Locale.\n"
>           "  --safe-mode        Disables extensions and themes for this session.\n"
> +         "  --allow-downgrade  Allows downgrading a profile.\n"

Do we want this option to be available at all?  My impression is that things like indexedDB can break horribly in downgrade scenarios.

::: toolkit/xre/nsAppRunner.cpp:2731
(Diff revision 3)
>   * Checks the compatibility.ini file to see if we have updated our application
>   * or otherwise invalidated our caches. If the application has been updated,
>   * we return false; otherwise, we return true. We also write the status
>   * of the caches (valid/invalid) into the return param aCachesOK. The aCachesOK
>   * is always invalid if the application has been updated.

Perhaps we should update this comment for the new outparams?

Comment 85

[Dave Townsend [:mossop]]

(In reply to Nathan Froyd [:froydnj] from comment #84)
> Comment on attachment 8979639 [details]
> ::: toolkit/xre/nsAppRunner.cpp:1587
> (Diff revision 3)
> >           "  --no-remote        Do not accept or send remote commands; implies\n"
> >           "                     --new-instance.\n"
> >           "  --new-instance     Open new instance, not a new window in running instance.\n"
> >           "  --UILocale <locale> Start with <locale> resources as UI Locale.\n"
> >           "  --safe-mode        Disables extensions and themes for this session.\n"
> > +         "  --allow-downgrade  Allows downgrading a profile.\n"
> 
> Do we want this option to be available at all?  My impression is that things
> like indexedDB can break horribly in downgrade scenarios.

I think so? It will allow tools like mozregression to easily handle this. Without it it is still possible to bypass the checks by just deleting compatibility.ini from the profile folder.

Comment 86

[Dave Townsend [:mossop]]

Comment on attachment 8979639 [details]
Bug 1455707: Detect when running an older version than previously ran with the selected profile.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/245776/diff/3-4/

Comment 87

[Dave Townsend [:mossop]]

Comment on attachment 8969760 [details]
Bug 1455707: Add UI allowing the user to choose what to do when a downgrade is detected.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/238568/diff/6-7/

Comment 88

[Liz Henry (:lizzard) (relman/hg->git project)]

Marking this affected for 63 and tracking since we may ship this in 63.

Comment 89

[Pascal Chevrel:pascalc]

This is now planned for 64

Comment 90

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c667f8f40c65
Remove CanShowProfileManager(). r=froydnj

Comment 91

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/c667f8f40c65

Comment 92

[:Gijs (he/him)]

Should this have been left open?

Comment 93

[Dave Townsend [:mossop]]

Yes!

Comment 94

[Dave Townsend [:mossop]]

Attachment: Bug 1455707: Detect when running an older version than previously ran with the selected profile. r=froydnj

Use the information in compatibility.ini to detect that the current running
application is an older version than previously ran with the profile and in
that case open a UI allowing the user to launch the profile manager, launch
the previous instance of the application or quit.

MozReview-Commit-ID: F7rwlvXiOfN

Comment 95

[Dave Townsend [:mossop]]

Attachment: Bug 1455707: Add UI allowing the user to choose what to do when a downgrade is detected. r=Gijs

Allows the user to choose whether to open the profile manager, launch the last
instance of the application or quit.

MozReview-Commit-ID: L9DJQ3WZwhy

Comment 96

[Worcester12345]

Perhaps it is time to revisit this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1493008

Comment 97

[Dave Townsend [:mossop]]

Michael, can you answer this question?

https://phabricator.services.mozilla.com/D6547#inline-88001

Comment 98

[Bram Pitoyo [:bram]]

(In reply to Dave Townsend [:mossop] (he/him) from comment #97)

Michael, can you answer this question?

https://phabricator.services.mozilla.com/D6547#inline-88001

Hi mossop, I offer a perspective that may or may not provide the info you’ve requested from verdi.

On phabricator, flod wrote:

Scenario: the default profile is assigned to release, I try to start it with Nightly. This dialog would say "You've launched an older version of Nightly`, and I'm not sure that's what we want.

In this particular scenario, I think that we want to say something along the lines of “This profile may only be launched with Firefox. Quit and relaunch Nightly to continue using it with a fresh new profile.”

What do you think?

Comment 99

[Francesco Lodolo [:flod]]

To clarify, my question was about hardcoding some of the Firefox, to always show that independently from the version you're running. The strings are clear to me.

This profile may only be launched with Firefox. Quit and relaunch Nightly to continue using it with a fresh new profile.

This would be confusing. Beta and Release are both "Firefox", what's Firefox in such a message?

Comment 100

[Albert Scheiner [:alberts]]

Even as a Nightly user I find "This profile may only be launched with Firefox." somewhat confusing, also the second sentence hints regarding the differentiation. Just my 2 cents.

Comment 101

[Bram Pitoyo [:bram]]

(In reply to Francesco Lodolo [:flod] from comment #99)

To clarify, my question was about hardcoding some of the Firefox, to always show that independently from the version you're running. The strings are clear to me.

Would hardcoding some of the Firefox mean that we’ll refer to the product as “Firefox Nightly”, “Firefox Beta”, etc.?

If yes, then it will make the string clearer. As you wrote, a product called “Nightly” may only be familiar to the most technical users, and a product called “Beta” can refer to just about any app. Calling it “Firefox Nightly” or “Firefox Beta” will clarify what specific app is being impacted.

Sorry about the confusion from the string rewrite. I don’t think we need to do it.

Comment 102

[Francesco Lodolo [:flod]]

(In reply to Bram Pitoyo [:bram] from comment #101)

(In reply to Francesco Lodolo [:flod] from comment #99)

To clarify, my question was about hardcoding some of the Firefox, to always show that independently from the version you're running. The strings are clear to me.

Would hardcoding some of the Firefox mean that we’ll refer to the product as “Firefox Nightly”, “Firefox Beta”, etc.?

No, that would require an insane amount of duplication. What I'm saying is that we should consider to talk about just "Firefox" in some cases, independently from the version.

"You've launched an older version of Firefox" applies to all versions of Firefox without space for confusion.

Another string:

"Using an older version of &brandShortName; can corrupt bookmarks and browsing history already saved to an existing &brandShortName; profile. To protect your information, create a new profile for this installation of &brandShortName;."

I think the first 2 instances could just be "Firefox", and leave the brand name on the last. On Dev Edition that would read:

"Using an older version of Firefox can corrupt bookmarks and browsing history already saved to an existing Firefox profile. To protect your information, create a new profile for this installation of Firefox Developer Edition."

Comment 103

[Bram Pitoyo [:bram]]

(In reply to Francesco Lodolo [:flod] from comment #102)

What I'm saying is that we should consider to talk about just "Firefox" in some cases, independently from the version.

"You've launched an older version of Firefox" applies to all versions of Firefox without space for confusion.

This makes a lot of sense to me.

In other words, we refer to the current application as &brandShortName; and all other versions of the app (which is almost always going to be older versions) as “Firefox”.

Comment 104

[Dave Townsend [:mossop]]

Attachment: Screenshot

Michael, during review we identified a couple of things that needed fixing but fixing them mean moving the buttons around a bit on OSX/Linux. Does this look ok or do you want them all pushed to the right?

Comment 105

[Verdi [:verdi] Best to slack me]

(In reply to Dave Townsend [:mossop] (he/him) from comment #104)

Does this look ok or do you want them all pushed to the right?

Pushed to the right please.

Comment 106

[Verdi [:verdi] Best to slack me]

(In reply to Francesco Lodolo [:flod] from comment #102)

I think the first 2 instances could just be "Firefox", and leave the brand name on the last. On Dev Edition that would read:> > "Using an older version of Firefox can corrupt bookmarks and browsing history already saved to an existing Firefox profile. To > protect your information, create a new profile for this installation of Firefox Developer Edition."

Yes, I agree. Sorry for the confusion. Should look like this:

You’ve launched an older version of Firefox

Using an older version of Firefox can corrupt bookmarks and browsing history already saved to an existing Firefox profile. To protect your information, create a new profile for this installation of &brandShortName;.

Exit (Windows), Quit (Mac) [default action]Create New Profile

Comment 107

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/21a801ca5f6d
Detect when running an older version than previously ran with the selected profile. r=froydnj, r=mconley, r=Gijs

Comment 108

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/82355ab7e063
Fix rebase breakage. r=bustage CLOSED TREE

Comment 109

[Cristina Coroiu [:ccoroiu]]

Backed out 7 changesets (bug 1518632, bug 1463198, bug 1455707, bug 1522934, bug 1322797, bug 1474285) for build bustages at /builds/worker/workspace/build/src/toolkit/xre/nsAppRunner.cpp

Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/b4d8ca47f938b88f66f2f8fa566108e6d636ac1c

Failure push: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=b965981c9ce0449a8d70df6ad47ebf6c4f1f70b9

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=225113702&repo=mozilla-inbound&lineNumber=36111

[task 2019-01-31T01:04:12.272Z] 01:04:12 INFO - make[4]: Entering directory '/builds/worker/workspace/build/src/obj-firefox/toolkit/mozapps/update/updater/updater-dep'
[task 2019-01-31T01:04:12.272Z] 01:04:12 INFO - /builds/worker/workspace/build/src/sccache2/sccache /builds/worker/workspace/build/src/clang/bin/clang++ -o ../../../../../_tests/updater-dep/updater-dep -Qunused-arguments -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -Qunused-arguments -Wall -Wbitfield-enum-conversion -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wshadow-field-in-constructor-modified -Wsign-compare -Wtype-limits -Wunreachable-code -Wunreachable-code-return -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wloop-analysis -Wc++1z-compat -Wc++2a-compat -Wcomma -Wimplicit-fallthrough -Werror=non-literal-null-conversion -Wstring-conversion -Wtautological-overlap-compare -Wtautological-unsigned-enum-zero-compare -Wtautological-unsigned-zero-compare -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=return-std-move -Wno-error=atomic-alignment -Wformat -Wformat-security -Wno-gnu-zero-variadic-macro-arguments -Wno-unknown-warning-option -Wno-return-type-c-linkage -D_GLIBCXX_USE_CXX11_ABI=0 -fno-sized-deallocation -fcrash-diagnostics-dir=/builds/worker/artifacts -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -Xclang -load -Xclang /builds/worker/workspace/build/src/obj-firefox/build/clang-plugin/libclang-plugin.so -Xclang -add-plugin -Xclang moz-check -Os -fno-omit-frame-pointer -funwind-tables -Werror /builds/worker/workspace/build/src/obj-firefox/toolkit/mozapps/update/updater/updater-dep/updater-dep.list -lpthread -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc -Wl,-Bsymbolic-functions -Wl,--build-id=sha1 -Wl,-rpath-link,/builds/worker/workspace/build/src/obj-firefox/dist/bin -Wl,-rpath-link,/usr/local/lib -pie ../../../../../security/nss/lib/nss/nss_nss3/libnss3.so ../../../../../security/nss/lib/util/util_nssutil3/libnssutil3.so ../../../../../security/nss/lib/smime/smime_smime3/libsmime3.so ../../../../../config/external/sqlite/libmozsqlite3.so ../../../../../security/nss/lib/ssl/ssl_ssl3/libssl3.so -ldl -Wl,--version-script,/builds/worker/workspace/build/src/build/unix/stdc++compat/hide_std.ld -L/builds/worker/workspace/build/src/obj-firefox/dist/bin -lnspr4 -lplc4 -lplds4 -lgtk-3 -lgdk-3 -latk-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo -lgio-2.0 -lgobject-2.0 -lglib-2.0
[task 2019-01-31T01:04:12.273Z] 01:04:12 INFO - make[4]: Leaving directory '/builds/worker/workspace/build/src/obj-firefox/toolkit/mozapps/update/updater/updater-dep'
[task 2019-01-31T01:04:12.283Z] 01:04:12 INFO - make[4]: Entering directory '/builds/worker/workspace/build/src/obj-firefox/toolkit/xre'
[task 2019-01-31T01:04:12.288Z] 01:04:12 INFO - /builds/worker/workspace/build/src/sccache2/sccache /builds/worker/workspace/build/src/clang/bin/clang++ -o nsAppRunner.o -c -I/builds/worker/workspace/build/src/obj-firefox/dist/stl_wrappers -I/builds/worker/workspace/build/src/obj-firefox/dist/system_wrappers -include /builds/worker/workspace/build/src/config/gcc_hidden.h -DDEBUG=1 -DTELEMETRY_PING_FORMAT_VERSION=4 -DPROXY_PRINTING=1 -DOS_POSIX=1 -DOS_LINUX=1 -DUSE_GLX_TEST '-DMOZ_APP_NAME="firefox"' '-DMOZ_APP_BASENAME="Firefox"' '-DMOZ_APP_DISPLAYNAME="Firefox Nightly"' '-DMOZ_APP_VENDOR="Mozilla"' '-DMOZ_APP_VERSION="67.0a1"' '-DOS_TARGET="Linux"' '-DMOZ_WIDGET_TOOLKIT="gtk3"' -DMOZ_UPDATER '-DTARGET_OS_ABI="Linux_x86_64-gcc3"' -DGRE_MILESTONE=67.0a1 -DMOZ_APP_VERSION_DISPLAY=67.0a1 -DAPP_VERSION=67.0a1 '-DAPP_ID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}' -DMOZ_BUILD_APP_IS_BROWSER -DTOPOBJDIR=/builds/worker/workspace/build/src/obj-firefox -DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -I/builds/worker/workspace/build/src/toolkit/xre -I/builds/worker/workspace/build/src/obj-firefox/toolkit/xre -I/builds/worker/workspace/build/src/toolkit/components/printingui -I/builds/worker/workspace/build/src/obj-firefox/ipc/ipdl/_ipdlheaders -I/builds/worker/workspace/build/src/ipc/chromium/src -I/builds/worker/workspace/build/src/ipc/glue -I/builds/worker/workspace/build/src/other-licenses/nsis/Contrib/CityHash/cityhash -I/builds/worker/workspace/build/src/toolkit/components/find -I/builds/worker/workspace/build/src/toolkit/components/printingui/ipc -I/builds/worker/workspace/build/src/toolkit/components/windowwatcher -I/builds/worker/workspace/build/src/toolkit/mozapps/update/common -I/builds/worker/workspace/build/src/toolkit/profile -I/builds/worker/workspace/build/src/config -I/builds/worker/workspace/build/src/dom/base -I/builds/worker/workspace/build/src/dom/commandhandler -I/builds/worker/workspace/build/src/dom/ipc -I/builds/worker/workspace/build/src/dom/webbrowserpersist -I/builds/worker/workspace/build/src/testing/gtest/mozilla -I/builds/worker/workspace/build/src/toolkit/crashreporter -I/builds/worker/workspace/build/src/xpcom/build -I/builds/worker/workspace/build/src/widget/xremoteclient -I/builds/worker/workspace/build/src/obj-firefox/dist/include -I/builds/worker/workspace/build/src/obj-firefox/dist/include/nspr -I/builds/worker/workspace/build/src/obj-firefox/dist/include/nss -fPIC -DMOZILLA_CLIENT -include /builds/worker/workspace/build/src/obj-firefox/mozilla-config.h -Qunused-arguments -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -Qunused-arguments -Wall -Wbitfield-enum-conversion -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wshadow-field-in-constructor-modified -Wsign-compare -Wtype-limits -Wunreachable-code -Wunreachable-code-return -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wloop-analysis -Wc++1z-compat -Wc++2a-compat -Wcomma -Wimplicit-fallthrough -Werror=non-literal-null-conversion -Wstring-conversion -Wtautological-overlap-compare -Wtautological-unsigned-enum-zero-compare -Wtautological-unsigned-zero-compare -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=return-std-move -Wno-error=atomic-alignment -Wformat -Wformat-security -Wno-gnu-zero-variadic-macro-arguments -Wno-unknown-warning-option -Wno-return-type-c-linkage -D_GLIBCXX_USE_CXX11_ABI=0 -fno-sized-deallocation -fcrash-diagnostics-dir=/builds/worker/artifacts -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -Xclang -load -Xclang /builds/worker/workspace/build/src/obj-firefox/build/clang-plugin/libclang-plugin.so -Xclang -add-plugin -Xclang moz-check -Os -fno-omit-frame-pointer -funwind-tables -Werror -I/builds/worker/workspace/build/src/widget/gtk/compat-gtk3 -pthread -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/include/gtk-3.0/unix-print -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng12 -Wno-error=shadow -MD -MP -MF .deps/nsAppRunner.o.pp /builds/worker/workspace/build/src/toolkit/xre/nsAppRunner.cpp
[task 2019-01-31T01:04:12.289Z] 01:04:12 ERROR - /builds/worker/workspace/build/src/toolkit/xre/nsAppRunner.cpp:2469:25: error: use of undeclared identifier 'NS_APPSTARTUP_CONTRACTID'
[task 2019-01-31T01:04:12.289Z] 01:04:12 INFO - do_GetService(NS_APPSTARTUP_CONTRACTID);
[task 2019-01-31T01:04:12.291Z] 01:04:12 INFO - ^
[task 2019-01-31T01:04:12.291Z] 01:04:12 INFO - 1 error generated.
[task 2019-01-31T01:04:12.291Z] 01:04:12 INFO - /builds/worker/workspace/build/src/config/rules.mk:1117: recipe for target 'nsAppRunner.o' failed
[task 2019-01-31T01:04:12.291Z] 01:04:12 ERROR - make[4]: *** [nsAppRunner.o] Error 1
[task 2019-01-31T01:04:12.291Z] 01:04:12 INFO - make[4]: Leaving directory '/builds/worker/workspace/build/src/obj-firefox/toolkit/xre'
[task 2019-01-31T01:04:12.292Z] 01:04:12 INFO - make[4]: *** Waiting for unfinished jobs....
[task 2019-01-31T01:04:12.327Z] 01:04:12 INFO - make[4]: Entering directory '/builds/worker/workspace/build/src/obj-firefox/security/manager/ssl/tests/unit/tlsserver/cmd'
[task 2019-01-31T01:04:12.327Z] 01:04:12 INFO - /builds/worker/workspace/build/src/obj-firefox/_virtualenvs/init/bin/python -m mozbuild.action.check_binary --target BadCertServer

Comment 110

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/250089b69337
Detect when running an older version than previously ran with the selected profile. r=froydnj, r=mconley, r=Gijs

Comment 111

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/250089b69337

Comment 113

[Pascal Chevrel:pascalc]

Dave, do we need a separate release note from the general note we have on Dedicated Profiles for this change in 67 beta and/or release?

Comment 114

[Dave Townsend [:mossop]]

(In reply to Pascal Chevrel:pascalc from comment #113)

Dave, do we need a separate release note from the general note we have on Dedicated Profiles for this change in 67 beta and/or release?

Yeah we should probably add something. I am not a wordsmith but maybe something like "Firefox will now protect you against running older versions of Firefox which can lead to data corruption and stability issues."

Comment 115

[Pascal Chevrel:pascalc]

(In reply to Dave Townsend [:mossop] (he/him) from comment #114)

(In reply to Pascal Chevrel:pascalc from comment #113)

Dave, do we need a separate release note from the general note we have on Dedicated Profiles for this change in 67 beta and/or release?

Yeah we should probably add something. I am not a wordsmith but maybe something like "Firefox will now protect you against running older versions of Firefox which can lead to data corruption and stability issues."

Better than what I would have written thanks!
Added to Nightly relnotes and our beta draft

Comment 116

[Worcester12345]

Isn't there a field to add "more control to user" as a comment? This bug should have that.

Comment 117

[Worcester12345]

(In reply to Worcester12345 from comment #116)

Isn't there a field to add "more control to user" as a comment? This bug should have that.

Key word: Papercut