https://bugzilla.mozilla.org/show_bug.cgi?id=874410 In the above bug, it was brought to our attention that the "click here if the download didn't start" link was too small for the user on the download confirmation page. However, there are 2 larger issues that we are trying to resolve across mozilla.org that should be solved here: 1. Consistent sandstone styles. The user was landing at this URL after choosing to download from /en-US/: https://www.mozilla.org/en-US/products/download.html?product=firefox-21.0&os=linux&lang=en-US This above URL is presented in the older orange style. 2. Reduce redundant pages across Mozilla.org so we can more easily manage and keep track of things like redirects and style consistency. Solution: After choosing to download Firefox for Desktop for any platform, the user should be brought to the second state of firefox/new/. The second state of firefox/new/ presents a confirmation and thank you message along with platform relevant instructions. Question for developer: Do you see any issues in bringing the user to the confirmation state of /new? - One issue I see as of now is our back button logic on this page. It is tied to the inline animation. We should tie this logic to the previous step of the user, which in some cases is entering the confirmation state from a URL other than /new. - Can we adapt all of our download buttons to use this confirmation state?

Also, thanks to Maria for confirming that the text is overlookable.

This same scenerio exists anywhere this is a download button that is not on the /firefox/new/ page. We could make the buttons point directly to: https://www.mozilla.org/firefox/new/#download-fx (no locale) The good thing about that page is that it is already platform and language aware and we don't have to pass product= and os= parameters. Should we wait until the unified product download page is done, localized, and out the door?

Note: When users request /en-US/products/download.html with *no* query parameters, it should be point to the *first* scene and not the second scene of /firefox/new/.

Note: The link to /firefox/new/ should *not* include locale so that locale detection can happen on the download page itself. The download will more likely be translated in more languages than all pages with download buttons.

All: we've reviewed the data on download.html and most are links looking for the latest version of Firefox and most are sources like search and external links again pointing to the latest version. There doesn't appear to be much traffic at all purposely pointing to old links. With this, I don't see a problem with redirecting download.html to the second scene of the /firefox/new/ when query parameters exist.

I think we may want to approach this in phases. Step 1: prepare /firefox/new to accept download button referals Step 2: Change download buttons in Bedrock to point to the /firefox/new page Step 3: Redirect /products/download.html to stage #2 of /firefox/new Step 4: Remove /products/download.html from SVN We'll have to keep in mind that in Internet Explorer, the download buttons on mozilla.org follow a different path than other browsers. The paths are as follows: Most Browsers: 1. Clicking the download button links to /products/download.html?product=firefox-26.0&os=osx&lang=en-US (for example) 2. /products/download.html page starts the download process with the version/locale in the URL variables Internet Explorer: 1. Clicking the download button opens small pop-up window that starts the download and then instantly closes, then redirects the original browser window to the /products/download.html page 2. /products/download.html knows this is IE that the download should already have started from the pop-up, so no auto-download is triggered. IE has this separate path because if a download is triggered by javascript (rather than by a "human" clicking), it presumes it may be unsafe and throws a yellow warning bar. This isn't the case in the latest versions of IE, so it might make sense to limit this path only to older versions, but that's a case for another bug. It appears that we can already link to https://www.mozilla.org/en-US/firefox/new/#download-fx to get to the 2nd-stage of the /firefox/new page and start the download automatically. The only problem I see here is that /firefox/new/#download-fx auto-starts the download even if you are using Internet Explorer. This means a download button with the IE pop-up work-around that then redirects to /firefox/new/#download-fx will start the download twice. We'll need to update the /firefox/new page to not trigger the download for IE if you start the page with the #download-fx URL fragment. I'll file a bug for this change. One other note: some non en-US locales have PHP-based download buttons pointing to an alternate download page: https://www.mozilla.org/fr/products/download.html?product=firefox-26.0&os=osx&lang=fr These download buttons will have to be addressed and this alternate download page redirected/retired in the same was as /products/download.html.

