Our tree sheriffs often look at test logs for e10s, and unfortunately, many of our tests trigger unsafe CPOW usage warnings because they haven't been ported to use async messages yet.
Most of these have been filed as blocking bug 1109869, but in the mean time, our sheriffs have to deal with a ton of log spam, and that really sucks.
As an interim solution, we would like to investigate filtering out "unsafe CPOW usage" warnings from the log viewer. RyanVM has told me that this would be an OK interim solution until we drill bug 1109869 into the ground.

I don't think this is something that we can easily do (or would want to do), particularly with the current log viewer. At some point in the future, when we use the json (aka structured) logs with a new log viewer, it can perhaps do collapsing by test or subtest/filtering/... - however even then, I don't think we'd want to hide things by default - it would be up to the user to filter each time - which doesn't really help this use case. In addition, it still leaves the full log and local dev console pretty cluttered.
As such, I think for now this is best dealt with at the console/logging/harness level instead - eg "only report the first N warnings for each file/type" or summarise them "55 warnings in file X". So this either belongs in an e10s component, or a testing/harness component. Another option would be to only show the warnings in local jobs, or to say ask the mozharness people to add another log level that we can get the log viewer to ignore.

Alternatively, and this is something RyanVM just suggested to me, we could disable all unsafe CPOW usage warnings for test runs except for a particular project branch (like Holly, which we already use for e10s tests, I believe).
What do you think of that last idea, jimm? RyanVM suspects that filtering out the unsafe CPOW usage entries from the log view the treeherder logviewer is non-trivial. Do you know if we have any run or build-time prefs that we can use to disable the warnings just for test runs?

So this patch will do the job of suppressing all unsafe CPOW warnings when running mochitests, and adds a --enable-CPOW-warnings argument to the mach mochitest-* commands (and runtests.py) to turn them back on.
I tested this locally with browser/base/content/test/general/browser_bug575561.js as a test case, and the warnings are gone (unless I flip them on with --enable-CPOW-warnings).

https://reviewboard.mozilla.org/r/6903/#review5761
::: testing/mochitest/mach_commands.py
(Diff revision 1)
> + enableCPOWWarnings = CommandArgument(
> + '--enable-CPOW-warnings',
> + action='store_true',
> + help='Run tests with unsafe CPOW usage warnings enabled.')
> + func = enableCPOWWarnings(func)
This is fine for now, but how common do you think enabling this locally is going to be? I'm trying to improve the UX of running tests a bit, and part of that will be cleaning rarely used options out of the command line. These rarer options will still be configurable.. just more out of the way.

(In reply to Andrew Halberstadt [:ahal] from comment #7)
> https://reviewboard.mozilla.org/r/6903/#review5761
>
> ::: testing/mochitest/mach_commands.py
> (Diff revision 1)
> > + enableCPOWWarnings = CommandArgument(
> > + '--enable-CPOW-warnings',
> > + action='store_true',
> > + help='Run tests with unsafe CPOW usage warnings enabled.')
> > + func = enableCPOWWarnings(func)
>
> This is fine for now, but how common do you think enabling this locally is
> going to be?
Very uncommon to never. The only use-case I can think of, to enable this for tests, is for the e10s team to sample the logs to determine if there are still places where we're using unsafe CPOWs. At this stage, I don't see us doing that very often, though that might change in the next quarter (Milestone 8 of e10s involves us drilling into a bunch of these unsafe CPOW usage warnings).