I don't know, off-hand.
(In reply to Jonas Allmann [:jallmann] from comment #0)
new Function to get the global object:
I would expect us not to hit this as the
freeGlobal should get the test its 'global'. If not, we can at least fix the Sinon.jsm consumers by defining a
global property on the loading context that points to the loading context itself.
new Function in
This isn't used inside the file, as far as I can tell from "find in page", and I would be surprised if any tests explicitly consumed it.
There are a few other
eval() uses, as well as some
setTimeout uses where the argument isn't clear, that I hope we don't hit in practice, but I'm not sure given that the trypush only has C++ stacks for assertions and no JS stack... You can probably use
xpc_DumpJSStack(true, false, false) with the assertion to get a JS stack.
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #3)
Personally, I think we are getting to a point with that project where I think it's better to just keep certain files like e.g. sinon-7.2.7.js in the whitelist. What do you think?
I don't know, it depends what we think the goal is. I think we should definitely get production (non-testing) code out of the whitelist. I think for the test-only code we could potentially only allow the eval() code if we're running in automation, ie we could use
xpc::AreNonLocalConnectionsDisabled()) to only allow this in automation and not elsewhere.