(In reply to Steven Garrity [:sgarrity] from comment #6) > We'll need to update the /firefox/new page to not trigger the download for > IE if you start the page with the #download-fx URL fragment. I'll file a bug > for this change. Filed Bug 961753, as foretold.

We will probably need to update the logic of the updated button to handle IE issues. If browser == IE then redirect(/firefox/new/) else redirect(/firefox/new/#download-fx) end if This should be fine since we handle up-to-date or not-up-to-date Firefox users directly on /firefox/new/. It is just the IE issue that was resolved in bug 961753.

Update: This bug should be blocked by the soon-to-be-filed bug on rebuilding the /firefox/channel/ page since those download buttons currently point to download.html. If we point all download buttons to the second scene of /firefox/new/ and then redirect download.html to /firefox/new/ and *not* make /firefox/new/ handle non-release channel Firefox downloads, we will break the download buttons on /firefox/channel. Thus, we need to do the updates to the /firefox/channel/ page and have the download buttons point directly to download.mozilla.org *instead* of download.html.

I've reviewed the analytics for download.html and these are *only* 4 pages that need to be updated to point to the second scene of the download page. * / (homepage) https://github.com/mozilla/bedrock/blob/master/bedrock/mozorg/templates/mozorg/home.html#L228 * /firefox/desktop/ https://github.com/mozilla/bedrock/blob/master/bedrock/firefox/templates/firefox/desktop/desktop-base.html#L53 https://github.com/mozilla/bedrock/blob/master/bedrock/firefox/templates/firefox/desktop/index.html#L31 * /firefox/desktop/tips/ https://github.com/mozilla/bedrock/blob/master/bedrock/firefox/templates/firefox/desktop/tips.html#L254 * /plugincheck/ https://github.com/mozilla/bedrock/blob/master/bedrock/mozorg/templates/mozorg/plugincheck.html#L46 I think we should make another attribute to the download helper called "redirect=True" so that the buttons are like: {{ download_firefox(small=True, icon=False, redirect=True) }} When redirect is "True", the buttons link link to /[locale]/firefox/new/#download-fx Maybe "redirect" is not the best word as it could be unified=True as we are already using direct=True for buttons that link directly to download.mozilla.org. Let's see if we can get this done soon so we can eliminate the download.html php page from the equation all together. The changes to the helper and the download buttons above should eliminate 99% of the traffic to download.html and then we can finally redirect download.html to /firefox/new/ via bug 988046. pmac/jgmize/agibson: feedback?

Hi Chris, Sounds good, but one thing I'm not quite clear on - if there are only 4 remaining pages that need pointing to the second scene of /new, do we need the new attribute? Couldn't we just have the default behavior point to this page? (unless it's a direct download)

I agree with :agibson. I think we can just make it always point to /firefox/new/#download-fx unless it's direct or in some other way overridden.

+1 to :pmac and :agibson

(In reply to Paul McLanahan [:pmac] from comment #13) > I agree with :agibson. I think we can just make it always point to > /firefox/new/#download-fx unless it's direct or in some other way overridden. Yes, I would agree and that makes more sense. The default behavior should be that non-firefox/new/ buttons just point to /firefox/new/#download-fx without any additional query parameters. This will also help with SEO as there will be lots of internal links pointing to that URL. The direct=True and non-release channel buttons should functional as-is and point directly to download.mozilla.org.

I've taken a crack at this and changed the default behaviour in bedrock download buttons to point to /firefox/new/#download-fx It's working for be locally, but since this is such important download code, I could use extensive review of both the specific syntax/style, and the general concept.

In making these changes, I'm wondering if we should eliminate the LOCALES_WITH_TRANSITION [1] list in Bedrock. This list determines if a download button for a given locale should run through the transition page [2] or link directly to bouncer [3] (download starts, but the page doesn't change). The idea behind the LOCALES_WITH_TRANSITION list (I assume), is that don't want to link to a page with thanks/download-instructions that isn't translated into the current locale - even if Firefox is available in that locale. I would propose that we eliminate this list, and run all download button links through the /firefox/new/#download-fx The drawback is that for locales in which Firefox is available but /firefox/new is not [4], these visitors will get the right download, but then see the "Thanks for downloading Firefox!" page in English. Since we probably don't have any other pages on mozilla.org in those locales, I think this might be acceptable. Pascal, can you let us know if this makes sense? Thanks. For some context, of the 86 locales we have Firefox downloads for on /firefox/all/, there are nine for which /firefox/new/ is not enabled (ach, bn-BD, bn-IN, bs, kn, mai, nn-NO, or, si). Also of that list of 86 locales, the following 16 are not included in the LOCALES_WITH_TRANSITION list: ach, an, as, br, bs, csb, en-GB, en-ZA, ff, hsb, km, lij, mai, ms, nn-NO, xh [1] LOCALES_WITH_TRANSITION list: https://github.com/mozilla/bedrock/blob/f9f9100aa91689dcffea3f166b7c10440c7e2dc0/bedrock/settings/base.py#L869 [2] Example links with transition-page: old: https://www.mozilla.org/en-US/products/download.html?product=firefox-31.0-SSL&os=osx&lang=en-US new: https://www.mozilla.org/firefox/new/#download-fx [3] Example direct link: https://download.mozilla.org/?product=firefox-31.0-SSL&os=win&lang=en-US [4] Status of locales for /firefox/new/ page: http://l10n.mozilla-community.org/~pascalc/langchecker/?locale=all&website=0&file=firefox/new.lang

Also, for some more background, there was some discussion over on the pull request, but I thought it might be better logged here in Bugzilla: https://github.com/mozilla/bedrock/pull/2196

Eliminating LOCALES_WITH_TRANSITION appears to make things a bit more simple and the instances we don't have a translation looks like an edge case. It probably represents a very small minority of traffic to the page. Pascalc: are you fine with this edge case for simplicity reasons? Regardless, let's keep moving here and get this resolved and out the door. Thanks!

I am fine with removing the LOCALES_WITH_TRANSITION flag, we now cover most locales and the remaining ones are very marginal and/or not maintained.

Any update here? I may add this as a priority for the Growth Team given it could have an impact on downloads.

There is an active PR for this bug - https://github.com/mozilla/bedrock/pull/2221 I'll check with jgmize and pmac regarding its nearness to completion.

I believe that any time we show a user a download button and allow them to click it, they expect to get something in return. Any time a user clicks on a download button on Mozilla.org we should initiate a download. This should be consistent logic across all Mozilla.org pages. This is expected behavior if we display a download button. If we do not want a particular user to initiate a download, we should not display the button. Therefore, on the homepage it is up to the front-end design of the page to not display the download button for users that we do not want to click it. We will address this separately. For this bug, we should stay true to its purpose to "Point all bedrock download buttons to the second scene of download page /firefox/new/#download-fx" and as a result, trigger a download. Jgmize, and I will meet with Cmore on Monday, August 25th so that he is aware before we make this change.

We'll move forward with the direction in comment 4. Any time the user is presented with a download button, we send the them to the second scene of /new (#download-fx). Make the following update to the PR: For up to date Fx users who are visiting the second scene of /new (#download-fx) we will not send them back to the first scene. We're removing the logic that checks the version and redirects. Expected behavior is that, regardless of what version of Firefox you are on, if you land on #download-fx a download will occur and the second scene will be displayed. If a user lands directly on /new, the page will behave as it currently does, with appropriate conditional messaging depending on Firefox version.

The updated logic habber describes in comment 24 was put previously in the /firefox/new/ page via bug 919788. The logic to be removed for latest Firefox removing #download-fx and going back to the first scene appears to be here: https://github.com/mozilla/bedrock/blob/master/media/js/firefox/new.js#L223

Moving forward with the changes in comment #4 we need to decide what to show the user. If we use the current text for up-to-date firefox, "Congrats! You’re using the latest version of Firefox." it could be confusing to the user, but using the text for the out of date firefox, "Looks like you_re using an older version of Firefox", would be worse. Perhaps we could re-use part of the wording for non-firefox browsers for up-to-date firefox and just say "Thanks for downloading Firefox!", leaving off the second part, "As a non-profit, we're free to innovate on your behalf without any pressure to compromise. You're going to love the difference." This way we don't need any new strings. What do you think, :habber?

(In reply to Josh Mize [:jgmize] from comment #26) > Moving forward with the changes in comment #4 we need to decide what to show I meant comment 24, not #4.

(In reply to Josh Mize [:jgmize] from comment #26) > Moving forward with the changes in comment #4 we need to decide what to show > the user. If we use the current text for up-to-date firefox, "Congrats! > You’re using the latest version of Firefox." it could be confusing to the > user, but using the text for the out of date firefox, "Looks like you_re > using an older version of Firefox", would be worse. Perhaps we could re-use > part of the wording for non-firefox browsers for up-to-date firefox and just > say "Thanks for downloading Firefox!", leaving off the second part, "As a > non-profit, we're free to innovate on your behalf without any pressure to > compromise. You're going to love the difference." This way we don't need any > new strings. What do you think, :habber? I would prefer not adding any new strings given how much this page is localized. The "congrats!" and "looks like you're using an older version" are only displayed on scene 1 and not on scene 2. We probably shouldn't show those conditional messages when scene 2 are requested and just show people the same scene 2 that non-Firefox users see now. :habber: are you fine with up-to-date Firefox users that request scene 2 from other locations (namely the homepage) get the as-is scene 2 without any conditional logic? Seems like the easiest solution without messing around with conditional content on the second scene.

(In reply to Chris More [:cmore] from comment #28) > (In reply to Josh Mize [:jgmize] from comment #26) > > Moving forward with the changes in comment #4 we need to decide what to show > > the user. If we use the current text for up-to-date firefox, "Congrats! > > You’re using the latest version of Firefox." it could be confusing to the > > user, but using the text for the out of date firefox, "Looks like you_re > > using an older version of Firefox", would be worse. Perhaps we could re-use > > part of the wording for non-firefox browsers for up-to-date firefox and just > > say "Thanks for downloading Firefox!", leaving off the second part, "As a > > non-profit, we're free to innovate on your behalf without any pressure to > > compromise. You're going to love the difference." This way we don't need any > > new strings. What do you think, :habber? > > I would prefer not adding any new strings given how much this page is > localized. The "congrats!" and "looks like you're using an older version" > are only displayed on scene 1 and not on scene 2. We probably shouldn't show > those conditional messages when scene 2 are requested and just show people > the same scene 2 that non-Firefox users see now. > > :habber: are you fine with up-to-date Firefox users that request scene 2 > from other locations (namely the homepage) get the as-is scene 2 without any > conditional logic? Seems like the easiest solution without messing around > with conditional content on the second scene. The current copy on scene 2 will work fine no matter how you reached this scene. (a user downloading Firefox for the first time vs. somebody needing a fresh copy) Let's keep the copy as-is. No string change and no new strings needed. Sgarrity and I discussed that this is a possible place to reach out to those downloading a fresh copy and help them with any problems they may be having with their current up-to-date version. We could test a link for this specific user that brings them to a SUMO article about resetting Firefox and/or inquire with a survey about this download. Something to add to the Growth Team list, cmore?

With the latest push to demo4, we now have the following behavior for up-to-date firefox users: 1. Users clicking the download button on https://www-demo4.allizom.org/en-US/ will be sent to https://www-demo4.allizom.org/en-US/firefox/new/#download-fx and will now see an identical "scene 2" to non-firefox users visiting that URL, including an automatic download of the current firefox. 2. Users visiting https://www-demo4.allizom.org/en-US/firefox/new/ *without* the #download-fx at the end will see the same "scene 1" they do today in prod. :Habber and :cmore, please take a look and verify that this is the behavior you expected.

(In reply to Josh Mize [:jgmize] from comment #30) > With the latest push to demo4, we now have the following behavior for > up-to-date firefox users: > > 1. Users clicking the download button on > https://www-demo4.allizom.org/en-US/ will be sent to > https://www-demo4.allizom.org/en-US/firefox/new/#download-fx and will now > see an identical "scene 2" to non-firefox users visiting that URL, including > an automatic download of the current firefox. > > 2. Users visiting https://www-demo4.allizom.org/en-US/firefox/new/ *without* > the #download-fx at the end will see the same "scene 1" they do today in > prod. > > > :Habber and :cmore, please take a look and verify that this is the behavior > you expected. This is working as expected. Thanks! Also, fyi: in the upcoming homepage redesign we will solve when it is appropriate to display the download button on that page. We are also working on the separate issue of a better way to surface the "download a fresh copy" link for those that need it on /new.

Sounds good to me! Thanks

I took a look at a number of OS/Browsers. I filed bug 1063000 about a prod&stage IE issue. I verified links, the download button URl, going directly to /firefox/new, different page sizes, and a variety of locales- it all looks good.

Commits pushed to master at https://github.com/mozilla/bedrock https://github.com/mozilla/bedrock/commit/4dfd50e4da2b4fc1763d2094f6323f0a789b3b67 Change download buttons to point to /firefox/new/ Download links will point to the second scene of download page with the url fragment /firefox/new/#download-fx Bug 874913 Remove LOCALES_WITH_TRANSITION list and behaviour https://github.com/mozilla/bedrock/commit/31f20461d9a94e006af1043d6559e5964af57055 Merge pull request #2221 from mozilla/bug-874913-download-fx Bug 874913 download fx

This has been pushed to prod & looks good.