User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36

Steps to reproduce:

1. Create a Firefox extension
2. Have the following code fire when you click the button:

const win = window.open(https://localhost:8000);
console.log(win);
function testFunc(myWin){
win.postMessage('test', 'https://localhost:8000');
}
window.setInterval(testFunc, 5000, win);

3. Note that localhost did open but never received any message events.
4. Note on the extension a logged error about accessing a dead object.

Actual results:

Firefox reports a dead object being accessed both in the console.log and the

Expected results:

Firefox should recognize that the window object is still in use and save the reference until the setInterval has been cleared.

The documentation (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Dead_object) says that "The JavaScript exception "can't access dead object" occurs when Firefox disallows add-ons to keep strong references to DOM objects after their parent document has been destroyed to improve in memory usage and to prevent memory leaks." Even trying to access the win object right after window.open says the object is already dead.

This does work in Chrome, more context: https://stackoverflow.com/questions/73954279/firefox-garbage-collection-and-a-window-open-object-combined-with-a-settimeout

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

My apologies on any confusion for the steps to recreate, this is my first bug submission. I wanted to restate the steps a little cleared:

1. Create a Firefox extension
2. Create a simple webpage at localhost:8000 with an event listener that is looking for events with 'message'
3. Have the following code fire when you click a button in the UI of the extension:

const win = window.open(https://localhost:8000);
console.log(win);
function testFunc(myWin){
win.postMessage('test', 'https://localhost:8000');
}
window.setInterval(testFunc, 5000, win);

1. Note that the console.log logs out a dead object
2. Note that localhost did open but never received any message events
3. Note on the extension a logged error about accessing a dead object
4. Note that whether you pass in the window to the setTimeout as a parameter or not, the result is the same

Hello rider.jensen,

I’m from Webextensions QA and I’m trying to reproduce the issue in order to confirm it. However, I have limited knowledge with creating extensions.
As such, would you be so kind as to attach the test extension you used to uncover this issue, as well as the test webpage you mentioned in Comment 2?

Thank you !

Hi Alex, thanks for responding

To reduce confusion, you can actually reproduce this bug with just an extension, you don't need the secondary page since the dead object will appear with all webpages from what I have seen. Here are the steps

1. Install the extension in Firefox
2. On the about:debugging page, click "Inspect" to open the console for the extension
3. Make sure in the console, in the settings area, you have "Persist Logs" checked
4. Open the popup
5. Click the "Test" button
6. Note that a new tab opens and navigates to google.com
7. Wait 3 seconds
8. Note an error message in the console about accessing a dead object

Let me know if I can clarify any more.

Hello rider.jensen ! Thank you for the extension and additional details !

I have reproduced the issue on the latest Nightly (107.0a1/20221009212852), Beta (106.0b9/20221006191955) and Release (105.0.320221007134813) under Windows 10 x64 and Ubuntu 16.04 LTS.

After clicking the “Test” button from the extension pop-up, the add-on console will start getting populated with “Uncaught TypeError: can’t access dead object”, confirming the issue.

For further details, see the attached screenshot.

Mozregression found this:

2022-10-18T10:37:41.151000: DEBUG : Found commit message:
Bug 1753048 - [devtools] Include the fallback window to the docShells array for webextension targets r=ochameau

Depends on D148489

This allows to properly set the cssErrorReportingEnabled flag on its docShell.
While we are not interested in css errors for this fallback window, the windowglobal target actor
will automatically set the flag on new root browsing contexts only if the previous one had the flag
set. This way when we switch to a valid webextension document (eg a popup), the flag will be set
and CSS errors will be reported.

Differential Revision: https://phabricator.services.mozilla.com/D148836

Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=240c921b8c75a8cb35f9aae5b99d5aaf4e9d166d&tochange=5092df1913d5091b814b9b98fa617921702f8ed4

Hope this is the right one. Otherwise, let me know and I’ll repeat the bisection.

Setting Regressed by field after analyzing regression range found by mozregression in comment #8.

:jdescottes, since you are the author of the regressor, bug 1753048, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

I doubt this was regressed by Bug 1753048. This bug fixed an issue which prevented to see console logs for webextensions. If there is no other way than using devtools / about:debugging to check the issue, you can try adding a background script (even empty) to the webextension. This workaround used to fix the missing log issue.

Maybe spoke too soon, even with the background script workaround I can't see the issue on 101, checking a bit more.

As I suspected, Bug 1753048 was not directly related. I will upload a modified version of the extension which will have logs on all Firefox versions and can be used to bisect.

However I suspect that this became more visible since we are keeping the webextension popups visible by default. The error only comes up if the webextension popup remains open for a few seconds. So with old about:debugging workflows, about:debugging would be in another tab, and the popup would disappear on the next click. So most likely users would dismiss the popup and wouldn't see the issue.

With the new UX, the toolbox is in a separate window and we prevent hiding the webextension popups, so it's much more likely that popups will remain on screen for a long time.

I tested Firefox 91, and there was the same error already, so if it's a regression it's probably very old.

You can use this version of the extension to check against Firefox versions which don't have the fix for logs.

@Julian
Thank you for the extension !

I’ve checked again using a range spanning Firefox 80 to 94 and all tested builds were affected. Mozregression ran until no builds could be found anymore and the bisection stopped. No regressor bug was produced. I can go further back if requested but at this point I think it’s a really old regression.

I also took notice of what Julian mentioned in Comment 13 regarding the state of the pop-up when triggering the issue.

In all cases the issue appeared, as per the provided STR, once I click the “Test” button from the add-on pop-up and the tab with google.com opens and gets focused, I don’t perform any other actions. I just wait a few seconds and then check the console. As Julian said, the pop-up remains open and the errors appear.

Now, if after I click the “Test” button and the tab with google.com opens I click on the tab so as the add-on pop-up gets dismissed, I no longer get the errors in the console. This appears to happen across all versions I tested. For example, see the attached video from Firefox 81.

The severity field is not set for this bug.
:mixedpuppy, could you have a look please?

For more information, please visit auto_nag documentation.