After much toil, this has finally landed on central. Hopefully it sticks. Big thanks to all of my reviewers - especially smaug, who reviewed the bulk of the weirder stuff.
-Mike On 9 June 2016 at 14:21, Mike Conley <mcon...@mozilla.com> wrote: > If you don’t write tests that open browser windows or work on the > front-end of Firefox, you can probably ignore this. > > The initial browser in browser.xul is non-remote by default. This means > that as soon as it browses to some URL that can be loaded in the content > process (about:home, for example), we kick off the remoteness flipping > machinery that swaps out that initial browser and puts a remote one down in > its place to load the content in the child process. > > In bug 1261842, I’m working on switching things around so that the initial > browser is remote as soon as possible (there’s still some set-up required > in JS, so I can’t just add the remote attribute to that initial browser). > Doing the flip sooner means we don’t have to set up the content viewer for > the non-remote browser (which gets immediately destroyed after the > remoteness flip), which is good for window-opening performance. > > Normally, I wouldn’t bother these two mailing lists with this kind of > information, but while working on these patches, I’ve had to fix a bunch of > tests that worked properly under the old assumption (initial browser is > non-remote) but not under the new one (initial browser is remote), and I > wanted to give a PSA on those writing tests that open windows. > > Here’s the deal: If you’re writing browser mochitests and you need to open > a window, please use BrowserTestUtils.openNewBrowserWindow. If you need to > trigger window openings via another mechanism (like window.open in > content), but need to do things with the newly opened window, set up a > Promise with BrowserTestUtils.waitForNewWindow. Both of these methods are > doing the right thing in terms of waiting for the new window to set itself > up and for the initial browser to be ready to do things with it. > > If you care - here’s why: without them, you run the risk of falling into > the mistake I was seeing in a number of tests, which was opening a new > window, waiting for its load event, telling the initial browser to load > some URI, and then waiting for BrowserTestUtils.browserLoaded to resolve > before proceeding. This technique will fail frequently, because sometimes > the message to load the URI will arrive at content after it has loaded its > initial about:blank, but before the parent has had an opportunity to hear > that the initial about:blank has been loaded. This means that the > browserLoaded Promise will sometimes resolve even though the URI you > requested hasn’t finished (or maybe even started) loading. > > Anyhow, with the patches in the bug, I appear to have fixed all of the > tests that fall into this trap - but if you write a new test that’s opening > a window that’s failing frequently and you don’t know why, it might be > because you need to use those BrowserTestUtils methods. > > Feel free to follow up with me in this thread or over IRC if there are any > questions or concerns regarding bug 1261842. > > Thanks, > > -Mike > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
