I disabled the test for bug 423833 since it was timing out on the Linux tinderbox, and increasing the default timeout from 15s to 30s didn't help. It may be that this box is just really slow/overburdened, and that we need an even longer timeout. Alternatively, we could find a different way of testing this (perhaps by developing a new way to listen for error page loads - this would be useful in other tests). We might also just want to disable the last test (the one that's failing) so that we at least have coverage for the other cases, but I wanted to get the tree green since it's been orange for a while now, so just disabling it entirely was most expedient.

Well, crap. Increasing the timeout is unlikely to help, since the most likely explanation is that, even with the modifications made in the last version of the patch for bug 423833, there is still a situation (on Linux) in which the code to set the popup menu context, and then launch the appropriate command (This Frame->Open in new tab/window) can execute before the page has loaded "enough." As a result, the new tab/window that is launched is about:blank, and the setInterval calls which check for specific content never find it. Changing them to setTimeout() and re-writing a little would at least let the tests declaratively fail, instead of polling until killed, but better still would be to figure out why only Linux behaves in a way that breaks them. Can you paste the relevant log segment, so we at least know where the failure is happening?

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1207969311.1207972892.7847.gz&fulltext=1 is one example. This wasn't the only test that's been giving that linux box headaches, so I filed bug 428865 about speeding up that box somehow.

Mass marking whiteboard:[orange] bugs WFM (to clean up TBPL bug suggestions) that: * Haven't changed in > 6months * Whose whiteboard contains none of the strings: {disabled,marked,random,fuzzy,todo,fails,failing,annotated,leave open,time-bomb} * Passed a (quick) manual inspection of bug summary/whiteboard to ensure they weren't a false positive. I've also gone through and searched for cases where the whiteboard wasn't labelled correctly after test disabling, by using attachment description & basic comment searches. However if the test for which this bug was about has in fact been disabled/annotated/..., please accept my apologies & reopen/mark the whiteboard appropriately so this doesn't get re-closed in the future (and please ping me via IRC or email so I can try to tweak the saved searches to avoid more edge cases). Sorry for the spam! Filter on: #FFA500