1369255 - Profile clean-up option in stub installer

Status: VERIFIED FIXED

(Firefox :: Installer, enhancement, P1)

Comment 1

[Peter Dolanjski [:pdol]]

Attachment: Example UI (not final)

Attached is an example of that experience

Comment 2

[Peter Dolanjski [:pdol]]

Michael, can you include the spec once that's completed?

Sam, please work with Michael on the appropriate copy for this experience.

Comment 3

[Molly Howell (she/her) (no longer active)]

To clarify, is the intent to display this UI whenever we find an existing installation? What had been discussed with me previously was a bit different, so I want to make sure I know what's up.

Comment 4

[Verdi [:verdi] Best to slack me]

(In reply to Matt Howell [:mhowell] from comment #3)
> To clarify, is the intent to display this UI whenever we find an existing
> installation? What had been discussed with me previously was a bit
> different, so I want to make sure I know what's up.

We want to check the last active time on the profile. If it's over 60 days, then we'll want to give them this UI. This should happen whether or not there is an existing installation. Here's a flowchart https://bug1357666.bmoattachments.org/attachment.cgi?id=8862610

Comment 5

[Molly Howell (she/her) (no longer active)]

Okay, thank you. That *is* what had been discussed with me previously, then.

In that case, I have to ask again something I've been wondering about all along and never gotten an answer to: what is the reasoning behind doing this check in the installer?

I'm worried because I would be have to duplicate code that (I think) Firefox already has for determining the last time the profile was active, and since my implementation would be totally disconnected from the browser's, it would be easy to accidentally break it by changing anything about how the browser implements profiles. The installer has never had any interaction with or knowledge of profiles before, and I'm not excited about bringing in that kind of fragility, at least not without fully understanding the need for it.

The above flowchart actually shows this feature being implemented without involving the installer, which is the way of doing it that makes more sense to me.

Comment 6

[Verdi [:verdi] Best to slack me]

(In reply to Matt Howell [:mhowell] from comment #5)
> Okay, thank you. That *is* what had been discussed with me previously, then.
> 
> In that case, I have to ask again something I've been wondering about all
> along and never gotten an answer to: what is the reasoning behind doing this
> check in the installer?
> 

The reason for doing it in the installer is so that we can make this a more automatic process (the refresh happens mostly invisibly on launch) while giving people a way to opt-out of it. This also has the advantage of putting the decision close in time to the user action of installation. So the refresh is seen as modifying the installation (technically it's modifying the profile but that's not the mental model of most users).

If it happened in Firefox, we could do it one of two ways:
* The user would get a working Firefox where this decision would then compete with just trying the browser out. This is what we do now and it's not very effective.
* We add a decision point in before the Firefox window opens. This moves the decision farther away from the user action (installation) and interrupts the flow.

Comment 7

[Molly Howell (she/her) (no longer active)]

(In reply to Verdi [:verdi] from comment #6)
> If it happened in Firefox, we could do it one of two ways:
> * The user would get a working Firefox where this decision would then
> compete with just trying the browser out. This is what we do now and it's
> not very effective.

Agreed.

> * We add a decision point in before the Firefox window opens. This moves the
> decision farther away from the user action (installation) and interrupts the
> flow.

The installer automatically runs the browser immediately after the installation is done. No user actions are involved after executing the installer, and the only time difference is the browser startup time. That does not seem like a significant enough difference to make me feel better about what's going to be a pretty fragile hack.

Additionally, I'd like to point out that anything we put in the installer only happens on Windows, because other platforms do not have an installer. This is another reason why we generally avoid putting functionality in the installer beyond what's required to properly install the browser onto the system.

Comment 8

[Fischer [:Fischer]]

Hi Matt,
The bug 1054947 is addressing the FF-last-used time issue. We are going to using the lastModifiedTime of the profiles.ini under the user app data folder as the FF-last-used time. The stub installer could check out that time if it is longer than 60-days from now, then provide the profile clean-up checkbox. If user didn't uncheck(agreed to profile refresh) just invoke FF with extra args like: `C:\Program Files (x86)\Mozilla Firefox\firefox.exe -resset-profile -migration`

Comment 9

[Molly Howell (she/her) (no longer active)]

I know there are ways to get this information and convey to the browser what needs to happen, I'm not worried about that. What I am worried about is when anything in that system changes, we're depending on whoever makes that change taking a pretty high level of initiative in order for that information to make its way into the installer. Maybe someday somebody decides that removing that disk write to update the profiles.ini modified time sounds like a good performance optimization. Maybe it's something silly like one of those command-line parameters getting renamed. Any such change is going to silently break this installer feature if it isn't fixed at the same time.

All of this would be an acceptable cost to take on (surely we already have examples of poor coupling elsewhere in the code base), if it is truly necessary for the installer to present this UI instead of the browser. But I still don't see the benefit of doing that.

Comment 10

[Verdi [:verdi] Best to slack me]

(In reply to Matt Howell [:mhowell] from comment #9)
> Any such change
> is going to silently break this installer feature if it isn't fixed at the
> same time.
> 

Good to know. Would be great if that gets documented wherever such things get documented. Question - what happens if the feature silently breaks? Will it just install Firefox normally? If so, that's an acceptable failure state and one that sounds like it could be tested for by QA.


> All of this would be an acceptable cost to take on (surely we already have
> examples of poor coupling elsewhere in the code base), if it is truly
> necessary for the installer to present this UI instead of the browser. But I
> still don't see the benefit of doing that.

The benefit is that this flow will be easier for the user to understand and make a decision about. They will also get to make all of their decisions at one time - download -> run -> allow -> install with or without refresh. 

Doing it in the browser means having them install Firefox and then when they expect the browser to launch we confound that expectation and present them with a dialog asking if they want to refresh Firefox. This makes the interaction less understandable. UX and Product met about this at the Photon workweek in Toronto and agreed that presenting this option in the browser is not the experience we want to give users.

Comment 11

[David Durst [:ddurst]]

The goal of this is to have the mental model of the user conform to the idea that "profile cleanup happens during installation."

Where it happens is different from where it *appears* to happen, so I want to be clear about this. The two significant parts of this -- a) showing the additional UI to allow the user to choose to clean up their profile, b) actually cleaning up their profile.

There is still nothing I've seen that says that this needs to be *in* the installer (it needs to appear, to the user, to be during/part of installation, but even with additional UI, it doesn't need to be part of the application that is the installer). It would be far cleaner to have this as a change to the existing browser code that does this.

[Additionally, the UI (I know it's not final), implies that "Firefox has been installed before" but that has no time implications -- could be a week ago, could be a decade ago -- and it sounds like we have a very specific definition of what it should imply. If we are less specific about "install" (or just more adaptive in the language used), we could still use this (and a consistent UI, to boot) for situations like bug 1054947, without duplicating any code.]

I want to make sure we're describing the goal and not prescribing the implementation yet.

Comment 12

[Sam Barrett]

So we need to inform the user his/her profile needs to be "cleaned up" because a previous version of Firefox was installed? Is that correct?

Comment 13

[Verdi [:verdi] Best to slack me]

Attachment: Returning-User---Refresh-opt-out.png

(In reply to David Durst [:ddurst] from comment #11)
> The goal of this is to have the mental model of the user conform to the idea
> that "profile cleanup happens during installation."
> 
> Where it happens is different from where it *appears* to happen, so I want
> to be clear about this. The two significant parts of this -- a) showing the
> additional UI to allow the user to choose to clean up their profile, b)
> actually cleaning up their profile.
> 

If I understand you correctly we're in agreement. I've attached a new flowchart (from Bug 1357666) that I hope makes this clear. The idea is that the installer should do this last active time check and then conditionally display UI allowing the user to opt-out of the refresh but the installer is not doing the refresh. It just has to tell Firefox whether or not it should run the refresh on start up or not.

Comment 14

[David Durst [:ddurst]]

That flowchart explains well what you're after, but it's not what I'm saying. Maybe another way to put this is to add to what I said previously:

> Where it happens is different from where it *appears* to happen, so I want to be clear about this. The two 
> significant parts of this -- a) showing the additional UI to allow the user to choose to clean up their profile, 
> b) actually cleaning up their profile
... don't need to happen *in* the installer, but need to happen during the "installation process" for the user to feel like it's part of installation. The "installation process" includes the stub installer run and the subsequent browser startup that the stub installer initiates (basically, from when they see the stub installer until they see Firefox is the "installation process" from the user's point of view).

So the question is: if the effect to the user experience is the same, is there a reason to put this code in the stub installer instead of where it currently lives (in the browser)? This is just about what application the code is part of, not when it happens from the user's vantage point.

Since the stub installer currently knows nothing about a profile, moving or duplicating that logic into the stub installer complicates things in a variety of undesirable ways; plus, code to do most of this already exists in the browser, so it's easier to modify it there (and by "easy" I don't mean "we don't want to do the work" -- I mean less fragile, less error-prone, more straightforward to test and support, etc). So if we decide to do this, there needs to be a compelling reason.

The first startup of the browser after the stub installer runs could do both this check and the subsequent cleanup -- and more easily than trying to do it in the stub installer -- so that seems like the more optimal course of action. To the user it would still happen only as "part of" installation, even though behind the scenes the code is technically in the browser.

Comment 15

[Matthew N. [:MattN]]

I was part of the discussions about this years ago and implemented Firefox Refresh so will try to clarify…

(In reply to David Durst [:ddurst] from comment #14)
> So the question is: if the effect to the user experience is the same, is
> there a reason to put this code in the stub installer instead of where it
> currently lives (in the browser)? This is just about what application the
> code is part of, not when it happens from the user's vantage point.

I think the core of the misunderstanding is that the user experience isn't the same if we do this in Firefox for the following reasons:
a) If this question is asked by Firefox, it will have to open a dialog like attachment 8873264 [details] before choosing a Firefox profile. That means the installer dialog will have closed and then some milliseconds to seconds later Firefox starts up and shows the dialog possibly in a different position on the screen as Firefox wouldn't know where the installer window was positioned. This would seem janky to the user.

b) From user research, users think of re-installation as a repair (like the "repair" option found with many installers) and since we don't tell users about multiple profiles, they think that repairing Firefox also repairs there profile. Having the prompt to repair after the re-installation doesn't align with this mental model and also interrupts the flow of installation. With Michael's proposed flow there are questions up front in the installer and then Firefox will auto-start meaning only one series of prompts. With your proposed flow the user would have stub installer options up front, wait for the installation (which I believe can take a minute or more on some systems), and then they get prompted with a new question blocking Firefox from starting. The latter flow is a poorer user experience.

