789422 - actions="silent" not working for Firefox 15.0 -> 15.0.1 updates (What's New page is shown)

Status: VERIFIED FIXED

(Toolkit :: Application Update, defect)

Description

[Nick Thomas [:nthomas] (UTC+12)]

Steps to reproduce
1, Install https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/15.0/mac/en-US/Firefox%2015.0.dmg
2, Firefox > About Firefox
3, let the partial download & get staged, and then hit 'Restart to update' button

Expected results
No What's New page shown

Actual results:
http://www.mozilla.org/en-US/firefox/15.0.1/whatsnew/?oldversion=15.0

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

I suspect there's some state not being saved properly when we stage the update in the background.

Prior to applying the update, active-update.xml is:
<updates xmlns="http://www.mozilla.org/2005/app-update"><update appVersion="15.0.1" buildID="20120905151427" channel="release" displayVersion="15.0.1" extensionVersion="15.0.1" installDate="1347009570323" isCompleteUpdate="false" name="Firefox 15.0.1" serviceURL="https://aus3.mozilla.org/update/3/Firefox/15.0/20120824154833/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/release/Darwin%2010.8.0/default/default/update.xml?force=1" showNeverForVersion="false" showPrompt="false" showSurvey="false" type="minor" version="15.0.1" detailsURL="https://www.mozilla.com/en-US/firefox/15.0.1/releasenotes/" platformVersion="15.0.1" previousAppVersion="15.0" statusText="Install Pending" actions="silent" foregroundDownload="true"><patch type="complete" URL="http://download.mozilla.org/?product=firefox-15.0.1-complete&amp;os=osx&amp;lang=en-US&amp;force=1" hashFunction="SHA512" hashValue="d67113d018ea7e07b023a625d92bad4595cbbeaf827658d01c2aa4988f2349daeb66900d236568044c780c601ebaac2df086c760b0a544b9b6119a26ede76257" size="33111821" selected="undefined" state="null"/><patch type="partial" URL="http://download.mozilla.org/?product=firefox-15.0.1-partial-15.0&amp;os=osx&amp;lang=en-US&amp;force=1" finalURL="http://download.cdn.mozilla.net/pub/mozilla.org/firefox/releases/15.0.1/update/mac/en-US/firefox-15.0-15.0.1.partial.mar" hashFunction="SHA512" hashValue="8a8a2045aeffed4c91ecc2f0d78a46f4685812170f38f3e3ec25874daaf6771a7a1a653d0bc5a5629b8adb41c708c26671491f37250bcf2c7bba3bb3a9d060a7" size="1761475" selected="true" state="applied"/></update></updates>

NB: state="applied"; actions="silent" from the offer means that whatsnew should not be opened (http://hg.mozilla.org/releases/mozilla-release/file/FIREFOX_15_0_1_RELEASE/browser/components/nsBrowserContentHandler.js#l160)

updates.xml is
<updates xmlns="http://www.mozilla.org/2005/app-update"/>

-----

After the restart the content of active-update.xml is the same, except that it's now state="pending". updates.xml is still without useful content.

A little later (I have app.update.interval set to 60 for another reason) active-update.xml gets wiped; updates.xml still content less.

So I'm wondering if the call in nsBrowserContentHandler.js ends up looking at updates.xml and hence doesn't find the actions="silent".

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

The whatsnew page is suppressed for          (all testing mac/en-US)
 * 13.0.1 --> 15.0.1
 * 14.0.1 --> 15.0.1
 * 15.0   --> 15.0.1  with app.update.stage.enabled set to false
which confirms a regression from bug 307181.

In terms of user fallout the following groups are probably seeing the unwanted whatsnew page
* brand new users that installed 15.0 since it came out
* older users that already updated to 15.0, and their previous update showed a whatsnew, which was the top locale list of 
  en-US en-GB fr it de es-ES es-AR es-CL es-MX ja ja-JP-mac ko ru

Comment 3

[Alex Keybl [:akeybl]]

Assigning to Ehsan and tracking for FF16, since we'll want to address this in our next release.

Juan - can you check to make sure this problem isn't Mac-only? Both Nick and Axel were using OS X to test.

Comment 4

[(no longer active)]

I'm not quite familiar with what exactly triggers the whatsnew page.  Robert, can you please tell me what I should precisely be expecting in updates.xml and active-update.xml, and also, where those values should be set?

Comment 5

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

The app.update.postupdate pref is set by app update
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.js#1656

browser code takes it from there

Comment 7

[juan becerra [:juanb]]

Fresh installation, new profile, en-US, 15.0 -> 15.0.1 on Win7 and Win8 I do not see a whatsnew page.

Comment 8

[Terry R.]

This is appearing on Windows also, as I answer the Mozilla webmaster email, and after receiving enough of them, filed https://bugzilla.mozilla.org/show_bug.cgi?id=789475 .  

This issue has come up before on prior releases, although not in at least the last few.

Comment 9

[(no longer active)]

The bug happens because we don't make sure that the updates/0 directory exists before writing update.status to it, so the WriteStatusFile function fails, which causes the status code to not be updated the next time that Firefox starts up.

Comment 10

[(no longer active)]

Attachment: Part 1: Remove UpdateStatusText because it does the exact same thing as UpdateStatusFile(const char*)

This patch just refactors the code so that we don't have the same function repeated twice.

Comment 11

[(no longer active)]

Attachment: Part 2: Ensure that the update.status directory exists before attempting to write to it

This is the real fix.

Comment 12

[Brian R. Bondy [:bbondy]]

Still the wrong patches

Comment 13

[(no longer active)]

Attachment: Part 1: Remove UpdateStatusText because it does the exact same thing as UpdateStatusFile(const char*)

Sorry, working on too many bugs at the same time. :(

Comment 14

[(no longer active)]

Attachment: Part 2: Ensure that the update.status directory exists before attempting to write to it

Comment 15

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f7e36dada4ff
https://hg.mozilla.org/integration/mozilla-inbound/rev/8f24b5819c22

Comment 16

[(no longer active)]

Comment on attachment 659510 [details] [diff] [review]
Part 1: Remove UpdateStatusText because it does the exact same thing as UpdateStatusFile(const char*)

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 307181.
User impact if declined: Continued displaying of what's new pages for minor updates
Testing completed (on m-c, etc.): locally
Risk to taking this patch (and alternatives if risky): the failure is well understood and the patch which actually fixes this (part 2) is very small and low-risk.
String or UUID changes made by this patch: none.

Comment 17

[(no longer active)]

Backed out the patches <https://hg.mozilla.org/integration/mozilla-inbound/rev/7c1611a68000> because of test failures: <https://tbpl.mozilla.org/php/getParsedLog.php?id=15110605&tree=Mozilla-Inbound&full=1#error0>

Comment 18

[(no longer active)]

Attachment: Part 3: Update the unit tests

So, it turns out that our unit tests had a check for this but were expecting the wrong behavior.  This patch fixes that.

(Note that strictly, only the change to toolkit/mozapps/update/test/unit/test_0201_app_launch_apply_update.js is needed, but I changed the rest of the tests for consistency even though they'll only get run on Windows.)

Comment 19

[(no longer active)]

https://tbpl.mozilla.org/?tree=Try&rev=83d791797c06

Comment 20

[Mozilla RelEng Bot]

Try run for 83d791797c06 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=83d791797c06
Results (out of 16 total builds):
    success: 16
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-83d791797c06

Comment 21

[u279076]

Added a MozTrap testcase to cover this for future releases. Henrik, is this something we can automate in Mozmill? Basically...

If actions="silent" in update.xml -> no what's new page after update
Else -> what's new page after update

Comment 22

[u279076]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #21)
> Added a MozTrap testcase to cover this for future releases. Henrik, is this
> something we can automate in Mozmill? Basically...
> 
> If actions="silent" in update.xml -> no what's new page after update
> Else -> what's new page after update

Sorry, I forgot to link the testcase:
https://moztrap.mozilla.org/manage/cases/_detail/6448/

Comment 23

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8700c0c59802
https://hg.mozilla.org/integration/mozilla-inbound/rev/b3dc4cd6b126
https://hg.mozilla.org/integration/mozilla-inbound/rev/8cc774a223fd

Comment 24

[Alex Keybl [:akeybl]]

Comment on attachment 659510 [details] [diff] [review]
Part 1: Remove UpdateStatusText because it does the exact same thing as UpdateStatusFile(const char*)

[Triage Comment]
Approving for Aurora/Beta so that future updates are completely silent.

Note to QA: verification will require an update from FF16->FF17 on Aurora and FF15->FF16 on Beta.

Comment 25

[(no longer active)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/b836150c9cba
https://hg.mozilla.org/releases/mozilla-aurora/rev/0e3f1e36153b
https://hg.mozilla.org/releases/mozilla-aurora/rev/1eb3ba759678
https://hg.mozilla.org/releases/mozilla-beta/rev/bdf8bdfe315e
https://hg.mozilla.org/releases/mozilla-beta/rev/05375a12ab05
https://hg.mozilla.org/releases/mozilla-beta/rev/45d2eeca9b46

Comment 26

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/8700c0c59802
https://hg.mozilla.org/mozilla-central/rev/b3dc4cd6b126
https://hg.mozilla.org/mozilla-central/rev/8cc774a223fd

Comment 27

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #22)
> > Added a MozTrap testcase to cover this for future releases. Henrik, is this
> > something we can automate in Mozmill? Basically...
> > 
> > If actions="silent" in update.xml -> no what's new page after update
> > Else -> what's new page after update
> 
> Sorry, I forgot to link the testcase:
> https://moztrap.mozilla.org/manage/cases/_detail/6448/

Sure, we can perfectly include such a check in our update tests. Depending on the state of `actions` we will ensure that a what's new page is shown or not. I will file a new bug to cover the Mozmill Test work.

Comment 28

[Terry R.]

The Mozilla webmaster email address has had dozens of complaints about this issue since v15 was released.  I can't imagine how many millions of users believe that this is Mozilla pushing FF for Android with aggressive advertising.

What is the possibility to get a patch pushed to the current release, as most users are doing the only thing they can do to get rid of this tab that takes focus every time FF is launched?  I believe it may stop thousands if not millions of defections.

Comment 29

[Robert Kaiser]

(In reply to Terry R. from comment #28)
> I can't imagine how many millions of users
> believe that this is Mozilla pushing FF for Android with aggressive
> advertising.

Actually, the emails about the Android stuff might be some stuff that is on about:home as a "snippet" that is quite a bit into-your-face. I wish we had a simple thing there to opt out of animated about:home snippets altogether.

Comment 30

[Terry R.]

(In reply to Robert Kaiser (:[e-mail]) from comment #29)
> (In reply to Terry R. from comment #28)
> > I can't imagine how many millions of users
> > believe that this is Mozilla pushing FF for Android with aggressive
> > advertising.
> 
> Actually, the emails about the Android stuff might be some stuff that is on
> about:home as a "snippet" that is quite a bit into-your-face. I wish we had
> a simple thing there to opt out of animated about:home snippets altogether.

No, what I'm referring to is specifically regarding the extra tab with "Hooray!..." that takes focus away from the default home page.

I have a fix I send out to remove the Snippets from the about:home page.  That isn't an issue, as it works perfectly using the UserStyles addon.

Comment 31

[u279076]

Verified fixed with:
 * Firefox 17.0a1 2012-08-27 -> Firefox 18.0a1 2012-09-18
 * Firefox 16.0a2 2012-08-27 -> Firefox 17.0a2 2012-09-18

Firefox 15.0b6 en-US -> Firefox 16.0b3 en-US still reproduces this issue (ie. displays the what's new page). Did this patch make the cut-off for 16.0b3?

Comment 32

[Alex Keybl [:akeybl]]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #31)
> Firefox 15.0b6 en-US -> Firefox 16.0b3 en-US still reproduces this issue
> (ie. displays the what's new page). Did this patch make the cut-off for
> 16.0b3?

It made the cut, so I've pinged Ehsan to take a look.

Comment 33

[(no longer active)]

This bug is fixed in the updater code, and it was never landed on 15, so the last paragraph of comment 31 is expected.

Comment 34

[u279076]

Based on comment 33 I would assume this is not verifiable for *any* branch until after the next migration date. In other words, it's not testable until we have major-version updates for the fixed builds.

For example:
 * 18.0a1 2012-09-12 -> 19.0a1 latest
 * 17.0a2 2012-09-12 -> 18.0a2 latest
 * 16.0b3 -> 17.0b1

Is this true?

Comment 35

[(no longer active)]

(In reply to comment #34)
> Based on comment 33 I would assume this is not verifiable for *any* branch
> until after the next migration date. In other words, it's not testable until we
> have major-version updates for the fixed builds.
> 
> For example:
>  * 18.0a1 2012-09-12 -> 19.0a1 latest
>  * 17.0a2 2012-09-12 -> 18.0a2 latest
>  * 16.0b3 -> 17.0b1
> 
> Is this true?

Yeah probably, but I guess RelEng can set up fake major updates on a given channel.

Comment 36

[u279076]

(In reply to Ehsan Akhgari [:ehsan] from comment #35)
> Yeah probably, but I guess RelEng can set up fake major updates on a given
> channel.

Reverting the VERIFIED state of this bug.

Akeybl, my recommendation is that we just wait 3 weeks and verify it after the next migration. I'd rather test this with *real* snippets rather than fake ones.

Comment 37

[Alex Keybl [:akeybl]]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #36)
> (In reply to Ehsan Akhgari [:ehsan] from comment #35)
> > Yeah probably, but I guess RelEng can set up fake major updates on a given
> > channel.
> 
> Reverting the VERIFIED state of this bug.
> 
> Akeybl, my recommendation is that we just wait 3 weeks and verify it after
> the next migration. I'd rather test this with *real* snippets rather than
> fake ones.

Sounds good. And I filed bug 792181 for making FF15->16 silent.

Comment 38

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to Ehsan Akhgari [:ehsan] from comment #35)
> (In reply to comment #34)
> > Based on comment 33 I would assume this is not verifiable for *any* branch
> > until after the next migration date. 
> Yeah probably, but I guess RelEng can set up fake major updates on a given
> channel.

I don't think we can fake an update offer to do this, as the actual app version needs to change to tickle the what's new logic post-update. But we could take any 15.0 beta and copy an the updater which includes the fix, then update via a complete and see if WN is suppressed.

Comment 39

[u279076]

If it's all the same to everyone else, I'd rather just wait 3 weeks and test the real thing. It appears as though Ehsan and Alex are okay with waiting. Thanks for the offer though, Nick.

Comment 40

[Terry R.]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #39)
> If it's all the same to everyone else, I'd rather just wait 3 weeks and test
> the real thing. It appears as though Ehsan and Alex are okay with waiting.
> Thanks for the offer though, Nick.


Please consider Comment 28.  Three weeks is too long.

Comment 41

[u279076]

Hi Terry, at this point there is no plans to uplift this fix for Firefox 15. Alex Keybl can comment further on that decision. The testing Nick proposed in comment 38 would not move up that timeline at all, it just would allow us to double check that it is really fixed before going live with Firefox 16.  

I would suspect if we were going to do a Firefox 15.0.2, this bug would be a ride-along and not a catalyst for doing so. Again, I would let Alex Keybl comment further as to the reasoning behind this.

Comment 42

[Mihai Morar, (:MihaiMorar)]

I verified the fix on Beta channel by updating from Firefox 16.0be to 17.0b5 using the suggestions from comment 34 and it works as expected. 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20100101 Firefox/16.0 (build id: 20120911232325  ->  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Firefox/17.0 (build id: 20121106195758)

For Nightly and Aurora the action="silent" property doesn't show in the update.xml file.
Steps:
1.Install previous Nightly/Aurora version (17.0a2, 18.0a1 )
2.Set app.update.log to true in about:config and restart browser
3. Check for updates via the About dialog
4. Before restarting, open Error Console and find the update.xml URL. Open this URL in a new tab
Actual result: 
* Aurora: 
<updates><update type="minor" version="18.0a2" extensionVersion="18.0a2" buildID="20121112042014"><patch type="complete" URL="http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/11/2012-11-12-04-20-14-mozilla-aurora/firefox-18.0a2.en-US.mac.complete.mar" hashFunction="sha512" hashValue="202217da3dfce0a4d31baf2ae6b3b4e3ae7cb6669bc272f2c5ac449337306dfdd34d86e30466bfa23ef837691465e28005efd705bf8650a001dfa7423b643d6b" size="48153459"/></update></updates>
* Nightly:
<updates><update type="minor" version="19.0a1" extensionVersion="19.0a1" buildID="20121112030753"><patch type="complete" URL="http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/11/2012-11-12-03-07-53-mozilla-central/firefox-19.0a1.en-US.mac.complete.mar" hashFunction="sha512" hashValue="b48e4fe5e965385dd437dd70d013af466ba61376817731d02a2cccc113603ca6a14a91f2be733961b1081e6ecbeab0b18cb90628ab91a16410f0757697867c2d" size="47617250"/></update></updates>

Still, after restarting the browser to apply the update, the What's New page doesn't show on Nightly and Aurora. Is this expected ?

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Firefox/17.0 (build id: 20120913042009) ->  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:18.0) Gecko/18.0 Firefox/18.0 (build id: 20121112042014)
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:18.0) Gecko/18.0 Firefox/18.0 (build id: 20120913030547)  -> Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:19.0) Gecko/19.0 Firefox/19.0 (build id: 20121112030753)

Comment 43

[u279076]

(In reply to MarioMi from comment #42)

Thanks for your help testing this bug. Your results seem to indicate this is now working as expected.

> What's New page doesn't show on Nightly and Aurora.

What's New pages are only deployed for Releases and only on occasion when we feel what's in a release warrants a What's New page. You should never see a What's New page in Nightly and Aurora, or Beta for that matter. If you do, please file a new bug.

Comment 44

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The Mozmill test request was filed a while ago as bug 790538. So removing my name from the in-qa-testsuite flag.