The default bug view has changed. See this FAQ.

Show Australis whatsnew tour page upon update for all locales on Firefox 29 release builds

RESOLVED FIXED

Status

Release Engineering
Releases
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: MattN, Unassigned)

Tracking

unspecified
Dependency tree / graph

Firefox Tracking Flags

(firefox29+ affected)

Details

(Whiteboard: [Australis:P1][qa+], URL)

Attachments

(1 attachment, 1 obsolete attachment)

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

For the release of Firefox 29, the whatsnew page with the following URL should be enabled for all locales:

https://www.mozilla.org/%LOCALE%/firefox/%VERSION%/whatsnew/?oldversion=%OLD_VERSION%

The en-us version for beta 29 from bug 979599 should be disabled before 30b1.
Adding Firefox 29.0 tracking bug.
Blocks: 978746
Created attachment 8396119 [details] [diff] [review]
[tools] Modify patcher configs

Requested:
https://www.mozilla.org/%LOCALE%/firefox/%VERSION%/whatsnew/?oldversion=%OLD_VERSION%
I'm setting:
https://www.mozilla.org/%locale%/firefox/29.0/whatsnew/?oldversion=%OLD_VERSION%

Notes
* %OLD_VERSION% is interpolated by Firefox at run time
* we interpolate %locale% (nb lower case) when generating snippets, using getOptionalAttrs() in tools/lib/python/release/updates/patcher.py
* we don't have version interpolation at the moment (and pass the old version to the existing getOptionalAttrs() call), so hardcode the '29.0'. There's a risk here that we forget to bump to 29.0.1 for a chemspill.
Just for fun, bug 976735 will use funnelcake to do something different with en-US users.
tracking-firefox29: ? → +
Nick, are you planning to make the attachment 8396119 [details] [diff] [review] land in Firefox 29? Thanks
Flags: needinfo?(nthomas)
It should land in a RelEng repo (http://hg.mozilla.org/build/tools/) before 29 starts building, but after any change for a 28.0.x chemspill. catlee is going to be doing 29.0, and 
  https://bugzilla.mozilla.org/show_bug.cgi?id=978746#c2
has a commment on what needs to be landed.
Flags: needinfo?(nthomas)
To better handle the pave-over install case we decided to set the whatsnew pref in-product in bug 987407. This bug is technically not required anymore as I understand it.

Note that someone should still remove the whatsnew URL from mozBeta-branch-patcher2.cfg (after bug 987407 lands) so perhaps we can morph this bug into just that cleanup? If it's easier for RelEng to proceed with also offering the whatsnew page in the snippet, then that's also fine as there shouldn't be a conflict in having both.
Flags: needinfo?(nthomas)
I think we still need to send the whatsnew url in the update info, because of
  http://hg.mozilla.org/releases/mozilla-beta/file/default/browser/components/nsBrowserContentHandler.js#l167

Looks like leaving actions=silent in, or not specifying actions=showURL results in the pref from
  http://hg.mozilla.org/releases/mozilla-beta/file/default/browser/components/nsBrowserContentHandler.js#l593
being blanked out to "". Do you agree ?
Flags: needinfo?(nthomas)
(In reply to Nick Thomas [:nthomas] from comment #7)
> I think we still need to send the whatsnew url in the update info, because of
>  
> http://hg.mozilla.org/releases/mozilla-beta/file/default/browser/components/
> nsBrowserContentHandler.js#l167
> 
> Looks like leaving actions=silent in, or not specifying actions=showURL
> results in the pref from
>  
> http://hg.mozilla.org/releases/mozilla-beta/file/default/browser/components/
> nsBrowserContentHandler.js#l593
> being blanked out to "". Do you agree ?

Good catch, we would need to remove actions=silent but a few lines higher it falls back to what's in the product if no actions are specified:
 http://hg.mozilla.org/releases/mozilla-beta/file/default/browser/components/nsBrowserContentHandler.js#l161
Nick, Matthew, can any of you please confirm if "showURL" is now the expected value for the actions parameter? According to comment 8, the 'silent' value has been removed. Also, on that note, the 'What's new' page displayed upon update is: 'https://www.mozilla.org/en-us/firefox/29.0/whatsnew/?oldversion=28.0'
Flags: needinfo?(nthomas)
Flags: needinfo?(MattN+bmo)
Created attachment 8407175 [details] [diff] [review]
[tools] Modify patcher configs, v2

This sets up beta and release to not send action=silent in update data, so that we fall back to the in-app pref to show the whatsnew page. This would allow us to test the pref is working properly with 29.0b9 later this week, before we spin 29.0 for real. The tester would need to set the pref browser.startup.homepage_override.mstone to something older than '29.0'.

What do you think ?  Probably we'd put actions=silent back on beta afterwards.
Attachment #8407175 - Flags: feedback?

Updated

3 years ago
Attachment #8407175 - Flags: feedback? → feedback?(MattN+bmo)
Comment on attachment 8407175 [details] [diff] [review]
[tools] Modify patcher configs, v2

per irc, we decided to go with simplicity, and we know sending showURL works from beta updates, so we'll use the earlier patch.
Attachment #8407175 - Attachment is obsolete: true
Attachment #8407175 - Flags: feedback?(MattN+bmo)
Flags: needinfo?(nthomas)

Updated

3 years ago
Attachment #8396119 - Flags: review?(catlee)
(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #9)
> Nick, Matthew, can any of you please confirm if "showURL" is now the
> expected value for the actions parameter? According to comment 8, the
> 'silent' value has been removed. Also, on that note, the 'What's new' page
> displayed upon update is:
> 'https://www.mozilla.org/en-us/firefox/29.0/whatsnew/?oldversion=28.0'

Yes, we're using going to use actions=showURL in the update offer for release builds, same as beta. The url looks almost right, en-US instead of en-us.
Flags: needinfo?(MattN+bmo)
Comment on attachment 8396119 [details] [diff] [review]
[tools] Modify patcher configs

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

::: release/patcher-configs/mozBeta-branch-patcher2.cfg
@@ -14,3 @@
>              force   force_plist_reload
>              from   29.0b1
> -            openURL   https://www.mozilla.org/%locale%/firefox/29.0/whatsnew/?oldversion=%OLD_VERSION%

sorry, why are we removing these from beta?
The beta whatsnew was there for Australis on 29.0b. Once we get to 30.0b1 we don't want/need to have a whatsnew any more.
That is correct.  Thanks Nick!

Updated

3 years ago
Attachment #8396119 - Flags: review?(catlee) → review+
Attachment #8396119 - Flags: checked-in+
marking fixed on 29 since it's been checked in.
status-firefox29: affected → fixed
putting this back to affected as we haven't confirmed locales are showing localized content
status-firefox29: fixed → affected
Can we get this verified today? We need to make sure this is working before tomorrow (Tuesday/release day).
Keywords: qaurgent, qawanted
Whiteboard: [Australis:P1] → [Australis:P1][qa!]
I have spot checked a few locales, with a few scenarios across platforms, and we are getting correct, localized content for firstrun and whatsnew pages, for example:

https://www.mozilla.org/ja/firefox/29.0/whatsnew/?oldversion=27.0.1
https://www.mozilla.org/zh-CN/firefox/29.0/whatsnew/?oldversion=27.0.1
https://www.mozilla.org/es-ES/firefox/29.0/whatsnew/?oldversion=28.0

https://www.mozilla.org/es-ES/firefox/29.0/firstrun/
https://www.mozilla.org/ja/firefox/29.0/firstrun/
https://www.mozilla.org/zh-CN/firefox/29.0/firstrun/

This is a list of locales with these pages translated and deployed:

http://l10n.mozilla-community.org/~pascalc/langchecker/?locale=all&website=0&file=firefox/australis/firefox_tour.lang

There's only one exception, zh-TW, which is not redirecting to the right pages, but which should be done tomorrow once the following pull request is approved and merged: https://github.com/mozilla/bedrock/pull/1930

Once that's done we can mark this as verified.
Here's the new PR to fix  the zh-TW redirect https://github.com/mozilla/bedrock/pull/1931
A couple of update spot checks show the correct landing page now:

https://www.mozilla.org/zh-TW/firefox/29.0/whatsnew/?oldversion=27.0.1

Also: https://www.mozilla.org/zh-TW/firefox/29.0/firstrun/

So I am marking this as verified taking into consideration that not all of the locales were ready and deployed per:

http://l10n.mozilla-community.org/~pascalc/langchecker/?locale=all&website=0&file=firefox/australis/firefox_tour.lang
Keywords: qaurgent, qawanted
So we now have 29.0.1 so I'm wondering it's possible to silence whatsnew for updates from 29.0.0 so those users don't see the tour a second time. Is that straightforward with our current infrastructure?
Flags: needinfo?(nthomas)

Comment 23

3 years ago
(In reply to Matthew N. [:MattN] (behind on reviews) from comment #22)
> So we now have 29.0.1 so I'm wondering it's possible to silence whatsnew for
> updates from 29.0.0 so those users don't see the tour a second time. Is that
> straightforward with our current infrastructure?

What about if we do it from the website side where we don't show the whatsnew tour for 29.0.1 users when ?oldversion=29.0 ?
Nick, can you remove the whatsnew page from the update xml for going from 29 to 29.0.1, etc. per the following?

(In reply to Matthew N. [:MattN] (behind on reviews) from comment #22)
> So we now have 29.0.1 so I'm wondering it's possible to silence whatsnew for
> updates from 29.0.0 so those users don't see the tour a second time. Is that
> straightforward with our current infrastructure?
Note: It might also be a good thing to handle this on the website since this will only remove opening the page for the user performing the update and secondary users will still open the whatsnew page though I am not as familiar with that code.
(In reply to Chris More [:cmore] from comment #23)
> What about if we do it from the website side where we don't show the
> whatsnew tour for 29.0.1 users when ?oldversion=29.0 ?

We can add some logic in bedrock to only show the post-tour web page when ?oldversion=29.0
Filed a PR for this change: https://github.com/mozilla/bedrock/pull/1978
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #24)
> Nick, can you remove the whatsnew page from the update xml for going from 29
> to 29.0.1, etc. per the following?
> 
> (In reply to Matthew N. [:MattN] (behind on reviews) from comment #22)
> > So we now have 29.0.1 so I'm wondering it's possible to silence whatsnew for
> > updates from 29.0.0 so those users don't see the tour a second time. Is that
> > straightforward with our current infrastructure?

Note that it needs to be silenced (not just removed IIUC) so that it prevents the in-product whatsnew URL from being used.
(In reply to Matthew N. [:MattN] (behind on reviews) from comment #28)
> (In reply to Robert Strong [:rstrong] (use needinfo to contact me) from
> comment #24)
> > Nick, can you remove the whatsnew page from the update xml for going from 29
> > to 29.0.1, etc. per the following?
> > 
> > (In reply to Matthew N. [:MattN] (behind on reviews) from comment #22)
> > > So we now have 29.0.1 so I'm wondering it's possible to silence whatsnew for
> > > updates from 29.0.0 so those users don't see the tour a second time. Is that
> > > straightforward with our current infrastructure?
> 
> Note that it needs to be silenced (not just removed IIUC) so that it
> prevents the in-product whatsnew URL from being used.
For the user performing the update that is possible using the update xml as it is possible to define the url that is opened. For a user that is not performing an update that is changing versions that is entirely outside of the control of app update and the update advertisement. That is controlled by the code that I am not familiar with and affects a much smaller number of users. I believe that Gavin knows that code, what conditions cause it to open the whatsnew page, and the url it opens.

Comment 30

3 years ago
Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/1ad328381ff9c6005feca6f7756d7fca70b6641f
Bug 987480: Do not show whatsnew tour when upgrading from 29.0.

https://github.com/mozilla/bedrock/commit/f79d3994e6623b1d0673350e189a820dd8a85949
Merge pull request #1978 from pmclanahan/hide-tour-whatsnew-upgrade-29-987480

Bug 987480: Do not show whatsnew tour when upgrading from 29.0.
(In reply to Matthew N. [:MattN] (behind on reviews) from comment #22)
> So we now have 29.0.1 so I'm wondering it's possible to silence whatsnew for
> updates from 29.0.0 so those users don't see the tour a second time. Is that
> straightforward with our current infrastructure?

Yes, we could set "actions=silent" for updates from 29.0 and show no whatsnew page, which will override the in-app preference we have set at the moment. Is that still necessary given the website changes just landed ?
Flags: needinfo?(nthomas)
We haven't been showing any whatsnew page after an update for quite some time unless we have a major announcement such as australis so it would be a "good thing" to add it back since we have decided that showing the whatsnew page after an update is not what we want to typically do.
Also, for future releases unless we have a specific communication we want to show users that they haven't seen already the default should be "actions=silent".
Ok, I'll go ahead and modify the updates for 29.0 to supppress what's new.

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #33)
> Also, for future releases unless we have a specific communication we want to
> show users that they haven't seen already the default should be
> "actions=silent".

Will handle this in bug 996137 for Firefox 30.0, but leave the existing situation until we get closer to that.
Also, nothing specified is the same as "actions=silent" so you should be able to just not define any actions in the update xml.
I'd agree with that in normal times, but startup.homepage_override_url isn't null on release right now.
bah... thanks for letting me know about that!

Updated

3 years ago
Whiteboard: [Australis:P1][qa!] → [Australis:P1][qa+]

Updated

3 years ago
Blocks: 1006829
This was successful. We kept whatsnew on for 30 in bug 1009893.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.