1075122 - Throbber never stops throbbing in remote tab

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Brad Lassey [:blassey] (use needinfo?)]

If I load this URL, the throbber/spinner never stops in a remote tab. In a non-e10s window it loads and stops throbbing.

No idea if this is networking or some front end logic issue, but filing under networking for now.

Comment 2

[Brad Lassey [:blassey] (use needinfo?)]

Also, if I hit the stop button, it has no effect

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I see this in the browser console:
NS_NOINTERFACE: Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIWebProgress.DOMWindow]
browser-child.js:64

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

Bug 1096506 and bug 1096850 might be related.

Comment 5

[Tim Taubert [:ttaubert] (inactive)]

And it seems to be something from platform.twitter.com again.

Comment 6

[Tim Taubert [:ttaubert] (inactive)]

We receive an OnStateChange notification for https://platform.twitter.com/jot.html. Flags are STATE_STOP and STATE_IS_WINDOW. How can accessing aWebProgress.DOMWindow fail with NS_NOINTERFACE here?

Comment 7

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: fix-throbber

I looked into this a bit more. The reason DOMWindow throws NS_NOINTERFACE is because we go through this call chain:
GetDOMWindow: http://hg.mozilla.org/mozilla-central/file/64206634959a/uriloader/base/nsDocLoader.cpp#l894
nsDocShell::GetInterface: http://hg.mozilla.org/mozilla-central/file/64206634959a/docshell/base/nsDocShell.cpp#l1021
EnsureScriptEnvironment: http://hg.mozilla.org/mozilla-central/file/64206634959a/docshell/base/nsDocShell.cpp#l12471

The last one returns false because nsDocShell::Destroy has already been called. It looks like it's called when the corresponding frame is removed from the DOM. Not too surprising for this twitter page.

I was curious why this only happens in e10s. I added a .DOMWindow getter to onStateChange in tabbrowser.xml and got the same exception. The only difference in e10s is that we unconditionally call this getter, while non-e10s does it only when it needs that field.

I just threw an empty try catch around it. It seems like the best we can do.

Comment 8

[Tim Taubert [:ttaubert] (inactive)]

Comment on attachment 8523041 [details] [diff] [review]
fix-throbber

Review of attachment 8523041 [details] [diff] [review]:
-----------------------------------------------------------------

Works great here with IRCCloud. Thanks!

Comment 10

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/23c81cdab64f

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/23c81cdab64f