hackademix / nscl

NoScript Commons Library
GNU General Public License v3.0
23 stars 9 forks source link

TypeError: can't access dead object in patchWindow.js #4

Open jamhubhub opened 2 years ago

jamhubhub commented 2 years ago

First, I apologize as I cannot reproduce consistently the issue and cannot share the code that leads to it (it is from a private website). If this bug report is useless, feel free to close it.

So, this happens on a fairly complex javascript application that manipulates the DOM and uses Web Workers. The browser used is Tor Browser 11.0.14, based on Mozilla Firefox 91.10.0esr, in its default configuration (so, noscript is enabled by default). Sometimes, when using the application, all DOM manipulations seem to stop working, and a page reload is required. Specifically, running:

document.createElement("div").appendChild(document.createElement("div"))

in the browser javascript console throws a DOMException. When catched with a try-catch block, the catched error is undefined. Using the browser debugger step by step shows the original exception. On line 285 of the NSCL patchWindow.js, this:

for (let j = 0; j in win; j++) {

produces this exception:

TypeError: can't access dead object

and indeed, win appears as DeadObject in the browser debugger. See MDN about dead objects:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Dead_object

Do you know if the issue might be coming from your software or if I'm looking in the wrong direction?

jamhubhub commented 2 years ago

I found a way to reproduce the issue consistently with a minimal code example. It looks like the issue comes either from the NSCL or from Firefox / Tor Browser? Steps to reproduce the issue:

  1. Create a file first.html:
<html>
    <head>
        <meta charset="UTF-8">
    </head>
    <body>
        <button onclick="document.createElement('div').appendChild(document.createElement('div'));">
            Add something to the DOM
        </button>
        <br/>
        <a href="second.html">second.html</a>
    </body>
</html>
  1. Create a file second.html:
<html>
    <head>
        <meta charset="UTF-8">
    </head>
    <body>
    </body>
</html>
  1. Open Tor Browser 11.0.14, based on Mozilla Firefox 91.10.0esr, NoScript version 11.4.6, and set the Tor Browser security level to "Safer". Open the browser console to monitor the issue.

  2. Open first.html as a local file. Click the button, no issue. Click the link. Go back to the previous page using the browser "left arrow" button. Click the button again, a DOMException is thrown. The browser console indicates the exception comes from patchWindow.js:299. Using the browser debugger seems to indicate the initial exception comes from patchWindow.js:285.

The issue doesn't come up when using Tor Browser security level "Normal".

hackademix commented 2 years ago

Hi, thank you for the report and the reduced test case. At first glance, it seems a lifecycle mismatch between the page retrieved from BF Cache and the extension content script. Not your code's fault, anyway. Investigating...

hackademix commented 1 year ago

Hello, I've recently made some changes to the script injection machinery recently which are likely to affect this issue. Can you still reproduce on NoScript 11.4.19rc3? Thanks!

mriehm commented 1 year ago

I have been seeing this problem in Firefox on Android. On initial load of a Wikipedia page, tapping the article section headers successfully expands/collapses that section of the article. However, if I tap a link within the article to go to a different article, and then I use the Back button to go back to the original article, tapping the article section headers will no longer expand/collapse the section. When I attached Firefox debugging, I see that tapping the section header triggers the same 'TypeError: can't access dead object' error for the 'win' object in the line 'for (let j = 0; j in win; j++)' reported in this issue.

I am on version 11.4.25 of the extension.

hackademix commented 1 year ago

On initial load of a Wikipedia page

Thank you very much for this test case. I could reproduce indeed, and I'm investigating it.