Quick summary of the issues that we spotted while looking at this: - getWalker will crash at https://searchfox.org/mozilla-central/rev/6bceafe72cad5d5752667b4b6bd595d3a4047ca3/devtools/server/actors/inspector/inspector.js#149-151 . This crash breaks the inspector - getHighlighterByType will crash in the `onXUL` helper called at https://searchfox.org/mozilla-central/rev/6bceafe72cad5d5752667b4b6bd595d3a4047ca3/devtools/server/actors/highlighters.js#567 . This does not lead to a blank styleeditor, it is simply visible in the logs. It seems `getWalker` comes from StyleEditorUI's `initializeHighlighter` which retrieves the inspector front immediately : ```javascript async _onTargetAvailable({ targetFront, isTopLevel }) { if (isTopLevel) { await this.initializeHighlighter(targetFront); // ... } }, async initializeHighlighter(targetFront) { const inspectorFront = await targetFront.getFront("inspector"); // ... } }, ``` And the inspector front initialize method does: ``` javascript // async initialization async initialize() { await Promise.all([ this._getWalker(), this._getHighlighter(), this._getPageStyle(), this._startChangesFront(), ]); } ``` To fix `getWalker`, we first need to check if XUL documents still need to be handled (we announced their removal at cf https://groups.google.com/forum/#!msg/firefox-dev/WGcGYaQgu3g/-Z5jtoWdEAAJ but maybe the code needs to stay for some reason). If we still need to handle this, then maybe we could simply listen to both "load" and "DOMContentLoaded" events, without checking the document type - since it might crash. After that `getWalker` is supposed to correctly wait for the document load before resolving, so we should be ok. For the issue in `getHighlighterByType`, I thought it was also coming from the inspector front initialization. But that doesn't seem to be the case so we first need to check if it comes from `initializeHighlighter` in StyleEditorUI.jsm. The document.readyState was consistently "uninitialized" when I was seeing this failure, which is weird because in theory we should already have resolved getFront("inspector") which means the walker should be ready. Unless the call comes from another spot?
Bug 1604126 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Quick summary of the issues that we spotted while looking at this: - getWalker will crash at https://searchfox.org/mozilla-central/rev/6bceafe72cad5d5752667b4b6bd595d3a4047ca3/devtools/server/actors/inspector/inspector.js#149-151 . This crash breaks the styleeditor - getHighlighterByType will crash in the `onXUL` helper called at https://searchfox.org/mozilla-central/rev/6bceafe72cad5d5752667b4b6bd595d3a4047ca3/devtools/server/actors/highlighters.js#567 . This does not lead to a blank styleeditor, it is simply visible in the logs. It seems `getWalker` comes from StyleEditorUI's `initializeHighlighter` which retrieves the inspector front immediately : ```javascript async _onTargetAvailable({ targetFront, isTopLevel }) { if (isTopLevel) { await this.initializeHighlighter(targetFront); // ... } }, async initializeHighlighter(targetFront) { const inspectorFront = await targetFront.getFront("inspector"); // ... } }, ``` And the inspector front initialize method does: ``` javascript // async initialization async initialize() { await Promise.all([ this._getWalker(), this._getHighlighter(), this._getPageStyle(), this._startChangesFront(), ]); } ``` To fix `getWalker`, we first need to check if XUL documents still need to be handled (we announced their removal at cf https://groups.google.com/forum/#!msg/firefox-dev/WGcGYaQgu3g/-Z5jtoWdEAAJ but maybe the code needs to stay for some reason). If we still need to handle this, then maybe we could simply listen to both "load" and "DOMContentLoaded" events, without checking the document type - since it might crash. After that `getWalker` is supposed to correctly wait for the document load before resolving, so we should be ok. For the issue in `getHighlighterByType`, I thought it was also coming from the inspector front initialization. But that doesn't seem to be the case so we first need to check if it comes from `initializeHighlighter` in StyleEditorUI.jsm. The document.readyState was consistently "uninitialized" when I was seeing this failure, which is weird because in theory we should already have resolved getFront("inspector") which means the walker should be ready. Unless the call comes from another spot?