<div dir="ltr"><div><div><div><div>Mike,<br><br></div>Do we still kill the child process if the last content tab is closed?  For example, close all tabs in all windows except for an about:memory tab or something.  Or do we keep the child process alive as long as the browser.xul window is alive?<br><br></div>Keeping the process alive would actually make a few things easier with our current service worker/push/devtools setup.<br><br></div>Thanks.<br><br></div>Ben<br><div><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 25, 2016 at 10:29 AM, Mike Conley <span dir="ltr"><<a href="mailto:mconley@mozilla.com" target="_blank">mconley@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">After much toil, this has finally landed on central. Hopefully it sticks.<br>
<br>
Big thanks to all of my reviewers - especially smaug, who reviewed the bulk<br>
of the weirder stuff.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Mike<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 9 June 2016 at 14:21, Mike Conley <<a href="mailto:mconley@mozilla.com">mconley@mozilla.com</a>> wrote:<br>
<br>
> If you don’t write tests that open browser windows or work on the<br>
> front-end of Firefox, you can probably ignore this.<br>
><br>
> The initial browser in browser.xul is non-remote by default. This means<br>
> that as soon as it browses to some URL that can be loaded in the content<br>
> process (about:home, for example), we kick off the remoteness flipping<br>
> machinery that swaps out that initial browser and puts a remote one down in<br>
> its place to load the content in the child process.<br>
><br>
> In bug 1261842, I’m working on switching things around so that the initial<br>
> browser is remote as soon as possible (there’s still some set-up required<br>
> in JS, so I can’t just add the remote attribute to that initial browser).<br>
> Doing the flip sooner means we don’t have to set up the content viewer for<br>
> the non-remote browser (which gets immediately destroyed after the<br>
> remoteness flip), which is good for window-opening performance.<br>
><br>
> Normally, I wouldn’t bother these two mailing lists with this kind of<br>
> information, but while working on these patches, I’ve had to fix a bunch of<br>
> tests that worked properly under the old assumption (initial browser is<br>
> non-remote) but not under the new one (initial browser is remote), and I<br>
> wanted to give a PSA on those writing tests that open windows.<br>
><br>
> Here’s the deal: If you’re writing browser mochitests and you need to open<br>
> a window, please use BrowserTestUtils.openNewBrowserWindow. If you need to<br>
> trigger window openings via another mechanism (like window.open in<br>
> content), but need to do things with the newly opened window, set up a<br>
> Promise with BrowserTestUtils.waitForNewWindow. Both of these methods are<br>
> doing the right thing in terms of waiting for the new window to set itself<br>
> up and for the initial browser to be ready to do things with it.<br>
><br>
> If you care - here’s why: without them, you run the risk of falling into<br>
> the mistake I was seeing in a number of tests, which was opening a new<br>
> window, waiting for its load event, telling the initial browser to load<br>
> some URI, and then waiting for BrowserTestUtils.browserLoaded to resolve<br>
> before proceeding. This technique will fail frequently, because sometimes<br>
> the message to load the URI will arrive at content after it has loaded its<br>
> initial about:blank, but before the parent has had an opportunity to hear<br>
> that the initial about:blank has been loaded. This means that the<br>
> browserLoaded Promise will sometimes resolve even though the URI you<br>
> requested hasn’t finished (or maybe even started) loading.<br>
><br>
> Anyhow, with the patches in the bug, I appear to have fixed all of the<br>
> tests that fall into this trap - but if you write a new test that’s opening<br>
> a window that’s failing frequently and you don’t know why, it might be<br>
> because you need to use those BrowserTestUtils methods.<br>
><br>
> Feel free to follow up with me in this thread or over IRC if there are any<br>
> questions or concerns regarding bug 1261842.<br>
><br>
> Thanks,<br>
><br>
> -Mike<br>
><br>
_______________________________________________<br>
dev-platform mailing list<br>
<a href="mailto:dev-platform@lists.mozilla.org">dev-platform@lists.mozilla.org</a><br>
<a href="https://lists.mozilla.org/listinfo/dev-platform" rel="noreferrer" target="_blank">https://lists.mozilla.org/listinfo/dev-platform</a><br>
</div></div></blockquote></div><br></div></div></div></div></div></div></div></div>