# Although I'm still not sure if this is a valid bug. I found following 3 bugs: bug 1366505, bug 1307340 and bug 1253864. Those bugs are timeout bug after calling SimpleTest.waitForFocus() with newly opened chrome window. So, they does: > newWindows = window.open("foo.xul", "_blank", "chrome,width=600,height=600,..."); > SimpleTest.waitForFocus(()=>{ /* do someting */ }, newWindow); I see some tests which have not been reported same intermittent timeouts even though they do exactly same thing. However, those fails occurs not so high frequently. So, it *might* be that they have just not been reported yet.

I tried to reproduce the orange to log what happens. https://treeherder.mozilla.org/#/jobs?repo=try&revision=8b68e497d751d15a41f7359aae1281df6f91ec7d&filter-tier=1 However, I've never seen the failure in tryserver (when I worked on bug 1303260, I had never seen it, though). Something of tryserver are different from mozilla-central, mozilla-inbound, autoland, etc?

Although this isn't the same error, we've found one when we run mochitest-chrome on Ubuntu 16.04 that deals with the test mentioned by bug 1366505: https://treeherder.mozilla.org/#/jobs?repo=try&revision=275d53b6a1a0bd3cf36a98ffda2b837bbdfc42ce&selectedJob=101683656 Joel, do you know if there are any major differences in the different project branches?

try machines are the same as m-c/m-i/autoland. The differences might be the configurations, but this would be what you have locally in your tree vs what is built. We also do clobber builds on try vs incremental on inbound (with periodic clobber).

Ok, thank you. It would be interesting if the incremental build affects this, but if m-c uses clobber builds rather than incremental, that difference can't be the problem. Looking at the three failing tests, they all seem to be using a second parameter in the waitForFocus function (the window they wan't to operate on) and furthermore, they all open a window just before asking to waitForFocus. Maybe we have this problem because the window hasn't fully opened yet and we are already asking it for focus. Maybe we should be looking for another event here at [1] before trying to get focus. [1]: https://dxr.mozilla.org/mozilla-central/source/testing/mochitest/browser-harness.xul#266

So, I think we could add the following spin-lock at [1]: > while (win.document.readyState !== "interactive"); This change will make the function wait until the DOM elements inside the window is loaded completely (not the content within the DOMs), then get focus. It's hard to test if this would work though. I'm wondering if there is another flag that we could use to do this. Another thing I am thinking of is that we could have those tests use an addEventListener so that waitForFocus doesn't fire until the window "load" event is detected. [1]: https://dxr.mozilla.org/mozilla-central/source/testing/mochitest/browser-harness.xul#273