+++ This bug was initially created as a clone of Bug #1276366 +++ Applying the patch from bug 1276366 that helps eliminate chrome <-> chrome leaks I'm seeing a failure in |browser_toolbox_tool_ready.js| [1]: > Full message: TypeError: can't access dead object > Full stack: getActiveElement@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/client/shared/vendor/react.js:20006:7 > ... snip ... > DomView.prototype.initialize@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/client/dom/content/dom-view.js:50:22 > DomView.prototype.onMessage@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/client/dom/content/dom-view.js:58:7 > DomPanel.prototype.postContentMessage@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/client/dom/dom-panel.js:205:5 > DomPanel.prototype.refresh/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/client/dom/dom-panel.js:114:7 > ... snip ... This indicates that the dom toolbox is still loading when we finish the test. Removing the dom toolbox from testing bypasses the error. As a temporary measure I can also use: > thisTestLeaksUncaughtRejectionsAndShouldBeFixed("TypeError: can't access dead object"); So in general it seems like we're testing that the toolbox is ready, asserting that it is, but it actually is not. It's possible this toolbox just likes to periodically update, if so we should properly unload it before finishing the test. STR: 1) Apply patch from bug 1276366 2) |./mach test devtools/client/framework/test/browser_toolbox_tool_ready.js| [1] https://dxr.mozilla.org/mozilla-central/rev/4c05938a64a7fde3ac2d7f4493aee1c5f2ad8a0a/devtools/client/framework/test/browser_toolbox_tool_ready.js

Honza, can you assess the priority of this? Moving back to DOM, I know the test is in Framework, but seems like the root cause is DOM panel somewhere.

The DOM panel sends the 'ready' event when the Pane.open() method is called [1] (as part of the panel construction process). It's too soon (for tests) since the panel initialization process involves fetching data from the backend. The fetch is initiated automatically in DOMView (when the TreeView renders 'window' properties for the first time). It's done through 'fetchProperties' action and `DomProvider` object accessed within panel's iframe (exposed from the chrome scope). Window properties are fetched using `prototypeAndProperties` packet. We might want to fire the 'ready' event after the initial RDP packet is done. I am not sure if that has any impact on UX (e.g. toolbox open timing), but the Inspector panels does pretty much the same - it fires 'ready' event when the markup is loaded [2] I am marking as P2 since this nobody is working on it now, but this should be fixed. If it's blocking bug 1276366 we can either apply the 'thisTestLeaksUncaughtRejectionsAndShouldBeFixed' workaround or find someone to fix it properly. Honza [1] https://dxr.mozilla.org/mozilla-central/rev/24763f58772d45279a935790f732d80851924b46/devtools/client/dom/dom-panel.js#56 [2] https://dxr.mozilla.org/mozilla-central/rev/24763f58772d45279a935790f732d80851924b46/devtools/client/inspector/inspector-panel.js#246