Closed Bug 986081 Opened 10 years ago Closed 6 years ago

Provide option to continue the download when cancelling the stub installer download

Categories

(Firefox :: Installer, enhancement, P1)

x86_64
Windows 8.1
enhancement

Tracking

()

RESOLVED FIXED
Firefox 61
Tracking Status
firefox61 --- fixed

People

(Reporter: robert.strong.bugs, Assigned: molly)

References

Details

(Whiteboard: [stubv3+])

Attachments

(7 files, 7 obsolete files)

566.87 KB, image/png
Details
1.12 MB, image/png
phlsa
: ui-review+
Details
1.18 MB, image/png
Details
4.19 KB, image/png
Details
28.82 KB, image/png
Details
59 bytes, text/x-review-board-request
agashlin
: review+
Details
59 bytes, text/x-review-board-request
agashlin
: review+
Details
Currently it just offers to download the full installer. It would be nice to provide the option to continue the download.
Whiteboard: [stubv2+]
Assignee: nobody → robert.strong.bugs
Status: NEW → ASSIGNED
Philipp, what we discussed via email a few months ago and I think I'd like to do is:

Display a messagebox asking whether to continue the download with the default button set to continue.

If the download is cancelled, display a page with a checkbox to open the page to download the full installer and a "Finish" button.

Are you ok with this?
Flags: needinfo?(philipp)
BTW: I am leaning towards the messagebox for whether to continue downloading since having 3 options on a page would be rather clumsy especially when one of those options would be to Finish, it would lessen the chances of continuing the download with 3 options, and it would be difficult to promote continuing the download over the Finish button.

Note: with the messagebox, the Finish page would have a checkbox that is checked by default to open the download page.
Example of Finish page with minimal text
Attachment #8394361 - Flags: ui-review?(philipp)
Matej, could you provide copy for this new page (see attachment) in the stub installer since you provided the other copy? This page will be shown when the user cancels the download, when the download is interrupted, or when the install fails so multiple strings would likely be better. Thanks!
Flags: needinfo?(Mnovak)
I would suggest one of the following:

Your Nightly download did not finish.

Nightly did not finish downloading.


Any preferences?

Also, I'm sure the image in comment 3 is just a mockup, but I notice that it says "Dowload" next to the check box.
Flags: needinfo?(Mnovak)
Thanks Metej!

I think I prefer "Nightly did not finish downloading."

What about the installation failed case? How about "Nightly was unable to install."?

Would you like to put additional text or is the minimal text preferred?

Are you ok with "Download Full Installer"? Perhaps "Download the Full Nightly Installer"?

Thanks for catching the typo in the mockup.
Flags: needinfo?(Mnovak)
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #6)
> Thanks Metej!
> 
> I think I prefer "Nightly did not finish downloading."
> 
> What about the installation failed case? How about "Nightly was unable to
> install."?

How about "Nightly did not finishing installing." to match the other one?
 
> Would you like to put additional text or is the minimal text preferred?

Not sure what you mean here.
 
> Are you ok with "Download Full Installer"? Perhaps "Download the Full
> Nightly Installer"?

