0

I recently had a problem that the same code run at some engines and not in others, and the reason is that DOM method cannot find the elements. This stems another question: given the same code, why do some interpreters/engines be able to find the elements, and some are not?

Interpreters that are able to find the elements:

  • JSFiddle
  • StackSnippet if you are using Edge

Interpreters that aren't able to find the elements:

  • StackSnippet if you are using Firefox (95.0.2 64-bit)
  • In Edge, which is opened by VSCode

Obviously having the interpreters know what you do is convenient, but is there any drawback to automatically assume what you mean, so that the other ones don't implement this feature?

This seems to be the browser issue. Is that correct?

Ooker
  • 1,276
  • 3
  • 21
  • 49

2 Answers2

2

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.

Kaiido
  • 103,356
  • 8
  • 183
  • 231
-2

The structure of

<div id="foo" data-function="bar">string1</div>
<div id="lorem" data-function="ipsum">string2</div>
<div id="dolor" data-function="es">string3</div>

has for each element:

  • an id
  • a data-function
  • an inner text (some string)

The Javascript of

function myfunction(context, id, func, str) {
    context[id] = undefined;
    return context[func] = function() {
        var config = {
            a: id,
            b: str,
            //otherConfigs...
        };
        
        context[id] = new NeoVis.default(config);
        context[id].render();
        console.log(`function ${func} was called and ${id} is the id`);
    };
}

for (let item of document.querySelectorAll("#foo, #lorem, #dolor")) {
    myfunction(window, item.id, item.getAttribute("data-function"), item.innerText)();
}

has the last three lines initiating the call for myfunction. Now, if you do not have elements with the ids of foo, lorem and dolor, then querySelectorAll returns an empty array-like-object and myfunction will never be called. You will need to make sure that your div elements can be properly found and change the selector accordingly. Then, define their functions as values for data-function and their strings as inner texts for the divs.

Lajos Arpad
  • 53,986
  • 28
  • 88
  • 159
  • I wonder about the reason of the down-vote. The original question of the asker (see https://stackoverflow.com/questions/70555052/a-piece-of-js-code-is-needed-to-use-multiple-times-with-different-values-and-fun/70555213#70555213) clarifies the goal to be achieved and the issue is that in the example code we have a structure to work with and at the actual site there is some other structure that does not support this feature yet. So I'm pretty sure that this answer addresses the question and provides helpful information. – Lajos Arpad Jan 04 '22 at 14:38
  • No it doesn't, the current question is "given the same code, why do some interpreters/engines be able to find the elements, and some are not?" Your answer absolutely doesn't answer that. It is saying that their code might be the culprit, if that was the case, then that would either not be "the same code", either not be working anywhere. (And for the [original issue](https://stackoverflow.com/questions/70555052/) OP faced it's because these were not the same code as was found in the comments there, they had their – Kaiido Jan 05 '22 at 02:40
  • @Kaiido the asker identified JSFiddle as an interpreter and assumed that the engine works differently for the proof-of-concept which works properly from the actual page this needs to be implemented. If you reread the original question, then you will realize that the issue was not with the script being executed before the elements were parsed, actually the asker even mentioned that the code worked, but wanted to apply the same logic many times and avoid code duplication. You accepted the assumption of the asker about what the problem is. – Lajos Arpad Jan 05 '22 at 09:08
  • Sorry I got my link confused by your own, OP's original issue is https://stackoverflow.com/questions/70558494/why-does-the-same-code-run-at-some-engines-and-not-in-others But that doesn't change a thing about this question anyway, that your answer absolutely doesn't answer. – Kaiido Jan 05 '22 at 09:10
  • @Kaiido it was a follow-up to the link I gave you... – Lajos Arpad Jan 05 '22 at 09:11
  • @Kaiido I understand that you think I did not address the problem. It is because you approach it superficially. – Lajos Arpad Jan 05 '22 at 09:12
  • Still it's the one from which this very question came from. Because from that question they did realize that the same code executed in different environments (that they miscalled "interpreters") will execute differently. – Kaiido Jan 05 '22 at 09:13
  • @Kaiido it's not the same code... There is a webpage and there is a proof-of-concept. The proof-of-concept works, its application to the webpage does not. Quote from the comment section of the original question that I have shared with you: "I try to remove that dummy on your code, and.. it's only work in JSFiddle, but not in my local machine. I open a new question to solve this, hope to see you there" (please check it out). If you read that, you should realize that the asker misunderstood what the problem is when asking this question. – Lajos Arpad Jan 05 '22 at 09:17
  • @Kaiido anyway, thanks for letting me know about the reason for the downvote. In most cases the downvoter does not specify a reason, so, thanks for being informative about it. – Lajos Arpad Jan 05 '22 at 09:18