Currently the error printed for MOZ_DISABLE_NONLOCAL_CONNECTIONS transgressions ends up being hard to find on some platforms - particularly those where it's only buried in the logcat some lines away from the crash (or in the case of some suites; hang since they don't handle crashes properly... facepalm): eg https://tbpl.mozilla.org/php/getParsedLog.php?id=41944900&full=1&branch=try 02:29:23 INFO - 06-18 02:28:15.453 I/Gecko ( 2177): Non-local network connections are disabled and a connection attempt to www.google.com (22.214.171.124) was made. You should only access hostnames available via the test networking proxy (if running mochitests) or from a test-specific httpd.js server (if running xpcshell tests). Browser services should be disabled or redirected to a local server. We should use one of the strings recognised by the parser: https://hg.mozilla.org/webtools/tbpl/file/tip/php/inc/GeneralErrorFilter.php#l37 ...which is soon hopefully going to have "ERROR: " added (in bug 1018910) - which is perhaps more suitable than something too test-centric like "TEST-UNEXPECTED-FAIL" or "Automation Error:".
I could be talked into writing a patch borrowing "fatal error" from line 44.
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #1) > I could be talked into writing a patch borrowing "fatal error" from line 44. Waiting to see how bug 1035773 and thus bug 1018910 pans out :-)
Bug 1018910 added TBPL support for the new "FATAL ERROR" style prefixes that are now being used by failure cases where an automation related string would be inappropriate (eg bug 1035773), so let's just use that. I've also broken the error string across two lines, so that the bugzilla search term only includes the first, more relevant line.
Attachment #8466808 - Flags: review?(nfroyd)
Attachment #8466808 - Flags: review?(nfroyd) → review+
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
You need to log in before you can comment on or make changes to this bug.