Will people know that they're running an installer or even know what one is? Do we need to have this option? It feels pretty advanced.
Flags: needinfo?(Mnovak)
(In reply to Matej Novak [:matej] from comment #7)
> (In reply to Robert Strong [:rstrong] (use needinfo to contact me) from
> comment #6)
> > Thanks Metej!
> > 
> > I think I prefer "Nightly did not finish downloading."
> > 
> > What about the installation failed case? How about "Nightly was unable to
> > install."?
> 
> How about "Nightly did not finishing installing." to match the other one?
That works for me

> > Would you like to put additional text or is the minimal text preferred?
> 
> Not sure what you mean here.
In case you think these strings should be more verbose.

> > Are you ok with "Download Full Installer"? Perhaps "Download the Full
> > Nightly Installer"?
> 
> Will people know that they're running an installer or even know what one is?
> Do we need to have this option? It feels pretty advanced.
We definitely need it since this gives us another way to successfully get installed onto the system.

What we currently do which was a quick fix is display a messagebox with the text:
"Your download was interrupted.

Please click the OK button to continue."

that defaults to OK. When that is clicked or the user hits enter the page to download the full installer is opened.

I agree that the text is sub-optimal and am up for pretty much anything regarding the text.
Perhaps the text in the main window could provide more detail to inform the user regarding the checkbox?
Flags: needinfo?(Mnovak)
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #1)
> Philipp, what we discussed via email a few months ago and I think I'd like
> to do is:
> 
> Display a messagebox asking whether to continue the download with the
> default button set to continue.
> 
> If the download is cancelled, display a page with a checkbox to open the
> page to download the full installer and a "Finish" button.
> 
> Are you ok with this?

In general, yes. I take it that is message box would only appear if the user cancels the download (as opposed to when the download fails) right?

How about something like this for that case:

Do you want to cancel downloading? If you do, Nightly will not be installed.
[Continue downloading] [Cancel download]

Regarding the copy in the main downloads window: I think few people know what is actually going on when they use the stub installer. So our goal should be to convey the message »Since installing Firefox this way didn't work for you, here's a way that might work better (and it is super easy!)«
Flags: needinfo?(philipp)
I'm having a bit of trouble understanding everything that's needed here and what all the implications are. Could someone put together an etherpad or something (or even just put everything into a single comment) with all the copy we need? Everything I'm seeing looks pretty good, but I feel like I'm missing a few pieces.

Also, what's the timing on this? I may not be able to get back to it until some time next week.

Thanks.
Flags: needinfo?(Mnovak)
Hi Matej, I think this covers it.

1. When manually cancelling a download:
Display a messagebox asking whether to continue the download with the default button set to continue.

Copy needed: MessageBox text. Example:
Do you want to cancel downloading? If you do, Nightly will not be installed.
[Continue downloading] [Cancel download]

Note: we only have the OS provided MessageBox button text to work with
 
2. If the manually cancelled download is not continued (from item 1)
Display a page with a checkbox to open the page with the option to download the full installer and a "Finish" button.

Copy needed: See screenshot. Example:
Since installing Firefox this way didn't work for you, here's a way that might work better (and it is super easy!)

3. When a download fails:
Display a page with a checkbox to open the page with the option to download the full installer and a "Finish" button.

Copy needed: See screenshot. Example:
Since installing Firefox this way didn't work for you, here's a way that might work better (and it is super easy!)

4. When an install fails:
Display a page with a checkbox to open the page with the option to download the full installer and a "Finish" button.

Copy needed: See screenshot. Example:
Since installing Firefox this way didn't work for you, here's a way that might work better (and it is super easy!)

I'd like to get this in before the end of the month since it is part of our quarterly goals.
Flags: needinfo?(Mnovak)
Thanks, Robert. Much appreciated. Looks like we just need to strings. I actually quite like what Philipp came up with in comment 10. I just made a few revisions to the string and buttons for the other one.

1:
Are you sure you want to cancel your download? If you do, Nightly will not be installed.
[Resume download] [Cancel download]

2, 3, 4:
Since installing Firefox this way didn't work for you, here's a way that might work better (and it's super easy!).

Let me know if you have any questions or need anything else.
Flags: needinfo?(Mnovak)
(In reply to Matej Novak [:matej] from comment #13)
> Thanks, Robert. Much appreciated. Looks like we just need to strings. I
> actually quite like what Philipp came up with in comment 10.

Did not see that coming ;)

If we go with the »Since installing Firefox this way didn't work for you, here's a way that might work better (and it's super easy!).« bit, then perhaps the button/link to click should say something like:

»Download the full installer from the Mozilla website«

Just to make clear what is happening.
(In reply to Philipp Sackl [:phlsa] from comment #14)
> (In reply to Matej Novak [:matej] from comment #13)
> > Thanks, Robert. Much appreciated. Looks like we just need to strings. I
> > actually quite like what Philipp came up with in comment 10.
> 
> Did not see that coming ;)
> 
> If we go with the »Since installing Firefox this way didn't work for you,
> here's a way that might work better (and it's super easy!).« bit, then
> perhaps the button/link to click should say something like:
> 
> »Download the full installer from the Mozilla website«

I'd really like to avoid the word "installer." It just feels technical and jargony here. Could we just say "Get it now" as the CTA? I think the copy does a good job of explaining that they're getting something else, but they don't need to understand exactly what.
I'll throw together some screenshots for review.
Note: for the messaegbox we have the following options

For button text:
MB_OK - Display with an OK button
MB_OKCANCEL - Display with an OK and a cancel button
MB_ABORTRETRYIGNORE - Display with abort, retry, ignore buttons
MB_RETRYCANCEL - Display with retry and cancel buttons
MB_YESNO - Display with yes and no buttons
MB_YESNOCANCEL - Display with yes, no, cancel buttons

For icons
MB_ICONEXCLAMATION - Display with exclamation icon
MB_ICONINFORMATION - Display with information icon
MB_ICONQUESTION - Display with question mark icon
MB_ICONSTOP - Display with stop icon
MB_USERICON - Display with installer's icon
Attached image manual download page screenshot (obsolete) —
Attachment #8396064 - Flags: ui-review?(philipp)
Attachment #8396064 - Flags: ui-review?(Mnovak)
Comment on attachment 8396070 [details]
Retry screenshot

Note: this should have the exclamation point icon and I've changed it locally
or question mark... which do you think is more appropriate?
This seems close to finish in regards to strings / UX and I'd like to get this done by Friday if at all possible. Thanks!
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #21)
> or question mark... which do you think is more appropriate?

I think a question mark is more appropriate.

Since it looks like there's no way we can get a »Resume« label on the dialog button, »Retry« seems to be the next best thing, so that looks good :)

There are a couple of issues with the other screen though (seeing everything in context really helps here):
1) The elements are currently spread out all over the window. There are three pieces of information/UI-elements and each one is in a different corner of the window. I'll throw something together this week…
2) »Get it now« feels a misplaced next to a checkbox. This might get better when we move the copy text closer to the footer, but it still leaves the question open what »it« is. Maybe changing it to »Download Firefox« or »Download full Firefox« would help?
3) I'm still torn on the copy text. While it is sympathetic and lively, it is also quite abstract and there is little more concrete information in the rest of the UI that would catch it.

Matej, I think you'll have to make the ultimate call on the copy.
Attached image alternative copy (obsolete) —
How about something like this?

I'm somewhat concerned about moving the text alongside the app name lower due to some locales requiring longer text and the globe shortening the width available.
Attachment #8396772 - Flags: feedback?(philipp)
Comment on attachment 8396772 [details]
alternative copy

or perhaps "Get alternative BrandShortName installer"?
Attached image alternative copy 2 (obsolete) —
I think I prefer "Get the alternative BrandShortName installer"
Comment on attachment 8396772 [details]
alternative copy

»Get the alternative Firefox installer« is definitely better!

I'm still not sold on the main copy though. With the above changes in mind, how about

»Sorry, something went wrong while installing Firefox. Please use the alternative installer.«
Attachment #8396772 - Flags: feedback?(philipp)
Flags: needinfo?(Mnovak)
Attached image screenshot (obsolete) —
Created a screenshot with the new copy.

If you prefer, we could just use a color for the background and place the checkbox in the content area instead of in the footer.

If anyone has an idea of how we can ask the user without a messagebox whether they would like to continue to download I'd like to hear them. I'd love to get rid of the messagebox but I don't think there is a reasonable way to do so without making this page overly complicated.
Attachment #8394361 - Attachment is obsolete: true
Attachment #8396064 - Attachment is obsolete: true
Attachment #8396772 - Attachment is obsolete: true
Attachment #8396810 - Attachment is obsolete: true
Attachment #8394361 - Flags: ui-review?(philipp)
Attachment #8396064 - Flags: ui-review?(philipp)
Attachment #8396064 - Flags: ui-review?(Mnovak)
Attachment #8399675 - Flags: ui-review?(Mnovak)
Note: in the screenshot the term Firefox would actually be Nightly, etc... I left it hardcoded.
(In reply to Philipp Sackl [:phlsa] from comment #27)
> Comment on attachment 8396772 [details]
> alternative copy
> 
> »Get the alternative Firefox installer« is definitely better!
> 
> I'm still not sold on the main copy though. With the above changes in mind,
> how about
> 
> »Sorry, something went wrong while installing Firefox. Please use the
> alternative installer.«

I'm still worried about the word "installer."

How about:

Sorry, something went wrong while installing Firefox. Would you like to use an alternate method?

Or, longer:

Sorry, something went wrong while installing Firefox. Would you like to use an alternate method to complete your installation?
Flags: needinfo?(Mnovak)
Thanks Matej! The first version sounds great to me.
Attached image screenshot with latest copy (obsolete) —
Attachment #8399675 - Attachment is obsolete: true
Attachment #8399675 - Flags: ui-review?(Mnovak)
Attachment #8401430 - Flags: ui-review?(philipp)
Attachment #8401430 - Flags: ui-review?(Mnovak)
Do you want to change the wording for the checkbox as well? I think I'd prefer if it matched the text above.
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #33)
> Do you want to change the wording for the checkbox as well? I think I'd
> prefer if it matched the text above.

Agreed. Maybe "Yes, use the alternate method"
The "Yes, " would be out of place with the rest of the checkbox text in the stub installer and other checkboxes on Windows. Perhaps "Get the alternative method" since it requires additional actions by the user?
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #35)
> The "Yes, " would be out of place with the rest of the checkbox text in the
> stub installer and other checkboxes on Windows. Perhaps "Get the alternative
> method" since it requires additional actions by the user?

I would still say "use" rather than "get," but otherwise I'm fine not including the "yes."
Attachment #8401430 - Attachment is obsolete: true
Attachment #8401430 - Flags: ui-review?(philipp)
Attachment #8401430 - Flags: ui-review?(Mnovak)
Attachment #8401468 - Flags: review?(philipp)
Attachment #8401468 - Flags: review?(philipp) → ui-review?(philipp)
Attachment #8401468 - Flags: ui-review?(Mnovak)
Comment on attachment 8401468 [details]
screenshot with latest copy

oops... missed adding use in the compile
Attachment #8401468 - Flags: ui-review?(philipp)
Attachment #8401468 - Flags: ui-review?(Mnovak)
Comment on attachment 8401468 [details]
screenshot with latest copy

meh... confused the attachments
Attachment #8401468 - Flags: ui-review?(philipp)
Comment on attachment 8401468 [details]
screenshot with latest copy

Ship it!
Attachment #8401468 - Flags: ui-review?(philipp) → ui-review+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Sorry - didn't mean to close this, I had it confused with another bug I had open. Sorry!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Whiteboard: [stubv2+] → [stubv3+]
It's unlikely that I will get to work on this in the next two weeks, so unassigning myself for now.
Assignee: robert.strong.bugs → nobody
Status: ASSIGNED → NEW
Priority: -- → P3
Severity: normal → enhancement
Hi Michael, about 10% of installs fail and 70% of these 10% relate to users cancelling the installation (with our new UI this is now users closing the installer window).
Given we still focus on improving install success rate this bug feels like a priority for us right now. Are you still the right person to help us with UX on the installer?
The scope described on comment 12 seems still relevant but the UX will need to adapt to the streamlined experience.
Now with NI to Michael...
Flags: needinfo?(mverdi)
(In reply to Romain Testard [:RT] from comment #43)
> Are you still the right person to help us with UX
> on the installer?

Yes. I'll also ask someone from the content team to help with the copy. I'll leave myself NI until I have some proposals.
Attached image install-cancel.png (obsolete) —
(In reply to Romain Testard [:RT] from comment #43)

> The scope described on comment 12 seems still relevant but the UX will need
> to adapt to the streamlined experience.

Looking back at comment 12 it seems we have two use-cases - the user cancels the install or the install fails on it's own. From the user's perspective we can treat these the same. That's what we were thinking when we re-wrote the dialog that appears when you click the X. It now says, "Hmm. For some reason, we could not install Firefox. Choose OK to start over. [OK] [Cancel]" If you click Cancel then you're done. If you click OK, we open this page - https://www.mozilla.org/en-US/firefox/installer-help/?channel=release&installer_lang=en-US - with a download link to the full installer. 

This page needs a visual update to match Photon and the download page. 

In addition we might be able to improve the success of this page with some other changes:
* Start the download of the full installer automatically with a link to restart that download if it fails to happen (similar to scene 2 of the download page https://www.mozilla.org/en-US/firefox/new/?scene=2 )
* Remove all extraneous links: header links, footer links, newsletter sign up form

I've attached a simple mockup.
Flags: needinfo?(mverdi)
> 
> Looking back at comment 12 it seems we have two use-cases - the user cancels
> the install or the install fails on it's own. From the user's perspective we
> can treat these the same. 
If the user closes the window during download or install, right now there is no way back. 
If it's true that some users will close the window by mistake or without realizing the implications, we need a fall-back that is not redirecting users to full installers but rather just resuming the install. [Continue downloading] on "1." from Comment 12 would close the dialog and resume to where the user was prior to closing the window.
This is likely a better experience for users than going to a webpage to download the full installer.
What do you think?

> That's what we were thinking when we re-wrote the
> dialog that appears when you click the X. It now says, "Hmm. For some
> reason, we could not install Firefox. Choose OK to start over. [OK]
> [Cancel]" If you click Cancel then you're done. If you click OK, we open
> this page -
> https://www.mozilla.org/en-US/firefox/installer-help/
> ?channel=release&installer_lang=en-US - with a download link to the full
> installer. 
> 
> This page needs a visual update to match Photon and the download page. 
> 
Agreed
> In addition we might be able to improve the success of this page with some
> other changes:
> * Start the download of the full installer automatically with a link to
> restart that download if it fails to happen (similar to scene 2 of the
> download page https://www.mozilla.org/en-US/firefox/new/?scene=2 )
> * Remove all extraneous links: header links, footer links, newsletter sign
> up form
> 
Agreed
> I've attached a simple mockup.
That look nice and simple. Only question/suggestion I have is whether people find easily files when they download them? Sometimes websites show arrows pointing at where the user shouldclickto access the files based on the browser he's in, I wonder if it was ever considered?
Flags: needinfo?(mverdi)
(In reply to Romain Testard [:RT] from comment #47)
> > 
> > Looking back at comment 12 it seems we have two use-cases - the user cancels
> > the install or the install fails on it's own. From the user's perspective we
> > can treat these the same. 
> If the user closes the window during download or install, right now there is
> no way back. 
> If it's true that some users will close the window by mistake or without
> realizing the implications, we need a fall-back that is not redirecting
> users to full installers but rather just resuming the install. [Continue
> downloading] on "1." from Comment 12 would close the dialog and resume to
> where the user was prior to closing the window.
> This is likely a better experience for users than going to a webpage to
> download the full installer.
> What do you think?
> 

Yes. I shouldn't have assumed that this wasn't possible and that's why we were redirecting to a webpage. If the user closes the window and then chooses OK to restart the install, we should just close that dialog and restart or resume where we left off. No need at all to redirect to a website, start a download of a full installer or show additional UI.

> > I've attached a simple mockup.
> That look nice and simple. Only question/suggestion I have is whether people
> find easily files when they download them? Sometimes websites show arrows
> pointing at where the user shouldclickto access the files based on the
> browser he's in, I wonder if it was ever considered?

Well, if we can just restart the download, then we don't necessarily need this page. But after thinking about your suggestion to show where the downloaded file is, I thought we could actually repurpose this page for people who click Cancel. It's reasonable to assume they still want to install Firefox (they've gone through a number of steps by this point) and were caught off guard by the auto install process. In this case it might be good to display the advanced install options (like the modal on the download page). And then maybe instead of/in addition to the "Need Help?" link we could have simplified install instructions that cover the whole process.
Flags: needinfo?(mverdi)
Okay, I want to get this one done, let me see if I understand what needs to happen here, at least for the installer-side change (the web stuff needs a separate bug if we want to do that).

Currently, when the user clicks the close button on the stub installer while it is in its download phase, we show a message box which sort of indicates that the download has failed and offers to either open a web page where the user can get the full installer for themselves, or to do nothing. There are no other options provided; one you click the close button, that install is finished one way or the other. What we would like to do instead when the user clicks the close button is prompt for confirmation, and either continue along as if nothing happened if the user decides they didn't want to cancel, or exit the installer without opening any web page or taking any other action if they really did want to cancel (I'm not sure we should even send a ping in that case; if we do, we need to add a new status code).

Is that all we need to do here? If so, I need a string to use for that confirmation prompt; the buttons on it will probably have to say "Yes" and "No" (the other option is "OK" and "Cancel").
(In reply to Matt Howell [:mhowell] from comment #49)
> Okay, I want to get this one done, let me see if I understand what needs to
> happen here, at least for the installer-side change (the web stuff needs a
> separate bug if we want to do that).
> 
> Currently, when the user clicks the close button on the stub installer while
> it is in its download phase, we show a message box which sort of indicates
> that the download has failed and offers to either open a web page where the
> user can get the full installer for themselves, or to do nothing. There are
> no other options provided; one you click the close button, that install is
> finished one way or the other. What we would like to do instead when the
> user clicks the close button is prompt for confirmation, and either continue
> along as if nothing happened if the user decides they didn't want to cancel,
> or exit the installer without opening any web page or taking any other
> action if they really did want to cancel (I'm not sure we should even send a
> ping in that case; if we do, we need to add a new status code).
> 
> Is that all we need to do here? If so, I need a string to use for that
> confirmation prompt; the buttons on it will probably have to say "Yes" and
> "No" (the other option is "OK" and "Cancel").

The experience described in Comment 12 seems ideal from the stub implementation standpoint if Michael is OK with it, this addresses a little more than what you describe here:
- allow continuing the download (UI 1) and prompt users to download the full installer if declined (UI2)
- prompt the user to download the full installer if download or install fails (UI2)

Michael does this align with your understanding? Could you help with a mock of the experience on the stub side to help get Matt unblocked?
Flags: needinfo?(mverdi)
What I'm thinking - comment 48 - is more simple than comment 12 and, I think, covers all the user-cases.

This doesn't require any new UI but it does require a redesign of /firefox/installer-help 

I put some details in the mockup. Let me know what you think.
Attachment #8950398 - Attachment is obsolete: true
Flags: needinfo?(mverdi)
Thanks Michael, that looks good to me. A couple comments:
- the string reads strangely to me and the string proposed in Comment 12 felt easier to understand although my understanding is we're limited by alert box constraints here for message length and button labelling.
- if users really want to cancel we redirect them to the download page anyway in your proposed flow. I think this is OK given people may hit the "OK" button by mistake and if users really want to not install despite downloading and launching the stub they can easily just close a tab

Matt, regarding "(I'm not sure we should even send a ping in that case; if we do, we need to add a new status code)" - currently my understanding is that we do send a Ping that counts as "Download cancelled". I think this is interesting stat that install time or download time can impact so we should keep it and "Download cancelled" status code feels appropriate?
(In reply to Romain Testard [:RT] from comment #52)
> Thanks Michael, that looks good to me. A couple comments:
> - the string reads strangely to me and the string proposed in Comment 12
> felt easier to understand although my understanding is we're limited by
> alert box constraints here for message length and button labelling.

If you're talking about, "Do you want to cancel downloading? If you do, Nightly will not be installed.
[Continue downloading] [Cancel download]" yes, that's more specific to the case of the user cancelling the install but it's confusing if the download stops because of some error. Can we tell them apart and have two different dialogs? I thought there was some reason we couldn't and that's why we wrote the current copy.
With NI to Matt to clarify if we can have a custom string for the use case where users close the installer window.
Flags: needinfo?(mhowell)
(In reply to Romain Testard [:RT] from comment #52)
> Matt, regarding "(I'm not sure we should even send a ping in that case; if
> we do, we need to add a new status code)" - currently my understanding is
> that we do send a Ping that counts as "Download cancelled". I think this is
> interesting stat that install time or download time can impact so we should
> keep it and "Download cancelled" status code feels appropriate?

You're right, we do have that status already; I'm not sure what I was thinking there, sorry.

(In reply to Romain Testard [:RT] from comment #54)
> With NI to Matt to clarify if we can have a custom string for the use case
> where users close the installer window.

We absolutely can do that, and I would be very much in favor of having it work that way.
Flags: needinfo?(mhowell)
> (In reply to Romain Testard [:RT] from comment #54)
> > With NI to Matt to clarify if we can have a custom string for the use case
> > where users close the installer window.
> 
> We absolutely can do that, and I would be very much in favor of having it
> work that way.

Great, I'd suggest using the string proposed in Comment 12 in that case "Do you want to cancel downloading? If you do, Nightly will not be installed.[Continue downloading] [Cancel download]" unless there are objections.
(In reply to Romain Testard [:RT] from comment #56)
> Great, I'd suggest using the string proposed in Comment 12 in that case "Do
> you want to cancel downloading? If you do, Nightly will not be
> installed.[Continue downloading] [Cancel download]" unless there are
> objections.

Okay, that sounds good, I'll go ahead and start working on this with that change. I can't really customize the button labels, though; I think those are going to have to be "Yes"/"No" (the other alternative is "OK"/"Cancel" but that seems self-evidently bad for this case).
(In reply to Matt Howell [:mhowell] from comment #57)
> Okay, that sounds good, I'll go ahead and start working on this with that
> change. I can't really customize the button labels, though; I think those
> are going to have to be "Yes"/"No" (the other alternative is "OK"/"Cancel"
> but that seems self-evidently bad for this case).

Ok - let me get Michelle to look at this. Yes/No and OK/Cancel are not great. That's why for example we wrote, "click OK" into the other string.
I'm actually going to experiment with that a bit; it might be possible to use a Windows 7-style task dialog instead of a traditional message box, and those do have customizable buttons.
Assignee: nobody → mhowell
Status: NEW → ASSIGNED
Priority: P3 → P1
Attached image Sample cancel dialog
Okay, I got that working, so we *can* have custom buttons. We can even have either traditional-looking buttons or the newer style "command" buttons, if we want. I'll attach a screenshot of what that version of the dialog looks like, but I'm happy to go either way.
That looks good to me. I only wonder if the string is right now that I look at the UI:
- It says "cancel downloading" but the scenario we want to capture is when the user closes the installer window at any moment (during install or download phase). Matt can you please confirm this UI would be shown in both instances?
- Should we rather say "Do you want to cancel the installation?" since the user won't understand/care that there is a download and then an install phase. He installs Firefox using an installer so we should talk to him about an installation. Brian is this something you could help us validate?
Flags: needinfo?(mhowell)
Flags: needinfo?(brjones)
Removing NI to Brian since Michelle is already in the loop
Flags: needinfo?(brjones)
We don't allow cancelling during the install phase, because of an unfortunate technical constraint; the full installer is running as a separate process at that point and there's no way to tell it to cancel while its working. The close button in the stub doesn't do anything after the download phase is over.
Flags: needinfo?(mhowell)
Attached image user-cancel-dialog.png
(In reply to Romain Testard [:RT] from comment #61)
> That looks good to me. I only wonder if the string is right now that I look
> at the UI:
> - It says "cancel downloading" but the scenario we want to capture is when
> the user closes the installer window at any moment (during install or
> download phase). Matt can you please confirm this UI would be shown in both
> instances?
> - Should we rather say "Do you want to cancel the installation?" since the
> user won't understand/care that there is a download and then an install
> phase. He installs Firefox using an installer so we should talk to him about
> an installation. Brian is this something you could help us validate?

(In reply to Matt Howell [:mhowell] from comment #63)
> We don't allow cancelling during the install phase, because of an
> unfortunate technical constraint; the full installer is running as a
> separate process at that point and there's no way to tell it to cancel while
> its working. The close button in the stub doesn't do anything after the
> download phase is over.

At this point in the process most users think that they "downloaded Firefox" when they downloaded the installer. Also the "installer" specifically calls out "Now Installing" while it is doing both downloading and installing. So for our purposes here, we should use "install" for consistency and comprehension even if it's not technically correct.

The copy Michelle wrote for this dialog is:
Do you want to install Firefox?
If you cancel, Firefox will not be installed. 
Install Firefox  (primary action)
Cancel  (secondary action)

Matt and talked about dialog styling over slack and I mocked up Michelle's copy with this new dialog using the regular buttons. 

And to be clear, this dialog should work the same way the other dialog (which we'll leave unchanged) does in comment 51: Clicking Install Firefox will restart the download and clicking Cancel will open /installer-help
(In reply to Verdi [:verdi] from comment #64)
> And to be clear, this dialog should work the same way the other dialog
> (which we'll leave unchanged) does in comment 51: Clicking Install Firefox
> will restart the download and clicking Cancel will open /installer-help

I'm not so sure about this behavior. /installer-help isn't really designed to serve this use case, and I feel like users who just duly confirmed that they want to cancel the installation are not going to be happy about having a web page suddenly appear trying to get them to download something else. I'd rather just exit cleanly and take no other action.
(In reply to Matt Howell [:mhowell] from comment #65)
> (In reply to Verdi [:verdi] from comment #64)
> > And to be clear, this dialog should work the same way the other dialog
> > (which we'll leave unchanged) does in comment 51: Clicking Install Firefox
> > will restart the download and clicking Cancel will open /installer-help
> 
> I'm not so sure about this behavior. /installer-help isn't really designed
> to serve this use case, 

It should be redesigned like I talked about in comment 48 and comment 51 but even without doing that it can still be helpful (see below).

> and I feel like users who just duly confirmed that
> they want to cancel the installation are not going to be happy about having
> a web page suddenly appear trying to get them to download something else.
> I'd rather just exit cleanly and take no other action.

In both the installer runs into a problem and the user clicks the X case, they have:
1. Searched for and found a Firefox download page.
2. Clicked Download Firefox.
3. Ran the installer file.
4. Told Windows it's ok to make changes to their computer. 

In other words, they've said yes 4 times. Why are they choosing to cancel now? They could have truly changed their mind or maybe they:
* Made a mistake or misread the dialog
* Really wanted to click advanced options but didn't see it (or it wasn't offered on the page they downloaded from)
* Just now realized that this might be installing Firefox in the wrong language
* Want to postpone the installation because something just came up
* Were caught off guard by the installer that starts automatically

There are a number of legitimate reasons to click cancel at this point and still want to install Firefox. All we'd be doing is opening a webpage with links that they might find helpful if they do indeed still want to install Firefox. If they did want to eventually install Firefox we've helped them. If they truly didn't want to install Firefox, I don't think opening this page would so prejudice them that they'd never consider installing Firefox in the future.
Comment on attachment 8961172 [details]
Bug 986081 - Allow backing out of closing the stub installer.

https://reviewboard.mozilla.org/r/229938/#review238088

::: browser/installer/windows/nsis/stub.nsi:1703
(Diff revision 1)
>    ${NSD_KillTimer} ClearBlurb
>    ; To better display the error state on the taskbar set the progress completed
>    ; value to the total value.
>    ${ITBL3SetProgressValue} "100" "100"
>    ${ITBL3SetProgressState} "${TBPF_ERROR}"
>    MessageBox MB_OKCANCEL|MB_ICONSTOP "$(ERROR_DOWNLOAD_CONT)" IDCANCEL +2 IDOK +1

If I'm reading this correctly we'll do LaunchHelpPageAndExit on IDOK, but just exit DisplayDownloadError without SendPing on IDCANCEL. I think we still want to send the ping, and that's what's going to exit the installer.

::: toolkit/mozapps/installer/windows/nsis/common.nsh:7611
(Diff revision 1)
> +                  p 0, \
> +                  p 0, \
> +                  i 0 \
> +                  ) p.r1"
> +  System::Call "comctl32::TaskDialogIndirect(p r1, *i 0 r0, p 0, p 0)"
> +  System::Free $0

I don't think we should be freeing $0 (selected button) or $R0 (unused?), the structures allocated are in $1 and $2?
Comment on attachment 8961172 [details]
Bug 986081 - Allow backing out of closing the stub installer.

https://reviewboard.mozilla.org/r/229938/#review238088

> I don't think we should be freeing $0 (selected button) or $R0 (unused?), the structures allocated are in $1 and $2?

Oops, yeah, that's left over from before I last renumbered the registers; good catch.
Comment on attachment 8961171 [details]
Bug 986081 Part 0 - Fix a hang when canceling an InetBgDl request.

https://reviewboard.mozilla.org/r/229936/#review238114
Attachment #8961171 - Flags: review?(agashlin) → review+
Comment on attachment 8961172 [details]
Bug 986081 - Allow backing out of closing the stub installer.

https://reviewboard.mozilla.org/r/229938/#review238116
Attachment #8961172 - Flags: review?(agashlin) → review+
Pushed by mhowell@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3a88c3c919f2
Part 0 - Fix a hang when canceling an InetBgDl request. r=agashlin
https://hg.mozilla.org/integration/autoland/rev/1e3e1229efde
Allow backing out of closing the stub installer. r=agashlin
https://hg.mozilla.org/mozilla-central/rev/3a88c3c919f2
https://hg.mozilla.org/mozilla-central/rev/1e3e1229efde
Landed 16 hours ago.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 61
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: