952169 - Tab slow to close (over a minute) due probably to sync XHR from onscroll.com

Status: RESOLVED WORKSFORME

(Firefox :: Tabbed Browser, defect)

Description

[nemo]

Confirmed in Stable and Nightly, OSX and Linux.  Unable to reproduce on Android mobile, but different network as well as different tab hnadling...
Profile:
http://people.mozilla.org/~bgirard/cleopatra/#report=5644bceca7b61015667bb9c3af2587910d4ede86

Opened the page in a new tab.  Waited for it to stop loading, scrolled down a little ways, then clicked the X.
Most of the time, but not always, the tab would not close.  After waiting 30 seconds to a minute, it closed.
mstange was unable to reproduce.  Could be due to my connection being slower.

mstange says (mildly edited):
"it definitely is a sync XHR, and the profile showed me the part of the JS that is responsible for it"
"it's obfuscated: f.open("GET",b,!1)"
"the javascript function q() is responsible, and if you right-click on that and choose View JS Source, you'll find the part of the code that I quoted"
"the fact that it's a nested event loop is not that obvious because this profile only shows simplified call stacks, but usually you don't have Timer::Fire under content JS, for example"
"if you get the profile on OS X instead, you should see more complete callstacks"
"for some reason we have frame pointers and full symbols in our OS X binaries, but not in our linux binaries. I don't know why"

< nemo> mstange: hm. I wonder if that's why scrolling seemed important
< nemo> mstange: onscroll.com fires ads on load
< mstange> nemo: probably!

So. Working on that OSX profile next, will post an update once I have it.

Oh. He also says it is probably not a dupe of bug #823030  since no CORS.
Although sync xhr so... related?

Comment 1

[nemo]

http://people.mozilla.org/~bgirard/cleopatra/#report=87b62e2b10b3b7578625f2f581ed5bd4484c6fef

Here's the OSX profile he'd asked for

Comment 2

[nemo]

Fixed OSX profile (network here had been blocking updates and nightly was horribly out of date on my OSX machine - if only the download url for updates was https...):
http://people.mozilla.org/~bgirard/cleopatra/#report=b5475848a919b392c9b5e3b35b6c1879b9a147a6

Comment 3

[nemo]

Erm.  And I meant "onscroll loads ads on visibility" but mstange apparently parsed it ok.
Anyway, yeah, scrolling seems pretty important, and sometimes I had to try it a couple of times.
I'm guessing the behaviour, if you can't replicate it over there, could be simulated by pointing the server it is hitting at localhost or something.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Haven't managed to reproduce.
(And there isn't evidence that Bug 823030 is actually sync XHR bug.)

Comment 5

[nemo]

m'k, well, I can reproduce pretty easily in stable and nightly on OSX and Linux.  Haven't tried Windows yet.
I guess I can fire up console to look for anything hanging or erroring in transit in case you need to simulate it.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

I was testing on linux.... and apparently I managed to write comment to 
https://bugzilla.mozilla.org/show_bug.cgi?id=823030#c1


As far as I see _beginRemoveTab doesn't expect that content might spin event loop.
http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml?rev=4e1073ed5389#1857

It is not clear to me what behavior we want here.

Comment 7

[nemo]

Ah. Cool.  Well, whatever the behaviour you want there, tabs not closing for a minute while they do whatever is presumably not it.  ;)

Comment 8

[nemo]

Encountered this behaviour on another site:
http://www.independent.co.uk/news/science/risk-of-supervolcano-eruption-big-enough-to-affect-the-world-far-greater-than-thought-say-scientists-9040073.html

Comment 9

[nemo]

Hm. Another oddity.  I was trying to open the browser console to see if the site was using the same ad service as the other one.
Hit command + shift + j and... The Tools menu blinked briefly, but no console appeared.
So I guess the load hang also prevents opening the console.  At least on my OSX machine.

Comment 10

[nemo]

I can't reproduce this at all anymore, and given this bug is 11 years old, I'm going to guess something fixed it in the interim. Closing.