This attached test extension is an MV2 extension that includes: - no background page - a sidebar panel loading an extension page that is then creating two more sub frames: - the first subframe is going to load another extension page from the same extension - the second subframe is going to load a webpage (https://wikipedia.org, because it is one that load fine as is in a subframe) This test extension is meant to help with testing corner cases related to reloading the addons with the addon debugging toolbox still open, in particular to reproduce the scenario where the first extension page loaded right away after the extension is reloaded isn't the background page (but the sidebar panel extension page). #### STR for the issue "leaked targets on reloading an extension with an extension sidebar panel" So far I managed to hit this issue only with an extension with a sidebar panel (even if I'm not sure yet how the sidebar panel contributes to be able to hitting the issue based on what it seems to be the underlying issue). STR: - start a Firefox instance with all the stack of patches attached to this bug applied - install this test extension temporarily from about:debugging - open the addon debugging toolbox - open the frame selector and confirm that "/sidebar.html" and "/subframe.html" are listed in the frame selector popup - reload the addon while the addon debugging toolbox is still open - open the frame selector again: - Actual behavior: the frame selector popup shows two times both "/sidebar.html" and "/subframe.html" (and that will increase further on each addon reload) - Expected behaviror: the frame selector popup should show only once the "/sidebar.html" and "/subframe.html" targets The same exception can also be hit without the changes attached to this bugzilla issue, but in that case the side-effect of the issue surfaces differently, with the frame selector panel disappearing instead of the list frame selector popup to be growing because of the old and new target actors be all listed there, as in the STR described above. In the browser console the following error is being logged right before this issue is being hit: ``` console.error: (new TypeError("can't access property \"name\", policy is null", "resource://devtools/server/actors/targets/window-global.js", 629)) TypeError: can't access property "name", policy is null: get title@resource://devtools/server/actors/targets/window-global.js:629:7 form@resource://devtools/server/actors/targets/window-global.js:751:7 destroyTargetActor@resource://devtools/server/connectors/js-process-actor/ContentProcessWatcherRegistry.sys.mjs:293:30 onNewTargetActor/<@resource://devtools/server/connectors/js-process-actor/ContentProcessWatcherRegistry.sys.mjs:233:37 newListener@resource://devtools/shared/event-emitter.js:169:27 _emit@resource://devtools/shared/event-emitter.js:242:32 emit@resource://devtools/shared/event-emitter.js:186:18 emit@resource://devtools/shared/event-emitter.js:330:18 destroy@resource://devtools/server/actors/targets/window-global.js:867:10 _onDocShellDestroy@resource://devtools/server/actors/targets/window-global.js:1143:14 observe@resource://devtools/server/actors/targets/window-global.js:1085:12 ``` Preventing that exception from being hit (e.g. by just [adding optional changing to this line](https://searchfox.org/mozilla-central/rev/b9e7c4300ba972a4c98bf463fc046e8cd9367175/devtools/server/actors/targets/window-global.js#595)) seems to prevent the issue as described in the STR from being hit, and so it seems to suggest that hitting this exception may be preventing us from removing the target actors successfully (and then entries for the old and new target actors to be piling up in the frame selector).
Bug 1754452 Comment 16 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This attached test extension is an MV2 extension that includes: - no background page - a sidebar panel loading an extension page that is then creating two more sub frames: - the first subframe is going to load another extension page from the same extension - the second subframe is going to load a webpage (https://wikipedia.org, because it is one that load fine as is in a subframe) This test extension is meant to help with testing corner cases related to reloading the addons with the addon debugging toolbox still open, in particular to reproduce the scenario where the first extension page loaded right away after the extension is reloaded isn't the background page (but the sidebar panel extension page). #### STR for the issue "leaked targets on reloading an extension with an extension sidebar panel" So far I managed to hit this issue only with an extension with a sidebar panel (even if I'm not sure yet how the sidebar panel contributes to be able to hitting the issue based on what it seems to be the underlying issue). STR: - start a Firefox instance with all the stack of patches attached to this bug applied - install this test extension temporarily from about:debugging - open the sidebar through the Firefox menu, pressing Alt-V and then clicking on View -> Sidebar -> test-sidebar-nobg - open the addon debugging toolbox - open the frame selector and confirm that "/sidebar.html" and "/subframe.html" are listed in the frame selector popup - reload the addon while the addon debugging toolbox is still open - open the frame selector again: - Actual behavior: the frame selector popup shows two times both "/sidebar.html" and "/subframe.html" (and that will increase further on each addon reload) - Expected behaviror: the frame selector popup should show only once the "/sidebar.html" and "/subframe.html" targets The same exception can also be hit without the changes attached to this bugzilla issue, but in that case the side-effect of the issue surfaces differently, with the frame selector panel disappearing instead of the list frame selector popup to be growing because of the old and new target actors be all listed there, as in the STR described above. In the browser console the following error is being logged right before this issue is being hit: ``` console.error: (new TypeError("can't access property \"name\", policy is null", "resource://devtools/server/actors/targets/window-global.js", 629)) TypeError: can't access property "name", policy is null: get title@resource://devtools/server/actors/targets/window-global.js:629:7 form@resource://devtools/server/actors/targets/window-global.js:751:7 destroyTargetActor@resource://devtools/server/connectors/js-process-actor/ContentProcessWatcherRegistry.sys.mjs:293:30 onNewTargetActor/<@resource://devtools/server/connectors/js-process-actor/ContentProcessWatcherRegistry.sys.mjs:233:37 newListener@resource://devtools/shared/event-emitter.js:169:27 _emit@resource://devtools/shared/event-emitter.js:242:32 emit@resource://devtools/shared/event-emitter.js:186:18 emit@resource://devtools/shared/event-emitter.js:330:18 destroy@resource://devtools/server/actors/targets/window-global.js:867:10 _onDocShellDestroy@resource://devtools/server/actors/targets/window-global.js:1143:14 observe@resource://devtools/server/actors/targets/window-global.js:1085:12 ``` Preventing that exception from being hit (e.g. by just [adding optional changing to this line](https://searchfox.org/mozilla-central/rev/b9e7c4300ba972a4c98bf463fc046e8cd9367175/devtools/server/actors/targets/window-global.js#595)) seems to prevent the issue as described in the STR from being hit, and so it seems to suggest that hitting this exception may be preventing us from removing the target actors successfully (and then entries for the old and new target actors to be piling up in the frame selector).