This appears to have started around the time of the other mochitest-dt issues we've been having recently. Retriggers seemed to be pointing to bug 995394 as the culprit, and it did go away for awhile post-backout. But now it's back. And it's just as inexplicable as the other ones we've been dealing with. Anyway, I'm filing the intermittent for now, but given the frequency, this bug may very-soon turn into a re-enabling bug.
Let's start with a longer timeout and see how that goes. https://hg.mozilla.org/integration/mozilla-inbound/rev/9dd9d1e5b43c
The test fails after all the assertions have passed, after the test harness logged "leaving test", and given the inexplicable nature of the failures we've been having, this could point in the direction of a test harness change. Bug 1073352 has recently landed, could it be related?
It's an interesting theory, but one I'm not horribly qualified to answer. Andrew, how likely does that seem to you? Basically, we're seeing lots of trunk-only timeouts on linux/linux64 debug mochitest-bc/dt. They started late last week. In some of the runs I've looked at, the DOMWINDOW count is crazy-high (like 500+), which is pretty amazing given that run-by-dir is enabled on those suites.
It is certainly possible that my patch messed things up for any browser-chrome kind of test. I looked at the logs for the last two failures in this bug, and the window count doesn't go above 86, so I don't think that's a factor for this particular failure.
Ryan: Do we keep the requestLongerTimeout(2) and close this bug? In the meantime, triaging as P3 (no recent failures, but that's only because of the requestLongerTimeout I guess).
Might as well at this point.