Closed Bug 979599 Opened 6 years ago Closed 6 years ago

Show Australis tour page upon update for en-US on Beta

Categories

(Release Engineering :: Release Requests, defect)

defect
Not set

Tracking

(firefox29+ fixed, firefox30 wontfix)

RESOLVED FIXED
Tracking Status
firefox29 + fixed
firefox30 --- wontfix

People

(Reporter: MattN, Assigned: nthomas)

References

()

Details

(Whiteboard: [Australis:P1])

Attachments

(2 files)

+++ This bug was initially created as a clone of Bug #966014 +++

Tweak the code and follow-up fix from bug 966014 to make it work for Beta too since we are just doing the tour for en-US there too.

The downside is that this means we're not testing what we're shipping on release.

This fix shouldn't land on m-c and this needs to be in the first beta 29 build.
Sorry, I forgot that targeting the snippet by locale was only a problem on Nightly and Aurora due to balrog being used there and bug 748698 not being fixed.

The whatsnew page for beta can be specified in the snippet from the update server.
Assignee: MattN+bmo → nobody
No longer blocks: 967123
Status: ASSIGNED → NEW
Component: General → Releases
No longer depends on: 966014
Priority: P1 → --
Product: Firefox → Release Engineering
QA Contact: rail
Whiteboard: [Australis:P1]
Version: 29 Branch → unspecified
Your example
 https://www.mozilla.org/en-US/firefox/29.0/whatsnew/
is en-US, should we localising that for all locales ?
Assignee: nobody → nthomas
Blocks: 961833
Hi Nick-

We will localize for all locales for the fx 29 release for general audience on April 29.

