A charming failure mode: it makes such a mess of the log by timing out at a bad time without a cleanup function that tbpl chokes and just says "Timeout generating log." What might well have been the first of these failures happened the other day while BzAPI was down and tbpl wasn't getting any suggestions, and we blew off the timeout generating log as a result of that. https://tbpl.mozilla.org/php/getParsedLog.php?id=11283297&tree=Mozilla-Inbound Rev3 WINNT 6.1 mozilla-inbound debug test mochitest-other on 2012-04-27 17:37:52 PDT for push df3acd833280 TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/tabview/test/browser_tabview_apptabs.js | Test timed out (screenshot) ... TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/tabview/test/browser_tabview_bug580412.js | There is only one group - Got 2, expected 1 ... TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/tabview/test/browser_tabview_bug626455.js | application timed out after 330 seconds with no output
This really isn't a good failure mode. https://tbpl.mozilla.org/php/getParsedLog.php?id=11455090&tree=Mozilla-Inbound
Created attachment 621009 [details] [diff] [review] patch v1 The problem was that whenAppTabIconAdded() always picked the first groupItem available but browser_tabview_apptabs.js (and others) was waiting for an app tab icon to be added to a specific groupItem. So I changed the signature of whenAppTabIconAdded() to take a groupItem as its first parameter so that there's no ambiguity anymore about the groupItem we're observing.