Bug 749231 did the same for xpcshell tests, and it can be very useful for diagnosing test failures.

How come I had never heard about build/automation.py.in until now?

(In reply to Panos Astithas [:past] from comment #1) > Created attachment 667471 [details] [diff] [review] > Patch v1 > > How come I had never heard about build/automation.py.in until now? we try to keep it secret and you just ruined it. Now we have to put all that into a new file somewhere else.

Comment on attachment 667471 [details] [diff] [review] Patch v1 before I r+ this, have you run it through try? It has the potential to really pollute our tests. We've also had tests behave differently when debugger logging has been enabled. I'm inclined to recommend using this for try builds only when trying to diagnose a specific problem.

Try push: https://tbpl.mozilla.org/?tree=Try&rev=f881e87cb260 Limiting logging to try pushes would probably be enough. How can I do this? I don't see anything in this file that differentiates between try and other builders.

unfortunately, I think that'd be a manual operation. Applying this patch to the top of your queue on a try run. :/

(In reply to Rob Campbell [:rc] (:robcee) from comment #5) > unfortunately, I think that'd be a manual operation. Applying this patch to > the top of your queue on a try run. :/ Ah, I've been doing that already, but by modifying the default value in firefox.js instead of this. Would you prefer to WONTFIX this bug? It has been very useful having xpcshell tests always run with logging enabled, and we have logging enabled when we write tests, so it would seem that running tests with logging enabled would be more accurate in that sense. On the other hand the xpcshell harness does not print protocol log data unless the test fails, which is not the case for mochitests.

yeah, let's wontfix this for now. We can revisit if we need to make a determined effort for test debugging.

Comment on attachment 667471 [details] [diff] [review] Patch v1 canceling review