browser-loop (on elm, but not yet on central) adds its own browser-delayed-startup observer to initialize the loop service. This causes leaks in second windows as the observer never fires (and maybe also in the first window if it shut down quickly enough?) Either way, the solution is to do this init in delayedStartup. Blair, sorry to ask you to review unlanded code, but hopefully this is clear enough.

Comment on attachment 8431259 [details] [diff] [review] Move init to delayedStartup Review of attachment 8431259 [details] [diff] [review]: ----------------------------------------------------------------- My original thought was for MozLoopService.jsm itself to be calling MozLoopService.initialize() at the end of the file, so it automatically happens only the first time the module is imported (which would be forced by LoopUI.initialize()), but that was without knowing any details of MozLoopService.jsm. But I see now that this'll work anyway, since MozLoopService.initialize() basically already protects against re-initialising :)

Yeah, I suspect the initialization is going to change anyway (indeed, there is a bug on file to simplify that) Thanks! https://hg.mozilla.org/projects/elmrev/c60f834cb976 Dan or Mark: not sure if this should be closed or what process you guys are hoping to use to merge to m-c, so I'll leave this for you guys to sort out.

Thanks for fixing this. We'll close out this bug so it leaves the tracking radars. I'll explain what I'm envisioning separately.

Untracking for QE verification. Please needinfo me to request manual testing.