Closed
Bug 1142752
Opened 10 years ago
Closed 9 years ago
(NS_NOINTERFACE) [nsIWebProgress.DOMWindow] exception in_docShellsToWindows when opening customize mode
Categories
(DevTools :: Framework, defect)
Tracking
(firefox43 fixed)
RESOLVED
FIXED
Firefox 43
Tracking | Status | |
---|---|---|
firefox43 | --- | fixed |
People
(Reporter: bgrins, Assigned: ochameau)
References
Details
Attachments
(1 file)
(deleted),
patch
|
jryans
:
review+
|
Details | Diff | Splinter Review |
I believe this started after bug 1059308.
STR:
Open browser toolbox (with --jsdebugger flag or using menu item)
Open customize mode (you may need to do this twice if you opened BT via the menu item)
See this error in the Browser Console:
Handler function threw an exception: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIWebProgress.DOMWindow]" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js :: TabActor.prototype._docShellsToWindows/< :: line 1003" data: no]
Stack: TabActor.prototype._docShellsToWindows/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1003:10
TabActor.prototype._docShellsToWindows@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1000:0
TabActor.prototype._notifyDocShellsUpdate@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1026:18
TabActor.prototype._onDocShellCreated/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:978:6
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:82:13
Also happening when loading websites, e.g.
https://photographylife.com/what-is-exif-data
http://www.lawblog.de/
http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_iframe
! Only with e10s off.
Affected:
Nightly 40.0a1
Aurora 39.0a2
Regression-range:
m-c:
Last good revision: 0189941a3fd5 (2015-03-06)
First bad revision: 43fb1f92e8d4 (2015-03-07)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0189941a3fd5&tochange=43fb1f92e8d4
m-i:
Last good revision: 1e4b76918021
First bad revision: 43fb1f92e8d4
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1e4b76918021&tochange=43fb1f92e8d4
fx-team:
Last good revision: 28a727d25fa7
First bad revision: 7697ad4919e7
Pushlog:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=28a727d25fa7&tochange=7697ad4919e7
Updated•10 years ago
|
Comment 2•9 years ago
|
||
I'm seeing this error in nightly when loading this page and opening the "Style editor" tab in devtools:
http://m.mlb.com/game/2015/08/20/415456/indians-vs-yankees#game=gid_2015_08_20_clemlb_nyamlb_1,game_state=Wrapup,tz=false,game_tab=wrap
This seems like a regression since the current release version because the style panel opens OK there. Is this still this bug? Should it be flagged as a high-pri regression, or should I report another one?
Flags: needinfo?(bgrinstead)
Comment 3•9 years ago
|
||
Right - comment #1 also confirms it happens in the wild. Probably happens with E10S off on any page with an IFRAME.
Handler function threw an exception: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIInterfaceRequestor.getInterface]" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js :: DebuggerProgressListener.prototype._getWindowsInDocShell/< :: line 2118" data: no]
Stack: DebuggerProgressListener.prototype._getWindowsInDocShell/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:2118:1
DebuggerProgressListener.prototype._getWindowsInDocShell@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:2117:12
DebuggerProgressListener.prototype.watch@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:2092:21
TabActor.prototype._onDocShellCreated/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1149:9
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:83:14
Line: 2118, column: 0
Reporter | ||
Comment 4•9 years ago
|
||
When I open this page [0] and then directly open the Style Editor (shift+F7) I am seeing an error, but it's different from the one in Comment 3. Everything seems to generally function after the error happens though. Are you seeing any breakage in the tools, or just the error in the console?
Forwarding request to Alex since the regression range in Comment 1 points to Bug 1059308.
Here's the error I see FWIW:
console.error:
Message: TypeError: this.transport is null
Stack:
DSC_send@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js:1339:5
Actor<._sendEvent@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:888:5
Actor<.initialize/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/protocol.js:866:11
emitOnObject@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:112:9
emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:89:38
MediaRuleActor<._matchesChange@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/stylesheets.js:327:5
BottomHost.prototype.create@resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/framework/toolbox-hosts.js:81:5
Toolbox.prototype.open/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/framework/toolbox.js:338:26
TaskImpl_run@resource://gre/modules/Task.jsm:314:40
TaskImpl@resource://gre/modules/Task.jsm:275:3
createAsyncFunction/asyncFunction@resource://gre/modules/Task.jsm:249:14
Task_spawn@resource://gre/modules/Task.jsm:164:12
Toolbox.prototype.open@resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/framework/toolbox.js:337:12
DevTools.prototype.showToolbox@resource:///modules/devtools/gDevTools.jsm:416:7
gDevToolsBrowser.selectToolCommand@resource:///modules/devtools/gDevTools.jsm:672:7
oncommand@chrome://browser/content/browser.xul:1:1
[0]: http://m.mlb.com/game/2015/08/20/415456/indians-vs-yankees#game=gid_2015_08_20_clemlb_nyamlb_1,game_state=Wrapup,tz=false,game_tab=wrap
Flags: needinfo?(bgrinstead) → needinfo?(poirot.alex)
Comment 5•9 years ago
|
||
The tool breaks completely: the CSS code never appears. Did you disable E10S when testing? I happened to use a profile with E10S off when I noticed.
Assignee | ||
Comment 6•9 years ago
|
||
I'm able to reproduce.
Assignee: nobody → poirot.alex
Flags: needinfo?(poirot.alex)
Assignee | ||
Comment 7•9 years ago
|
||
Note that we can see this exception while running this test with e10s turned on: browser/devtools/inspector/test/browser_inspector_remove-iframe-during-load.js
Assignee | ||
Comment 8•9 years ago
|
||
This patch prevent this exception in various scenarios: browser toolbox, regular page with e10s turned off,
or in the test I talked about.
I think the platform behavior changed a bit. We receive webnavigation-create event
with docshell being immediately destroyed.
I verified and we still get notifications for the document iframes,
it's just that we get some notification for some immediately-zombie docshell.
I would guess it is related to about:blank document or something...
https://treeherder.mozilla.org/#/jobs?repo=try&revision=b4573a818f82
Note that this exception happens within an executeSoon callback,
and the related docshell was a zombie one anyway,
I don't expect this exception to actually break anything.
While trying to reproduce this, I've seen the style editor being broken
for various other reasons. Sometimes with exceptions (access to Dead wrapper exception),
and some other times without any until you close the toolbox (getStylesheets pending request exception).
Both these exceptions, I think, are not related to iframe switching feature,
but results from internal races within style editor itself.
That would help if you could have a 100% reproducible STR for these two bugs.
Assignee | ||
Updated•9 years ago
|
Attachment #8652810 -
Flags: review?(jryans)
Attachment #8652810 -
Flags: review?(jryans) → review+
Comment 10•9 years ago
|
||
For testing purposes - also seen when choosing to connect to google.
Comment 12•9 years ago
|
||
Assignee | ||
Comment 13•9 years ago
|
||
I imagine this keybinding failure is due to the other changeset I bundled into this landing.
Let's see:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=5f2d8a9e1c28
Comment 15•9 years ago
|
||
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox43:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 43
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•