|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
59 bytes, text/x-review-board-request
|Details | Review|
Since it's going to a be a lot of work and risk to tear down/replace all of the XPCOM components, JSMs, stylesheets, injected preferences, etc. at runtime and that doesn't seem worth it to support updates during runtime, we can instead delay any add-on updates until the next restart. This will still be much faster than only updating on Fx releases. We just need to add an upgrade listener to the add-on and do nothing when it's called which means the upgrade won't be installed at that time. http://searchfox.org/mozilla-central/rev/f0e4ae5f8c40ba742214e89aba3f554da0b89a33/toolkit/mozapps/extensions/test/xpcshell/data/test_delay_update_ignore/bootstrap.js#12,15-17,19-22
I didn't manually test this because it will take a lot of work and this is already covered by add-on manager unit tests (linked from comment 0). QE can verify when we start delivering as a system add-on.
Comment on attachment 8894007 [details] Bug 1387611 - Delay formautofill system add-on updates until the next restart. https://reviewboard.mozilla.org/r/165086/#review170630 Thanks, Matt.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/347ea0d06092 Delay formautofill system add-on updates until the next restart. r=lchang
Matthew N, can you give us some guidelines on how can we test this fix? Thanks
I don't think you can test this without an update to the system add-on being available via balrog. If you have an update staged this is trivial to test, just make sure the add-on doesn't update while Fx is running even when the update is downloaded.