Closed Bug 1229352 Opened 9 years ago Closed 8 years ago

Make Loop fully restartless capable

Categories

(Hello (Loop) :: Client, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: standard8, Unassigned)

References

Details

(Whiteboard: [release][btpp-fix-later][todo-akita])

Attachments

(2 files, 1 obsolete file)

Currently Loop as a system add-on isn't fully restartless. We need to be unloading the loop-panel when the add-on is shutdown, so that we drop the references to the backend, and that allows the new versions of the backend modules to be reloaded.
Rob, do you know when the latest we should aim for this is?
Flags: needinfo?(rhelmer)
(In reply to Mark Banner (:standard8) from comment #1) > Rob, do you know when the latest we should aim for this is? The other missing piece for delivering restartless updates is to make sure we don't interrupt an ongoing call, or other important task. Did you want to handle that in this bug, or just unloading the loop-panel?
Flags: needinfo?(rhelmer)
(In reply to Robert Helmer [:rhelmer] from comment #2) > (In reply to Mark Banner (:standard8) from comment #1) > > Rob, do you know when the latest we should aim for this is? > > The other missing piece for delivering restartless updates is to make sure > we don't interrupt an ongoing call, or other important task. > > Did you want to handle that in this bug, or just unloading the loop-panel? Presumably there will be core parts to the interrupting a call - how about doing those as a separate bug, and we'll do the rest in this one?
Assignee: nobody → standard8
(In reply to Mark Banner (:standard8) from comment #3) > (In reply to Robert Helmer [:rhelmer] from comment #2) > > (In reply to Mark Banner (:standard8) from comment #1) > > > Rob, do you know when the latest we should aim for this is? > > > > The other missing piece for delivering restartless updates is to make sure > > we don't interrupt an ongoing call, or other important task. > > > > Did you want to handle that in this bug, or just unloading the loop-panel? > > Presumably there will be core parts to the interrupting a call - how about > doing those as a separate bug, and we'll do the rest in this one? OK I filed bug 1231172 to figure out the add-ons manager side of this.
Rank: 25
Priority: -- → P2
Rank: 25 → 22
Depends on: 1231172
Rank: 22 → 26
Whiteboard: [go faster] → [release]
Blocks: 1250849
This would allow the panel frames to be easily destroyed. Social API patch for central, needs a test.
Attachment #8697323 - Attachment is obsolete: true
Patch for the Loop repo - this does the necessary to cause the unload of the panel (if supported in the version of FF), and unload extra modules. At this stage, I think we'll deal with conversation window closing / pausing restarts in a separate bug (we need bug 1231172 to be fixed). We still need some manual verification here to ensure that when an add-on is restarted, then everything is loaded correctly. I think we could test this by: - Create two versions of the add-on, both with this fix. - The second version should have some changes visually, e.g. add extra log output in MozLoopService, change the colour of something on the panel. - Startup FF, install the unmodified version. Restart FF. - Install the second version, check the modifications show up correctly.
No longer blocks: 1250849
Depends on: 1250849
Whiteboard: [release] → [release][btpp-fix-later][akita-todo]
Whiteboard: [release][btpp-fix-later][akita-todo] → [release][btpp-fix-later][todo-akita]
Depends on: 1278692
No longer depends on: 1231172
Depends on: 1204156
No longer depends on: 1278692
Basic support for this has landed in bug 1231172. We'll have MDN docs for this feature soon, but basically it works like this: ``` AddonManager.addUpgradeListener(instanceID, upgrade => { upgrade.install(); }); ``` You may hang on to the `upgrade` object for later, or simply never call `install()` on it in which case the upgrade will be installed on next restart. Note that system add-ons are special-cased right now to always require restart, bug 1204156 will remove that and make them install just as normal add-ons do, so you have until that bug ships to implement this if you want to delay silent background updates :)
Flags: needinfo?(standard8)
(In reply to Robert Helmer [:rhelmer] from comment #8) > We'll have MDN docs for this feature soon, but basically it works like this: > ``` > AddonManager.addUpgradeListener(instanceID, upgrade => { > upgrade.install(); > }); > ``` Oh, and `instanceID` is passed to bootstrap `startup()` on the data object: ``` function startup(data, reason) { if (data.hasOwnProperty("instanceID") && data.instanceID) { // data.instanceID is a Symbol that is only accessible by this add-on } } ``` Since `instanceID` is a symbol you cannot serialize it, you must keep a reference to it.
(In reply to Robert Helmer [:rhelmer] from comment #8) > Note that system add-ons are special-cased right now to always require > restart, bug 1204156 will remove that and make them install just as normal > add-ons do, so you have until that bug ships to implement this if you want > to delay silent background updates :) At the moment for Hello its not just delaying silent updates that affects us. We're missing some vital parts that mean reloading the add-on will likely break the UI. Therefore I think this blocks bug 1204156 at the moment. Some of our newer code is already being written with restartless in mind, but I think we still need to fix some parts, especially the panel. I'm not sure if we'll get to this for the next few weeks.
Flags: needinfo?(standard8)
Assignee: standard8 → nobody
No longer depends on: 1204156
Support for Hello/Loop has been discontinued. https://support.mozilla.org/kb/hello-status Hence closing the old bugs. Thank you for your support.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: