1555088 - Lessen startup IO by using a different method to determine an update was performed other than reading the update.status file

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect, P2)

Description

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

Spinoff of Bug 1446012 and specifically Bug 1446012 comment #8

I've been thinking about this a bit and I think the code can be changed as follows:

Replace the use of the app.update.postupdate pref in BrowserContentHandler.jsm with a check for if there is an activeUpdate for OVERRIDE_NEW_MSTONE and OVERRIDE_NEW_BUILD_ID. For the OVERRIDE_NEW_MSTONE case when there is an activeUpdate it can be passed to getPostUpdateOverridePage and when there isn't an activeUpdate it can just use the value of the startup.homepage_override_url pref.
https://searchfox.org/mozilla-central/source/browser/components/BrowserContentHandler.jsm#555-577

Remove the following from UpdateService.jsm
https://searchfox.org/mozilla-central/source/toolkit/mozapps/update/UpdateService.jsm#1889-1894

Replace the following so it just QI's the activeUpdate to nsIWritablePropertyBag.
https://searchfox.org/mozilla-central/source/browser/components/BrowserContentHandler.jsm#143-158

Comment 1

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

Attachment: Bug 1555088 - Don't read the update.status file during profile-after-change. r=bytesized

Changes BrowserContentHandler.jsm to rely on whether there is a version change and an active update to determine whether to check for a what's new page and send an update ping
Changes BrowserContentHandler.jsm to rely on whether there is a build ID change and an active update to determine whether to send an update ping
Removes reading of the update.status file in UpdateService.jsm UpdateService::observe post-update-processing which is called during the profile-after-change observer notification

Comment 2

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

Well, this is annoying. There are several other consumers that have decided to use the pref! Good times...

Comment 3

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

https://searchfox.org/mozilla-central/source/browser/extensions/pdfjs/content/PdfJs.jsm#30
https://searchfox.org/mozilla-central/source/browser/components/enterprisepolicies/tests/browser/browser_policy_override_postupdatepage.js#10
https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/tests/browser/browser_UpdatePingSuccess.js#18

Comment 4

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

As suggested in comment #0, this can't be implemented unless nsHandlerService-json.js no longer has a dependency on the app.update.postupdate pref which was added in bug 1389443 so wontfixing. If a different method comes to mind I'll file a bug for it.

Comment 5

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

Attachment: Patch in progress

Attaching this for safe keeping until after bug 1446012 is fixed or wontfixed.

Comment 6

[:Gijs (he/him)]

The Pdfjs code in bug 1559195 is just being removed, but is actually already dead, so I'm gonna reopen this. :-)

Comment 7

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

Attachment: Bug 1555088 - Use activeUpdate and an app version increase to determine that an update was performed and remove the post update pref. r=bytesized

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9da065181d29
Use activeUpdate and an app version increase to determine that an update was performed and remove the post update pref. r=bytesized

Comment 9

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/9da065181d29