> Since the stub installer currently knows nothing about a profile, moving or
> duplicating that logic into the stub installer complicates things in a
> variety of undesirable ways; plus, code to do most of this already exists in
> the browser, so it's easier to modify it there (and by "easy" I don't mean
> "we don't want to do the work" -- I mean less fragile, less error-prone,
> more straightforward to test and support, etc). So if we decide to do this,
> there needs to be a compelling reason.

To be clear, we don't want/need to teach the stub installer about profiles, we're talking about touching the timestamp of a file outside the profiles directory which means the path will be consistent between users (profiles.ini the current proposal which is found in UAppData in Firefox).

I agree it is somewhat fragile since I don't think we have integration tests connecting the installer flow to Firefox startup but I think a comment at the timestamp touching code mentioning that the installer depends on it and adding this to release QA steps would mostly address that concern.

> The first startup of the browser after the stub installer runs could do both
> this check and the subsequent cleanup -- and more easily than trying to do
> it in the stub installer -- so that seems like the more optimal course of
> action. To the user it would still happen only as "part of" installation,
> even though behind the scenes the code is technically in the browser.

Sure, it may be somewhat easier to implement in Firefox but this is part of a project to smooth the onboarding experience (for new and returning users) and (a) and (b) above provide a less ideal UX.

Comment 16

[Romain Testard [:RT]]

> > The first startup of the browser after the stub installer runs could do both
> > this check and the subsequent cleanup -- and more easily than trying to do
> > it in the stub installer -- so that seems like the more optimal course of
> > action. To the user it would still happen only as "part of" installation,
> > even though behind the scenes the code is technically in the browser.
> 
> Sure, it may be somewhat easier to implement in Firefox but this is part of
> a project to smooth the onboarding experience (for new and returning users)
> and (a) and (b) above provide a less ideal UX.

My fear is that it will be hard for users to understand what "Refresh Firefox" is (or whatever other string we can come-up with) at a time where we don't want users to be confused/cancel the installation.
How about running the profile clean-up by default for eligible installs at Firefox start-up and provide a way for users to "undo"? (See attachment).
This would provide a non install blocking experience and a way out for the users who have reasons not to want this.
To put things in context, 40% of installs are re-installs (profile directory exists) and 8% of installs are done where the same Firefox version is already installed (likely that users are trying to fix something).

Comment 17

[Romain Testard [:RT]]

Attachment: Proposal consisting in running profile clean-up for all eligible users automatically

Proposal consisting in running profile clean-up for all eligible users automatically (i.e no stub installer changes)

Comment 18

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Interesting proposal. We would need PM/UX to weight in here.

Comment 19

[Peter Dolanjski [:pdol]]

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #18)
> Interesting proposal. We would need PM/UX to weight in here.

Technically, is @RT's proposal possible?  I'll let @verdi weigh in on UX, but it might be a good way to do this.

Comment 20

[Benjamin Smedberg]

Concerns that pdol asked me to put into this bug:
* timestamps are hard and users clock-skew a lot more than we think: we should probably make sure that a person who uses the browser regularly but has a messed up clock once doesn't get reset
* I'd encourage you to be cautious and measure this carefully so that we know exactly how often it's happening and monitor that it's not happening to active users.
* If this bug is intended to be a replacement for bug 1351616 it would be good to close that one. Otherwise the same comments apply to that bug *and* we need to figure out how the installer-based feature and the app-based feature interact.

Comment 21

[David Durst [:ddurst]]

I would also like to not lose track of bug 750979, though it's not quite the same (though related).

Comment 22

[Verdi [:verdi] Best to slack me]

The way we'd always planned on doing this was to do the refresh automatically but we were only comfortable doing that if we could migrate add-ons but make them disabled (Bug 1017919). Since that's not possible in the 57 time frame and we're getting much of the benefit from the loss of legacy add-ons we decided to go with an opt-out version.

