Closed Bug 1075122 Opened 5 years ago Closed 5 years ago

Throbber never stops throbbing in remote tab

Categories

(Core :: Networking, defect)

x86
macOS
defect
Not set
Points:
2

Tracking

()

RESOLVED FIXED
mozilla36
Iteration:
36.3
Tracking Status
e10s m5+ ---

People

(Reporter: blassey, Assigned: billm)

References

()

Details

Attachments

(1 file)

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.
Duplicate of this bug: 1073649
Also, if I hit the stop button, it has no effect
I see this in the browser console:
NS_NOINTERFACE: Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIWebProgress.DOMWindow]
browser-child.js:64
Flags: qe-verify?
Flags: firefox-backlog+
Points: --- → 2
And it seems to be something from platform.twitter.com again.
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?
Attached patch fix-throbberSplinter Review
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.
Assignee: nobody → wmccloskey
Status: NEW → ASSIGNED
Attachment #8523041 - Flags: review?(ttaubert)
Comment on attachment 8523041 [details] [diff] [review]
fix-throbber

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

Works great here with IRCCloud. Thanks!
Attachment #8523041 - Flags: review?(ttaubert) → review+
https://hg.mozilla.org/mozilla-central/rev/23c81cdab64f
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Iteration: --- → 36.3
Duplicate of this bug: 1096506
QA Whiteboard: [good first verify][verify in Nightly only]
Flags: qe-verify? → qe-verify-
You need to log in before you can comment on or make changes to this bug.