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

VERIFIED FIXED in Firefox 16

Status

()

Toolkit
Application Update
VERIFIED FIXED
5 years ago
3 years ago

People

(Reporter: nthomas, Assigned: Ehsan)

Tracking

(Depends on: 1 bug, {regression})

Trunk
mozilla18
x86
Mac OS X
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-qa-testsuite ?
in-moztrap +

Firefox Tracking Flags

(firefox16+ verified, firefox17+ verified, firefox18+ verified)

Details

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

5 years ago
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
(Reporter)

Comment 1

5 years ago
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".
(Reporter)

Comment 2

5 years ago
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
Blocks: 307181

Comment 3

5 years ago
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.
Assignee: nobody → ehsan
tracking-firefox16: --- → +
QA Contact: jbecerra
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?
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
Duplicate of this bug: 789475
Fresh installation, new profile, en-US, 15.0 -> 15.0.1 on Win7 and Win8 I do not see a whatsnew page.

Comment 8

5 years ago
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.
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.
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.
Attachment #659348 - Flags: review?(robert.bugzilla)
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.
Attachment #659349 - Flags: review?(robert.bugzilla)
tracking-firefox17: --- → +
tracking-firefox18: --- → +
status-firefox16: --- → affected
status-firefox17: --- → affected
status-firefox18: --- → affected
Keywords: regression
Still the wrong patches
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. :(
Attachment #659348 - Attachment is obsolete: true
Attachment #659349 - Attachment is obsolete: true
Attachment #659348 - Flags: review?(robert.bugzilla)
Attachment #659349 - Flags: review?(robert.bugzilla)
Attachment #659510 - Flags: review?(robert.bugzilla)
Created attachment 659511 [details] [diff] [review]
Part 2: Ensure that the update.status directory exists before attempting to write to it
Attachment #659511 - Flags: review?(robert.bugzilla)
Attachment #659510 - Flags: review?(robert.bugzilla) → review+
Attachment #659511 - Flags: review?(robert.bugzilla) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/f7e36dada4ff
https://hg.mozilla.org/integration/mozilla-inbound/rev/8f24b5819c22
Target Milestone: --- → mozilla18
status-firefox18: affected → fixed
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.
Attachment #659510 - Flags: approval-mozilla-beta?
Attachment #659510 - Flags: approval-mozilla-aurora?
Attachment #659511 - Flags: approval-mozilla-beta?
Attachment #659511 - Flags: approval-mozilla-aurora?
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>
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.)
Attachment #659879 - Flags: review?(robert.bugzilla)
Attachment #659879 - Flags: approval-mozilla-beta?
Attachment #659879 - Flags: approval-mozilla-aurora?
https://tbpl.mozilla.org/?tree=Try&rev=83d791797c06

Comment 20

5 years ago
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
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
Flags: in-qa-testsuite?(hskupin)
Flags: in-moztrap+
(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/
Attachment #659879 - Flags: review?(robert.bugzilla) → review+
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 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.
Attachment #659510 - Flags: approval-mozilla-beta?
Attachment #659510 - Flags: approval-mozilla-beta+
Attachment #659510 - Flags: approval-mozilla-aurora?
Attachment #659510 - Flags: approval-mozilla-aurora+

Updated

5 years ago
Attachment #659511 - Flags: approval-mozilla-beta?
Attachment #659511 - Flags: approval-mozilla-beta+
Attachment #659511 - Flags: approval-mozilla-aurora?
Attachment #659511 - Flags: approval-mozilla-aurora+

Updated

5 years ago
Attachment #659879 - Flags: approval-mozilla-beta?
Attachment #659879 - Flags: approval-mozilla-beta+
Attachment #659879 - Flags: approval-mozilla-aurora?
Attachment #659879 - Flags: approval-mozilla-aurora+
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
status-firefox16: affected → fixed
status-firefox17: affected → fixed
https://hg.mozilla.org/mozilla-central/rev/8700c0c59802
https://hg.mozilla.org/mozilla-central/rev/b3dc4cd6b126
https://hg.mozilla.org/mozilla-central/rev/8cc774a223fd
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(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.
Depends on: 790538

Comment 28

5 years ago
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

5 years ago
(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

5 years ago
(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.
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?
Status: RESOLVED → VERIFIED
status-firefox17: fixed → verified
status-firefox18: fixed → verified
Keywords: verifyme
QA Contact: jbecerra → anthony.s.hughes

Updated

5 years ago
status-firefox16: fixed → affected
(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.
This bug is fixed in the updater code, and it was never landed on 15, so the last paragraph of comment 31 is expected.
status-firefox16: affected → fixed
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?
(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.
(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.
Status: VERIFIED → RESOLVED
Last Resolved: 5 years ago5 years ago
status-firefox17: verified → fixed
status-firefox18: verified → fixed
(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.
(Reporter)

Comment 38

5 years ago
(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.
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

5 years ago
(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.
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.
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)
(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.
Status: RESOLVED → VERIFIED
status-firefox16: fixed → verified
status-firefox17: fixed → verified
status-firefox18: fixed → verified
Keywords: verifyme
The Mozmill test request was filed a while ago as bug 790538. So removing my name from the in-qa-testsuite flag.
Flags: in-qa-testsuite?(hskupin) → in-qa-testsuite?
You need to log in before you can comment on or make changes to this bug.