(In reply to Romain Testard [:RT] from comment #16)
> My fear is that it will be hard for users to understand what "Refresh
> Firefox" is (or whatever other string we can come-up with) at a time where
> we don't want users to be confused/cancel the installation.

I'm not so concerned about that as the user will have a simple way to opt-out at install time (just uncheck the box). 

> How about running the profile clean-up by default for eligible installs at
> Firefox start-up and provide a way for users to "undo"? (See attachment).

The undo idea is interesting but just making the feature less destructive would be better. Then it won't require as much explanation (or any) or something like an undo. I could be wrong but it seems to me that building an undo feature in the 57 time frame might not even be feasible.

> This would provide a non install blocking experience and a way out for the
> users who have reasons not to want this.

If we can't make the feature less destructive and automatic now, I think proposed flow with the opt-out in the installer is a better experience for the user. I think it's better to add back some friction for a small number of users than to ask them if they want to undo something they didn't even know was happening.

> To put things in context, 40% of installs are re-installs (profile directory
> exists) and 8% of installs are done where the same Firefox version is
> already installed (likely that users are trying to fix something).

For the 8% who have the same Firefox version installed we have the refresh from web feature (Bug 1062345). 

I believe the numbers that Peter provided for the number of people not active for more than 60 days was something like 4% though that could be higher if the buzz around 57 attracts more people to come back and give Firefox a try.

Comment 23

[Romain Testard [:RT]]

(In reply to Verdi [:verdi] from comment #22)
> The way we'd always planned on doing this was to do the refresh
> automatically but we were only comfortable doing that if we could migrate
> add-ons but make them disabled (Bug 1017919). Since that's not possible in
> the 57 time frame and we're getting much of the benefit from the loss of
> legacy add-ons we decided to go with an opt-out version.
> 
As a user who has not used Firefox for 60 days, do I really care about these add-ons?
Do users not expect a fresh new install when they re-install manually?
Maybe a Shield study could help us there if this has not been looked into before.
> 
> > How about running the profile clean-up by default for eligible installs at
> > Firefox start-up and provide a way for users to "undo"? (See attachment).
> 
> The undo idea is interesting but just making the feature less destructive
> would be better. Then it won't require as much explanation (or any) or
> something like an undo. I could be wrong but it seems to me that building an
> undo feature in the 57 time frame might not even be feasible.
I'm not sure, maybe someone on this thread can comment. I was thinking about copying the original profile data to a backup profile and the "undo" would just reset the default profile.
> 
> > This would provide a non install blocking experience and a way out for the
> > users who have reasons not to want this.
> 
> If we can't make the feature less destructive and automatic now, I think
> proposed flow with the opt-out in the installer is a better experience for
> the user. I think it's better to add back some friction for a small number
> of users than to ask them if they want to undo something they didn't even
> know was happening.
> 
Since doing this in the FF56 timeline is a challenge given the other FF56 deliveries, should we use the FF56 time to somehow validate that the stub-based flow is right? We may use this as well to optimize strings. Something we could follow-up on with Jennifer?
> > To put things in context, 40% of installs are re-installs (profile directory
> > exists) and 8% of installs are done where the same Firefox version is
> > already installed (likely that users are trying to fix something).
> 
> For the 8% who have the same Firefox version installed we have the refresh
> from web feature (Bug 1062345). 
> 
> I believe the numbers that Peter provided for the number of people not
> active for more than 60 days was something like 4% though that could be
> higher if the buzz around 57 attracts more people to come back and give
> Firefox a try.
Is this the share of re-installs where previous installs have not been used for over 60 days?

Comment 24

[Peter Dolanjski [:pdol]]

(In reply to Romain Testard [:RT] from comment #23)
> (In reply to Verdi [:verdi] from comment #22)
> > I believe the numbers that Peter provided for the number of people not
> > active for more than 60 days was something like 4% though that could be
> > higher if the buzz around 57 attracts more people to come back and give
> > Firefox a try.
> Is this the share of re-installs where previous installs have not been used
> for over 60 days?

Here is the stat that's being referenced:
About 10% of currently active users (using a number of different weeks as the sample) were last active at least 14 days ago. (meaning they came back after at least a 14 day hiatus)
Of those users, about 20% were actually last active over 58 days ago.
So, 10% x 20% = 2% of currently active users were last active at least 58 days ago.  

That doesn't tell us anything about re-installs, though. (though we can likely assume that some portion of those users will re-install instead of just launching Firefox and getting an update)

Comment 25

[Peter Dolanjski [:pdol]]

Here is the data that I referenced (generated by Saptarshi): https://docs.google.com/spreadsheets/d/1_Zlr6w_QpoIbe9ZA0E4at5niVGx7iTEmg_pDzorkj8Q/edit#gid=0

Comment 26

[Peter Dolanjski [:pdol]]

(In reply to Benjamin Smedberg [:bsmedberg] from comment #20)
> Concerns that pdol asked me to put into this bug:
> * timestamps are hard and users clock-skew a lot more than we think: we
> should probably make sure that a person who uses the browser regularly but
> has a messed up clock once doesn't get reset
> * I'd encourage you to be cautious and measure this carefully so that we
> know exactly how often it's happening and monitor that it's not happening to
> active users.

This is the critical piece that needs to be worked out.  How do we test how many people are going to get false positives for being inactive for 60 days?

Comment 27

[Romain Testard [:RT]]

This may give us clues (it excludes users the uninstalled Firefox prior to re-installing), Firefox new stub installs per old version where the installed version was 53.0.3 and there used to be Firefox installed previously:
https://sql.telemetry.mozilla.org/queries/4871/source#9960
About 50% of re-installs were from users who had 53.X already installed, the rest is pretty thinely spread across other Firefox versions.

Comment 28

[Romain Testard [:RT]]

After discussions we agreed to move forward with the following approach:
- We'll be using Michael's proposed UX principles (may need adjustments) - https://bug1369255.bmoattachments.org/attachment.cgi?id=8873264
- We'll be selecting users who get the extra stub installer page based on their old version number rather than days without activity (old version > current version-2). https://sql.telemetry.mozilla.org/queries/4871/source#9960 shows that installs where the old version is N-1 is 1.92% and N-2 is 1.79% of daily installs currently. This means that targeting old version > current version-2 is fairly conservative
- We'll implement a back-out solution in case the Beta telemetry indicates that this has a negative effect on install success rate (probably a preference)
- We're targeting FF57 for this although this is NOT a Quantum release blocker

I'm adding all these details to the user story field.
Michael, can you please confirm if the UX and the strings are final? We can potentially user test the strings during the FF56 cycle since we can only start development on this when FF57 hits nightly.

Comment 29

[Romain Testard [:RT]]

User story now updated with acceptance criteria.
Peter/Nicole could you please raise the Firefox bug needed to implement this feature on the browser side since I'll be out in the next 3 weeks and won't be able to track this?

Comment 30

[Fischer [:Fischer]]

(In reply to Romain Testard [:RT] from comment #29)
> User story now updated with acceptance criteria.
> Peter/Nicole could you please raise the Firefox bug needed to implement this
> feature on the browser side since I'll be out in the next 3 weeks and won't
> be able to track this?
Hi Romain,

The bug 1376558 would handle the browser side. After the bug 1376558 is landed, only user-triggered profile refresh would migrate the previous sessions. So once the stub-installer find user's firefox version is too old and with the auto-refresh checkbox checked, please invoke Firefox by the command of `firefox.exe -reset-profile -migration`. Then we wouldn't migrate old sessions and users would see the 1st run page just like an new user.

Thanks

Comment 31

[Peter Dolanjski [:pdol]]

(In reply to Fischer [:Fischer] from comment #30)
> The bug 1376558 would handle the browser side. After the bug 1376558 is
> landed, only user-triggered profile refresh would migrate the previous
> sessions. So once the stub-installer find user's firefox version is too old
> and with the auto-refresh checkbox checked, please invoke Firefox by the
> command of `firefox.exe -reset-profile -migration`. Then we wouldn't migrate
> old sessions and users would see the 1st run page just like an new user.

Matt, does this approach work for you?

Comment 32

[Nicole Yee (:nicoleyee)]

Hey Matt,

The onboarding team is targeting to land the profile refresh feature in 56. Soft code free is July 31st. Can we complete the stub installer portion of this by then? Rational to try and make it into 56 is to make sure we have enough time to test and fix any potential blockers before 57.

Comment 33

[Molly Howell (she/her) (no longer active)]

(In reply to Peter Dolanjski [:pdol] from comment #31)
> Matt, does this approach work for you?

Yes, I'm okay with where we've ended up at here.

(In reply to Nicole Yee (:nicoleyee) from comment #32)
> Hey Matt,
> 
> The onboarding team is targeting to land the profile refresh feature in 56.
> Soft code free is July 31st. Can we complete the stub installer portion of
> this by then? Rational to try and make it into 56 is to make sure we have
> enough time to test and fix any potential blockers before 57.

Well, I have PTO coming up from the 13th through the 21st, so that would give me basically one week to get this in before the feature freeze. That's... uncomfortably tight. I think it's possible if this is a high enough priority, but definitely on the low end of what I would estimate. That also assumes the final UI design is ready to go by then.

Comment 34

[Nicole Yee (:nicoleyee)]

(In reply to Matt Howell [:mhowell] from comment #33)

>  I think it's possible if this is a high
> enough priority, but definitely on the low end of what I would estimate.
> That also assumes the final UI design is ready to go by then.

Hey Matt,

We can land this in 57. Unfortunately, the code freeze for 57 is Aug 7th. Only 1 week after the 56 code freeze. We would still need this bug to land before the 31st (or very close to that date) to allow enough time for QA testing and bug fixing. This feature is of high priority. We expect that 57 will bring many re-installing users and we want to make sure that they have clean profile for 57.

Michael will have the final spec for you before the 21st when you come back from PTO.

Comment 35

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Per the last comments I guess this is no longer shipping in 56?

Comment 36

[David Durst [:ddurst]]

I wasn't aware that a code freeze for non-Quantum things is in effect until September. Can we confirm that with release drivers, please?

Comment 37

[Nicole Yee (:nicoleyee)]

(In reply to David Durst [:ddurst] from comment #36)
> I wasn't aware that a code freeze for non-Quantum things is in effect until
> September. Can we confirm that with release drivers, please?

Quantum and Photon deadline for fx 57 is Aug 7th and this was set by Jean Gong (EPM) and Justin Dolske (Eng Mgr). This bug is apart of the onboarding flow for photon so the team is expected to land all bugs by Aug 7th. Code freeze for 57 is on Sept 21st but only bug fixing is to be expected between aug 7th and sept 21st.

Is it not possible to land this around July 31st? If so, I would need to talk to Jean and Justin about submitting feature related code after the Aug 7th deadline.

Comment 38

[Verdi [:verdi] Best to slack me]

Attachment: paveover.png

Here's an example of the final UI. Michelle and I are going to run a copy test on this quickly.

Comment 39

[Verdi [:verdi] Best to slack me]

Attachment: reinstall.png

In addition to the screen in the previous comment, we'll need one for the reinstallation flow. I don't believe there is copy that can work well for both the paveover and reinstallation flow so Michelle and I made these two different screens. The work exactly the same but have different copy.

Comment 40

[Romain Testard [:RT]]

(In reply to Verdi [:verdi] from comment #39)
> Created attachment 8889699 [details]
> reinstall.png
> 
> In addition to the screen in the previous comment, we'll need one for the
> reinstallation flow. I don't believe there is copy that can work well for
> both the paveover and reinstallation flow so Michelle and I made these two
> different screens. The work exactly the same but have different copy.

Thanks Michael, can you clarify how paveover and reinstallation scenarios are defined? Is a paveover installation a reinstallation of the same version?

Comment 41

[Molly Howell (she/her) (no longer active)]

(In reply to Romain Testard [:RT] from comment #40)
> Thanks Michael, can you clarify how paveover and reinstallation scenarios
> are defined? Is a paveover installation a reinstallation of the same version?

I'm also confused about the intended distinction. If it's about the version being installed over, I see both cases are showing the cleanup checkbox, so does that mean we now also want to do that when installing over the same version, as well as older versions?

Comment 42

[Verdi [:verdi] Best to slack me]

(In reply to Romain Testard [:RT] from comment #40)
> 
> Thanks Michael, can you clarify how paveover and reinstallation scenarios
> are defined? Is a paveover installation a reinstallation of the same version?

Sure. So if the user is installing Firefox and there is already a Firefox.exe installed (2 versions out of date for our use-case) we'll use the "paveover" screen. If the user is installing Firefox and it's not already installed but there is an existing profile folder (indicating the last installed version is 2 versions out of date), we should use the "re-install" screen.

The reason we came up with these different screens is because the checkbox doesn't make sense from a user's perspective if they don't have Firefox. So we have to give them some explanation of why they're being presented with this choice. I've seen people be particularly confused in testing when they are greeted with the "Upgrade" button in the current installer. They cite not having Firefox so they're confused about why they're offered an upgrade button and they've also cited "upgrade" as indicating an option that costs money.

 (In reply to Matt Howell [:mhowell] from comment #41)
> I'm also confused about the intended distinction. If it's about the version
> being installed over, I see both cases are showing the cleanup checkbox, so


I think the distinction here is mainly for the person installing. In both cases, we're going to do the same thing - install Firefox and tell Firefox to refresh itself.


> does that mean we now also want to do that when installing over the same
> version, as well as older versions?

No we still only want to do this for people who are 2 versions out of date.

Comment 43

[David Durst [:ddurst]]

(Speaking only to one point: should we be using "update" instead of "upgrade" because of the latter's connotation of some sort of charge? I've wondered this for a while, as update/upgrade are often used interchangeably.)

Comment 44

[Molly Howell (she/her) (no longer active)]

Ah, so "re-install" is for when there used to be a Firefox installed more than 2 version ago, but it isn't installed anymore, we can only tell it was there because there's still a profile sitting around. And paveover means we're updating an installation that is currently present. I think I understand now, and I get the need for the distinction; thank you.

Comment 45

[Verdi [:verdi] Best to slack me]

(In reply to David Durst [:ddurst] from comment #43)
> (Speaking only to one point: should we be using "update" instead of
> "upgrade" because of the latter's connotation of some sort of charge? I've
> wondered this for a while, as update/upgrade are often used interchangeably.)

Yes. It seems "update" is pretty common for use as, get the next incremental version while "upgrade" is often used (including outside of software) as getting extra capabilities that can be had for extra cost.

(In reply to Matt Howell [:mhowell] from comment #44)
> Ah, so "re-install" is for when there used to be a Firefox installed more
> than 2 version ago, but it isn't installed anymore, we can only tell it was
> there because there's still a profile sitting around. And paveover means
> we're updating an installation that is currently present. I think I
> understand now, and I get the need for the distinction; thank you.

Exactly.

Comment 46

[Jean Gong :jgong]

Matt, it sounds like you are clear on this Verdi's UX requirement for this stub installer needed for Onboarding. We have confirmation that you would be able to get this done by Aug 18. Thanks!!

Comment 47

[Romain Testard [:RT]]

I now updated the user story with details on reinstall and paveover screens.

Comment 48

[Molly Howell (she/her) (no longer active)]

Quick question that's come up as I've been working on this UI: For differentiating between the paveover and re-install cases, should installations of other channels be counted? That is, if the user is installing a release build and there is a beta currently installed but not a release, should that user get the paveover UI?

Comment 49

[Molly Howell (she/her) (no longer active)]

Attachment: Re-install prompt implementation

Also, here's where the UI is at; I'm thinking this is pretty much done, but I'll take any feedback.

Comment 50

[Romain Testard [:RT]]

(In reply to Matt Howell [:mhowell] from comment #48)
> Quick question that's come up as I've been working on this UI: For
> differentiating between the paveover and re-install cases, should
> installations of other channels be counted? That is, if the user is
> installing a release build and there is a beta currently installed but not a
> release, should that user get the paveover UI?

For info we're heading towards dedicated profiles per channel per bug 1373244, so medium term we likely won't have to handle this. AFTAICT there is no way to know how often this scenario happens from the ping data but it sounds like an infrequent scenario. 

I feel like both  paveover or reinstall screens don't fit that scenario and risk confusing users, I think we have 2 options:
1 Ignore this scenario (i.e no profile refresh screen if you install a Firefox channel that is different from another Firefox channel already installed which falls into cases 1a or 1b of the user story field) given the low likelihood, we'll implement profiles per channel hopefully soon to handle this anyway
2 Implement a third type of screen to handle the multi-channel scenario in a way that does not confuse users

I'm inclined to go for (1), what are your thoughts Michael?

Comment 51

[Verdi [:verdi] Best to slack me]

(In reply to Romain Testard [:RT] from comment #50)

> I'm inclined to go for (1), what are your thoughts Michael?

I agree. Let's ignore this scenario - no refresh screen for these people.

Comment 52

[Molly Howell (she/her) (no longer active)]

Okay, this got a little complicated, so I want to check my understanding. Here's my current picture of the logic for deciding which prompt to show:

1) Is there a default Firefox profile present (non-default profiles might just have been forgotten about)?
  -- No: Don't show either prompt.
  -- Yes: Go to step 2.
2) Are there any Firefox installations at all already on the system?
  -- No: Show the re-install prompt.
  -- Yes: Go to step 3.
3) Are the existing installations all on different channels from the new install we're about to do?
  -- No: Go to step 4.
  -- Yes: Don't show either prompt.
4) Was the Firefox profile last used by a copy of Firefox that's more than 2 versions behind the new install we're about to do?
  -- No: Don't show either prompt.
  -- Yes: Show the paveover prompt.

RT (or Verdi), does that match up with what you intended?

Comment 53

[Verdi [:verdi] Best to slack me]

(In reply to Matt Howell [:mhowell] from comment #52) 
> RT (or Verdi), does that match up with what you intended?

This looks right to me.

Comment 54

[Verdi [:verdi] Best to slack me]

(In reply to Matt Howell [:mhowell] from comment #49)
> Created attachment 8891533 [details]
> Re-install prompt implementation
> 
> Also, here's where the UI is at; I'm thinking this is pretty much done, but
> I'll take any feedback.

This looks great. One nit: the baseline of the second line of the headline (Let's get you a new copy) looks to be about 5-6px lower than "Now Installing" on the next screen. If you could move the whole headline on this screen up to match that would be awesome.

Comment 55

[Romain Testard [:RT]]

(In reply to Matt Howell [:mhowell] from comment #52)
rompt.
>   -- Yes: Go to step 2.
> 2) Are there any Firefox installations at all already on the system?
>   -- No: Show the re-install prompt.
>   -- Yes: Go to step 3.
If a default profile but no Firefox installations exist, does this mean we cannot check the version that was installed and then un-installed? It sounds fine to show the re-install prompt in this case, just want to check why the version check does not happen here.

Comment 56

[Molly Howell (she/her) (no longer active)]

(In reply to Verdi [:verdi] from comment #54)
> This looks great. One nit: the baseline of the second line of the headline
> (Let's get you a new copy) looks to be about 5-6px lower than "Now
> Installing" on the next screen. If you could move the whole headline on this
> screen up to match that would be awesome.

Thanks for the feedback. I tuned things a bit and most of the mismatch is gone. I don't think I can get them to match exactly without positioning the two lines of text independently, which I think would cause issues for localization.

Comment 57

[Molly Howell (she/her) (no longer active)]

(In reply to Romain Testard [:RT] from comment #55)
> If a default profile but no Firefox installations exist, does this mean we
> cannot check the version that was installed and then un-installed? It sounds
> fine to show the re-install prompt in this case, just want to check why the
> version check does not happen here.

It would be possible to check the profile's last-used version in that case and only show the re-install prompt if that version shows up as > 2 behind, but I thought it made sense to unconditionally show the re-install prompt if all installations have been removed.

Comment 58

[Verdi [:verdi] Best to slack me]

(In reply to Matt Howell [:mhowell] from comment #57)
> I thought it made sense to unconditionally show the re-install prompt if
> all installations have been removed.

I think that's a smart change.

Comment 59

[Romain Testard [:RT]]

(In reply to Verdi [:verdi] from comment #58)
> (In reply to Matt Howell [:mhowell] from comment #57)
> > I thought it made sense to unconditionally show the re-install prompt if
> > all installations have been removed.
> 
> I think that's a smart change.
Understood now, Sounds good to me too!

Comment 60

[Molly Howell (she/her) (no longer active)]

Attachment: Patch version 1

Comment 61

[Robert Strong (they/them - no direct email)]

Comment on attachment 8893895 [details] [diff] [review]
Patch version 1

Talked with mhowell over irc and he is going to resubmit so there is less in the way of line movement (around 280 removed lines and those same 280 lines re-added).

Comment 62

[Molly Howell (she/her) (no longer active)]

Attachment: Patch part 1

This patch contains all the actual new code and necessary changes; part 2 will just be moving code. That keeps this diff somewhat bearable.

Comment 63

[Molly Howell (she/her) (no longer active)]

Attachment: Patch part 2

Just moves existing code including a few changes from part 1; no changes to code in this patch, just moves.

Comment 64

[Robert Strong (they/them - no direct email)]

Comment on attachment 8893909 [details] [diff] [review]
Patch part 1

All I did was a code review and not a functional review.

There are several reasons I disagree with this approach that I have stated in the past but I need to walk away from this and focus on other work.

Comment 65

[Molly Howell (she/her) (no longer active)]

I'm going to go ahead and push this to inbound and then start figuring out test cases.

Comment 66

[Molly Howell (she/her) (no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/165e54eeea49b8e27649dc1aedfd6bc7ffc87c5b
Bug 1369255 - Part 1: Add a prompt in the stub installer for running profile cleanup. r=rstrong

https://hg.mozilla.org/integration/mozilla-inbound/rev/647d1f09980c266021fc040cba63690c693f4265
Bug 1369255 - Part 2: Move SendPing to be less in the way and move install path checks earlier in the process. r=rstrong

Comment 67

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/165e54eeea49
https://hg.mozilla.org/mozilla-central/rev/647d1f09980c

Comment 68

[Justin [:JW_SoftvisionQA]]

I am not seeing the "re-install" screen on 1b. This is how I am getting there. Please let me know if I need to change any steps.

Preconditions: clear all profiles and instances of firefox
1. Install Nightly 53.0a1 (a profile is created)
2. Delete Nightly 53.0a1 (do not delete profile data)
3. Run Nightly 57.0a1 stub installer

Expected: re-install screen

Actual: installation automatically starts

Comment 69

[Molly Howell (she/her) (no longer active)]

Hmm, doesen't reproduce for me. Did you let 53.0a1 run before deleting it? The browser has to have been run at least once for a profile to get created; the installer doesn't create any profiles.

Comment 70

[Justin [:JW_SoftvisionQA]]

See video below:

https://jwilliams-softvision.tinytake.com/sf/MTg2MTU0N181OTkxNDAy

Comment 71

[Justin [:JW_SoftvisionQA]]

1 thing that I did notice is that I am installing 53.0a1 x86 and the 57 Stub installer is installing 57.0a1 x64.

Comment 72

[Molly Howell (she/her) (no longer active)]

Okay, thanks for the video. The steps you're following look correct, but I followed them exactly (including using the 32-bit 53.0a1 installer, since it shouldn't make a difference either way) and I still cannot replicate that failure. The only idea I have now is maybe the installer you're using is a couple of days out of date. Try downloading it straight from the web page at https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly and maybe that will help?

Comment 73

[Justin [:JW_SoftvisionQA]]

I was able to verify my issue on a different machine. I am not sure why I am running into this issue. I will investigate this more tomorrow before I verify this.


Another thing I noticed is that the stub-installer for 48.0a1, 53.0a1, & 54.0a1 are pointing to the 57.0a1 build (I am thinking ALL of the stub installers are pointed to the 57.0a1 build). I can write another bug for this. Just wanted to check with you first.

Comment 74

[Justin [:JW_SoftvisionQA]]

Update: My previous issue was happening because I was only deleting from the control panel. I had other Firefox/Nightly folders in program files. I will close this bug as Verified Fixed once I hear back about:

(In reply to Justin [:JW_SoftvisionQA] from comment #73)
> 
> Another thing I noticed is that the stub-installer for 48.0a1, 53.0a1, &
> 54.0a1 are pointing to the 57.0a1 build (I am thinking ALL of the stub
> installers are pointed to the 57.0a1 build). I can write another bug for
> this. Just wanted to check with you first.

Comment 75

[Molly Howell (she/her) (no longer active)]

(In reply to Justin [:JW_SoftvisionQA] from comment #74)
> Update: My previous issue was happening because I was only deleting from the
> control panel. I had other Firefox/Nightly folders in program files.

That in itself sounds like a bug, but if these were older versions I won't worry about it; probably nothing left to debug now anyway. Glad you got to the bottom of it.

> I will close this bug as Verified Fixed once I hear back about:
> 
> (In reply to Justin [:JW_SoftvisionQA] from comment #73)
> > 
> > Another thing I noticed is that the stub-installer for 48.0a1, 53.0a1, &
> > 54.0a1 are pointing to the 57.0a1 build (I am thinking ALL of the stub
> > installers are pointed to the 57.0a1 build). I can write another bug for
> > this. Just wanted to check with you first.

You're correct. This is intentional behavior; stubs should always be downloading and installing the latest version on their same channel, even if that version is newer than the stub is.

Comment 76

[Justin [:JW_SoftvisionQA]]

I have verified this bug with today's nightly. Adding myself to cc on bug 1387527 to stay in the loop with the telemetry.

Comment 77

[Andrei Vaida [:avaida]]

Updating status flags per Comment 76.