Closed Bug 1301288 Opened 4 years ago Closed 4 years ago
Firefox post update actions are no longer performed due to post update processing happening later in startup
No description provided.
Firefox reads the properties of the first update in the updates.xml file to determine if there are post update actions to perform such as opening a what's new page. Since bug 311614 landed the updates.xml file is updated later during startup along with the app.update.postupdate pref being set.
This caused bug 1292637
I tried a couple of other fixes but they all ended up with some fairly major changes. I ended up going with just updating the updates.xml with the active update so the changes would be safer for uplifting. I will file a bug for a cleaner fix if this approach is acceptable. Pushed to try https://treeherder.mozilla.org/#/jobs?repo=try&revision=538721b6ded1
Assignee: nobody → robert.strong.bugs
Status: NEW → ASSIGNED
Attachment #8789212 - Flags: review?(mhowell)
Comment on attachment 8789212 [details] [diff] [review] patch rev1 Review of attachment 8789212 [details] [diff] [review]: ----------------------------------------------------------------- A cleaner fix would definitely be preferred, but this should work fine for now.
Attachment #8789212 - Flags: review?(mhowell) → review+
I was able to verify this locally. For QA to verify this it will require the following steps: 1. install and then launch a build that has an update to a build that has this patch. 2. open the about window to download the update. 3. in the browser console run the following code to open the updates directory var fileLocator = Cc["@mozilla.org/file/directory_service;1"].getService(Ci.nsIProperties); var dir = fileLocator.get("UpdRootD", Ci.nsIFile); dir.reveal(); 4. exit Firefox. 5. open the active-update.xml file in an editor 6. adding the following to <update of the active-update.xml actions="showURL" openURL="https://www.mozilla.org/zh-TW/firefox/49.0/whatsnew/" 7. launch Firefox Alternatively, if releng can create a test update xml with the actions and openURL values you can add a string pref with the name app.update.url.override and a value of the url to the test update xml.
[Tracking Requested - why for this release]: This is a regression caused by bug 311614 which prevented showing the what's new page in bug 1292637.
Pushed by email@example.com: https://hg.mozilla.org/integration/fx-team/rev/c518337a8da2 set post update values earlier in startup so Firefox post update actions can be performed. r=mhowell
Filed bug 1301517 for the cleanup
Is this something you intend to uplift for 50? I assume not for 49. Thanks!
Hi Robert, could you please nominate a patch for uplift to Fx50? Thanks!
Comment on attachment 8789212 [details] [diff] [review] patch rev1 Approval Request Comment [Feature/regressing bug #]: Bug 311614 [User impact if declined]: We won't be able to show the What's New page by configuring the update advertisement. See 1292637 for one instance. [Describe test coverage new/current, TreeHerder]: Landed on nightly and I manually verified this patch fixes this bug [Risks and why]: Minimal since this code only runs after an update has been applied, it has landed on Nightly, and I've tested this locally. [String/UUID change made/needed]: None
Attachment #8789212 - Flags: approval-mozilla-aurora?
Comment on attachment 8789212 [details] [diff] [review] patch rev1 Recent regression, Aurora50+
Attachment #8789212 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Pushed to mozilla-aurora https://hg.mozilla.org/releases/mozilla-aurora/rev/79429ecdadfa79a101cff2add3d5c1eac5b07e7f
Using the STR provided in comment 5 I was able to confirm this fix on Windows 10 x64, the "whats new page" is correctly displayed after updating from an older version. Verified on latest 50.0a2 Aurora, build ID 20160914004005 and latest 51.0a1 Nightly, build ID 20160914030200.
You need to log in before you can comment on or make changes to this bug.