Filed by: tomcat [at] mozilla.com https://treeherder.mozilla.org/logviewer.html#?job_id=39205575&repo=mozilla-inbound https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-linux-debug/1479198072/mozilla-inbound_ubuntu32_vm-debug_test-mochitest-devtools-chrome-3-bm03-tests1-linux32-build38.txt.gz

This is a long-running test when it succeeds: devtools/client/commandline/test/browser_cmd_highlight_04.js | took 356621ms Most failures show progress just a few seconds before the timeout: [task 2017-02-15T12:58:24.465009Z] 12:58:24 INFO - Buffered messages logged at 12:58:19 [task 2017-02-15T12:58:24.482874Z] 12:58:24 INFO - TEST-PASS | devtools/client/commandline/test/browser_cmd_highlight_04.js | html output for 'highlight .item --showall' - [task 2017-02-15T12:58:24.490386Z] 12:58:24 INFO - Buffered messages finished [task 2017-02-15T12:58:24.496338Z] 12:58:24 INFO - TEST-UNEXPECTED-FAIL | devtools/client/commandline/test/browser_cmd_highlight_04.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. - so I think requestLongerTimeout() should avoid these failures.

I see requestLongerTimeout(3) was added just a few days ago - bug 1315570.

:ochameau, :smaug - I see the discussion in bug 1315570 about this test, but thought I should check in with you anyway: Shall I bump to requestLongerTimeout(4) or is there cause for concern here?

As far as I know, devtools have buggy code where it uses requestAnimationFrame to effectively spin event loop, and each its request does heavy work, so that normal runnables don't get run. But yes, even longer timeout might help.

Pushed by gbrown@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/323bcdc5575f Request even longer timeout for browser_cmd_highlight_04.js; r=me,test-only