These are not interpreters, they are contexts where your script runs.
They do differ because for instance the same .html page ran from a server sent through HTTPS doesn't represent the same security risks as the same page served from the file://
protocol.
While I couldn't find the exact culprit in this case, I found that for Firefox it's related to the WebSocket connection that your library is creating, which does throw in StackSnippets, but I couldn't find why exactly it throws in StackSnippets.
To be clear, the problem is not that they can't find the DOM element, but rather that the code throws a DOMException which is only half-handled, and thus the script execution halts.
try {
const connection = new WebSocket('wss://b95e1176.databases.neo4j.io:7687/');
console.log('passed')
}
catch(err) {
console.log('caught');
}
Among the few differences between jsfiddle's iframes and StackSnippets ones I first suspected the lack of allow-same-origin
clause in StackSnippets, then their lack of window.origin
, but given I tried to reproduce both cases in jsfiddle and it still worked there, I now suspect this has to do with the HTTP headers sent to the page, but as I said I'm not sure.
Anyway, all this to say that it is indeed expected that some code may work differently in various contexts, and it is also expected that different browsers will use various security measures, you may even expect that a future version of the same browser behaves differently in the same context.
Unfortunately there isn't much we as web-dev can do apart from extensive and regular testings.