On 5/7/14, 4:21 PM, Gavin Sharp wrote:
What does "get rid of strict warnings as errors for xpcshell tests" mean in practice?
It means that our non-standard spidermonkey "strict mode" (not the actual strict mode) console warnings would continue to simply be console warning messages rather than console error messages in xpcshell tests.
I don't understand how you're getting into the situation of "accidentally turn[ing] on strict warnings as errors".
Eddy can explain this better than me because he's been deep in these trenches the last couple weeks, but I'll give it a shot.
When xpcshell tests are run, they flip a bit on the initial JSContext that's off by default that tells spidermonkey "make the strict warning messages into error messages". Depending on how you load JS code, you might share the JSContext or you might not; for example, loadSubScript shares the JSContext, while Cu.import doesn't. Eddy has been making changes to the debugger server so that it will run in workers so we can debug workers. He has been replacing Cu.import calls with calls to a module loader that uses loadSubScript underneath the hood. So now code that used to be evaluated with this bit flipped off (because it is off by default and it was getting its own JSContext) is being evaluated with the bit on (because it is inheriting the JSContext from the xpcshell test). The result is error messages which cause devtools tests to fail.
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