Thx,
Jen
(In reply to Nick Thomas [:nthomas] from comment #2)
> Your example
>  https://www.mozilla.org/en-US/firefox/29.0/whatsnew/
> is en-US, should we localising that for all locales ?

See the summary, this is only for en-US in beta and all locales in release.
*opens eyes*  Thanks!
Requires the patch on bug 892972. Otherwise we can do the same as
 https://wiki.mozilla.org/Releases/Firefox_25.0/BuildNotes
Attachment #8392130 - Flags: review?(bhearsum)
Over to catlee or rail, whoever takes bug 961833 in order to do 29.0b1.
Assignee: nthomas → nobody
(In reply to Nick Thomas [:nthomas] from comment #6)
> Requires the patch on bug 892972. Otherwise we can do the same as
>  https://wiki.mozilla.org/Releases/Firefox_25.0/BuildNotes

Adding dependency.
Depends on: 892972
Attachment #8392130 - Flags: review?(bhearsum) → review+
Comment on attachment 8392130 [details] [diff] [review]
[tools] Tweak beta patcher config

Review of attachment 8392130 [details] [diff] [review]:
-----------------------------------------------------------------

::: release/patcher-configs/mozBeta-branch-patcher2.cfg
@@ +2,5 @@
>      <Firefox>
>          <current-update>
> +            actions   showURL
> +            action-locales   en-US
> +            openURL   https://www.mozilla.org/%locale%/firefox/29.0/whatsnew/

In-product in the past and for Aurora we used
https://www.mozilla.org/%LOCALE%/firefox/%VERSION%/whatsnew/?oldversion=%OLD_VERSION%

Is the oldversion query parameter something that also works in this system? Apologies for forgetting about that parameter when I filed the bug. I know people were looking at the data coming from this parameter on Aurora so it has some value. I don't think this is a blocker but someone else may feel differently.
Juan can you make sure this is tested in 29.0b1 sign off (having the localized what's new pages in localized builds)?
Flags: needinfo?(jbecerra)
Setting owner to apparent reality.
Assignee: nobody → nthomas
Is there anything we need to do for the stub installer version of this?
Flags: needinfo?(jbecerra) → needinfo?(nthomas)
One more thing, when I install a es-ES version of Fx29b1(build2), should I be landing on https://www.mozilla.org/es-ES/firefox/29.0/whatsnew/ and be redirected to the en-US version? Because I get https://www.mozilla.org/es-ES/firefox/29.0/firstrun/ instead.
(In reply to juan becerra [:juanb] from comment #13)
> One more thing, when I install a es-ES version of Fx29b1(build2), should I
> be landing on https://www.mozilla.org/es-ES/firefox/29.0/whatsnew/ and be
> redirected to the en-US version? Because I get
> https://www.mozilla.org/es-ES/firefox/29.0/firstrun/ instead.

One thing I want to clarify first is that this bug is about the whatsnew page being shown after an update. It would be good for QA to also verify the firstrun experience too but there isn't a product bug for that since we've been showing the same URL from the product on firstrun for a long time. If the content is wrong on firstrun, I guess you can comment in bug 975099 or file a blocking bug.

Now to your question, I'm not sure if you're saying you did a new install and/or used a new profile or if you are talking about updating an existing profile?

With this bug, en-US users should see a tour page whereas other locales should not since the page isn't localized yet and we don't want to show those users an English page. Hopefully that clarifies a bit.
Thanks Matt.

So, to verify this for beta 1:
1. From an earlier version, for example 28.b1, update to 29.b1
- You should get a whatsnew page, with content explaining the new Australis theme
- Localized builds should not be shown a whatsnew page (once the official 29.0 goes out, this will change)
(In reply to juan becerra [:juanb] from comment #15)
> - Localized builds should not be shown a whatsnew page (once the official
> 29.0 goes out, this will change)

I'm honestly not sure whether localized builds should be shown a whatsnew page, I just know that if they see a page, it shouldn't be a tour page and should be localized. If we normally show a whatsnew page on beta/release updates then I guess we're doing the same?
I just double-checked with agibson and what we talked about before was that there shouldn't be any whatsnew page opened for localized builds and it looks like that is what the patch is doing but nthomas can hopefully confirm.

What you said in comment 15 should be correct for beta 29.
Since at least Firefox 24 we have been suppressing whatsnew pages, so this bug has just turned it on for en-US, per the request.

> In-product in the past and for Aurora we used
> https://www.mozilla.org/%LOCALE%/firefox/%VERSION%/whatsnew/
> ?oldversion=%OLD_VERSION%
> 
> Is the oldversion query parameter something that also works in this system?
> Apologies for forgetting about that parameter when I filed the bug. I know
> people were looking at the data coming from this parameter on Aurora so it
> has some value. I don't think this is a blocker but someone else may feel
> differently.

I would need to test, but a quick read of the code (in browser/components/nsBrowserContentHandler.js) indicates that we could in include '?oldversion=%OLD_VERSION%' in the request. Firefox would replace %OLD_VERSION% with the user specific value. Please let us know if you would like to proceed with that.
Flags: needinfo?(nthomas)
(In reply to Nick Thomas [:nthomas] from comment #18)
> Please let us know if you would like to proceed with that.

Yes, that would be ideal, if possible.
Status: NEW → ASSIGNED
Flags: needinfo?(nthomas)
Are you fine with not having the "oldversion" parameter in beta 1? It would require a rebuild which we'd rather avoid.
Flags: needinfo?(jbertsch)
Flags: needinfo?(chrismore.bugzilla)
Actually just a change to the update configuration, but QA have tested whatsnew for 29.0b1 already and have less people around this week.
Flags: needinfo?(nthomas)
Did a spot test with oldversion in the url (a 28.0b9 --> 29.0b1 update) and this was loaded after the update:
 https://www.mozilla.org/en-US/firefox/29.0/whatsnew/?oldversion=28.0
And our tooling supports it OK.

There is followup issue to not use the whatsnew for updates starting from a 29.0 beta, another bug is probably better for that.
(In reply to Matthew N. [:MattN] from comment #20)
> Are you fine with not having the "oldversion" parameter in beta 1? It would
> require a rebuild which we'd rather avoid.

Oldversion in the URL is helpful, but I currently am not using it. We usually use that data when investigating a cohort of users who are going through the download/install funnel. For the beta test, if it is not there, I am not going to worry about it.
Flags: needinfo?(chrismore.bugzilla)
(In reply to Chris More [:cmore] from comment #23)
> (In reply to Matthew N. [:MattN] from comment #20)
> > Are you fine with not having the "oldversion" parameter in beta 1? It would
> > require a rebuild which we'd rather avoid.
> 
> Oldversion in the URL is helpful, but I currently am not using it. We
> usually use that data when investigating a cohort of users who are going
> through the download/install funnel. For the beta test, if it is not there,
> I am not going to worry about it.

+1
Flags: needinfo?(jbertsch)
As requested above.
Attachment #8395949 - Flags: review?(rail)
Attachment #8395949 - Flags: review?(rail) → review+
MattN, jbertsch: do we want to open the whatsnew page after updates to 29.0b2 ? That beta is spinning right now and will show it, but we have to change that before it goes live in a day or so.

What about later betas ?
Flags: needinfo?(MattN+bmo)
Comment on attachment 8395949 [details] [diff] [review]
[tools] Add oldversion query

Landed in time for 29.0b2
https://hg.mozilla.org/build/tools/rev/3793d09f0472
Attachment #8395949 - Flags: checked-in+
(In reply to Nick Thomas [:nthomas] from comment #26)
> MattN, jbertsch: do we want to open the whatsnew page after updates to
> 29.0b2 ? That beta is spinning right now and will show it, but we have to
> change that before it goes live in a day or so.
> 
> What about later betas ?

All of the beta 29 updates should continue to have the whatsnew URL offered. Since the milestone version will still be 29.0 (with no beta # indicator), the whatsnew page shouldn't be shown again to users upgrading from beta 1 (contrary to what you thought on IRC the other day).
Flags: needinfo?(MattN+bmo)
Right you are, I'll wrap my head around this properly one day. It's surprising to me that we can't turn on whatsnew *during* a beta cycle.

Anyway, with the ?oldversion=%OLD_VERSION% added to the url I think we're done here. How are we tracking removing it again ?
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
(In reply to Nick Thomas [:nthomas] from comment #29)
> Anyway, with the ?oldversion=%OLD_VERSION% added to the url I think we're
> done here. How are we tracking removing it again ?

Thanks! I don't have a bug filed to remove this. I can file one now to both remove this for beta and enable it for release.
Updating the flag I missed. We had this in place starting at 29.0b1.
I've verified this bug using FF beta 29.0b4 and in some cases after the update the Ui Tour is not correctly displayed. I've logged bug 991081 describing this issue.
Depends on: 991081
No longer depends on: 991081
You need to log in before you can comment on or make changes to this bug.