Last Comment Bug 789422 - actions="silent" not working for Firefox 15.0 -> 15.0.1 updates (What's New page is shown)
: actions="silent" not working for Firefox 15.0 -> 15.0.1 updates (What's New p...
Status: VERIFIED FIXED
: regression
Product: Toolkit
Classification: Components
Component: Application Update (show other bugs)
: Trunk
: x86 Mac OS X
: -- normal (vote)
: mozilla18
Assigned To: :Ehsan Akhgari (busy, don't ask for review please)
: Anthony Hughes (:ashughes) [GFX][QA][Mentor]
Mentors:
: 789475 (view as bug list)
Depends on: 790538
Blocks: bgupdates
  Show dependency treegraph
 
Reported: 2012-09-07 02:23 PDT by Nick Thomas [:nthomas]
Modified: 2014-06-23 04:09 PDT (History)
15 users (show)
anthony.s.hughes: in‑qa‑testsuite?
anthony.s.hughes: in‑moztrap+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
verified
+
verified
+
verified


Attachments
Part 1: Remove UpdateStatusText because it does the exact same thing as UpdateStatusFile(const char*) (2.41 KB, patch)
2012-09-07 13:55 PDT, :Ehsan Akhgari (busy, don't ask for review please)
no flags Details | Diff | Review
Part 2: Ensure that the update.status directory exists before attempting to write to it (1.86 KB, patch)
2012-09-07 13:55 PDT, :Ehsan Akhgari (busy, don't ask for review please)
no flags Details | Diff | Review
Part 1: Remove UpdateStatusText because it does the exact same thing as UpdateStatusFile(const char*) (2.78 KB, patch)
2012-09-08 12:07 PDT, :Ehsan Akhgari (busy, don't ask for review please)
robert.strong.bugs: review+
akeybl: approval‑mozilla‑aurora+
akeybl: approval‑mozilla‑beta+
Details | Diff | Review
Part 2: Ensure that the update.status directory exists before attempting to write to it (1015 bytes, patch)
2012-09-08 12:07 PDT, :Ehsan Akhgari (busy, don't ask for review please)
robert.strong.bugs: review+
akeybl: approval‑mozilla‑aurora+
akeybl: approval‑mozilla‑beta+
Details | Diff | Review
Part 3: Update the unit tests (4.39 KB, patch)
2012-09-10 15:31 PDT, :Ehsan Akhgari (busy, don't ask for review please)
robert.strong.bugs: review+
akeybl: approval‑mozilla‑aurora+
akeybl: approval‑mozilla‑beta+
Details | Diff | Review

Description Nick Thomas [:nthomas] 2012-09-07 02:23:12 PDT
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] 2012-09-07 02:31:41 PDT
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] 2012-09-07 03:04:52 PDT
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] 2012-09-07 08:03:11 PDT
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 :Ehsan Akhgari (busy, don't ask for review please) 2012-09-07 08:54:09 PDT
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 [:rstrong] (use needinfo to contact me) 2012-09-07 09:21:23 PDT
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 6 Robert Strong [:rstrong] (use needinfo to contact me) 2012-09-07 09:22:18 PDT
*** Bug 789475 has been marked as a duplicate of this bug. ***
Comment 7 juan becerra [:juanb] 2012-09-07 09:24:56 PDT
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. 2012-09-07 09:29:06 PDT
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 :Ehsan Akhgari (busy, don't ask for review please) 2012-09-07 13:54:53 PDT
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 :Ehsan Akhgari (busy, don't ask for review please) 2012-09-07 13:55:35 PDT
Created attachment 659348 [details] [diff] [review]
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 :Ehsan Akhgari (busy, don't ask for review please) 2012-09-07 13:55:57 PDT
Created attachment 659349 [details] [diff] [review]
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] 2012-09-07 16:01:24 PDT
Still the wrong patches
Comment 13 :Ehsan Akhgari (busy, don't ask for review please) 2012-09-08 12:07:05 PDT
Created attachment 659510 [details] [diff] [review]
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 :Ehsan Akhgari (busy, don't ask for review please) 2012-09-08 12:07:34 PDT
Created attachment 659511 [details] [diff] [review]
Part 2: Ensure that the update.status directory exists before attempting to write to it
Comment 16 :Ehsan Akhgari (busy, don't ask for review please) 2012-09-10 13:35:08 PDT
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 :Ehsan Akhgari (busy, don't ask for review please) 2012-09-10 14:41:40 PDT
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 :Ehsan Akhgari (busy, don't ask for review please) 2012-09-10 15:31:38 PDT
Created attachment 659879 [details] [diff] [review]
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 :Ehsan Akhgari (busy, don't ask for review please) 2012-09-10 15:33:58 PDT
https://tbpl.mozilla.org/?tree=Try&rev=83d791797c06
Comment 20 Mozilla RelEng Bot 2012-09-10 17:30:41 PDT
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/eakhgari@mozilla.com-83d791797c06
Comment 21 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-09-11 10:34:07 PDT
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 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-09-11 10:34:32 PDT
(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 24 Alex Keybl [:akeybl] 2012-09-11 13:38:30 PDT
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 27 Henrik Skupin (:whimboo) 2012-09-12 00:08:01 PDT
(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. 2012-09-15 09:34:16 PDT
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 (not working on stability any more) 2012-09-15 15:12:58 PDT
(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. 2012-09-15 21:05:27 PDT
(In reply to Robert Kaiser (:kairo@mozilla.com) 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 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-09-18 10:03:20 PDT
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] 2012-09-18 11:16:19 PDT
(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 :Ehsan Akhgari (busy, don't ask for review please) 2012-09-18 11:21:51 PDT
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 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-09-18 11:28:05 PDT
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 :Ehsan Akhgari (busy, don't ask for review please) 2012-09-18 11:34:06 PDT
(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 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-09-18 11:37:50 PDT
(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] 2012-09-18 14:31:44 PDT
(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] 2012-09-18 16:12:11 PDT
(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 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-09-18 16:14:07 PDT
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. 2012-09-18 16:17:13 PDT
(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 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-09-19 09:25:03 PDT
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) 2012-11-12 07:32:46 PST
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 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-11-13 12:24:55 PST
(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) 2014-06-23 04:09:28 PDT
The Mozmill test request was filed a while ago as bug 790538. So removing my name from the in-qa-testsuite flag.

Note You need to log in before you can comment on or make changes to this bug.