1103323 - Websites using sync XHR onbeforeunload hang the browser when closing the tab

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect)

Description

[Toady]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141113143407

Steps to reproduce:

Steps to reproduce:
Visit attached URL wait for the page to load then click the tab close button on the tab.


Actual results:

Not sure it this is a bug or note, But i myself and a few others can reproduce this sometimes it can take up to 10 minutes before the tab will close when the tab close button is pressed while visiting this web site.

http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/MS_DOS/Q_27612143.html

What happens:
Large delays in closing of the tab, Something is preventing the tab been closed and can take 30+ seconds to 10 minutes.

You can repetitively click the close button to no avail  



Expected results:

Tab should have closed when button clicked.

Note: Other websites open in the same session work correctly when the tab close button is pressed on the tab with the attached URL is affected, Not sure if this is a bug or note, But a web page should have control over the tab close button.

Comment 1

[Loic]

WFM with FF33 (win7).

Did you test in safe mode (https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode) and with a clean profile (https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles)?

Comment 2

[Toady]

(In reply to Loic from comment #1)
> WFM with FF33 (win7).
> 
> Did you test in safe mode
> (https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-
> mode) and with a clean profile
> (https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-
> firefox-profiles)?

Yes, It does the same in safemode and on new profile, Same on linux and mac, Also in the latest 34.0B11 it seems something on that site is preventing the tab close function like its been delayed or there is code being executed when the call to close the tab is sent ether way something is preventing the window|tab been closed and it can take a few seconds to a few minutes at times, In this you can open and close other tabs instantly but you can not force the tab with that url to close.

You can repetitively press the tab close button to no avail you have to wait for the site to stop what its doing, The site also shows different content if adblock plus is installed, There is a sliding banner at the bottom of the window that slowly scrolls up.

Ether way when the tab close button is pressed unless you have changed|entered data and a prompt to stay on this page|leave this page is shown, When the tab close button is pressed the tab should close instantly not 30 seconds + to 10 minutes.

The same thing happens when you only have that url open in the browser and you select the window close button, The browser closing is delayed as well.

Comment 3

[:Gijs (he/him)]

Do you log in on this site first or something? I can't reproduce either (using 34 beta).

Can you create a CPU profile and share it via cleopatra, so we can figure out what's taking so long? And I presume you don't mean /literally/ 10 minutes of lockup? Or does the browser continue to respond? How long does it actually take until the tab closes?

Comment 4

[Toady]

(In reply to :Gijs Kruitbosch from comment #3)
> Do you log in on this site first or something? I can't reproduce either
> (using 34 beta).
> 
> Can you create a CPU profile and share it via cleopatra, so we can figure
> out what's taking so long? And I presume you don't mean /literally/ 10
> minutes of lockup? Or does the browser continue to respond? How long does it
> actually take until the tab closes?

Hi Gijs Kruitbosch

No just normal view no login needed

Unfortunately i don't know how to do this(> Can you create a CPU profile and share it via cleopatra,) if there is a article on how that i could read then i could do it and know for future references.

Here is my main computer specs:
i7-4790k @5.0ghz GenuineIntel family 6 model 60 stepping 3 | 8
4x8gb g.skill 1600mhz
GTX 670 AdapterVendorID: 0x10de, AdapterDeviceID: 0x1189, AdapterSubsysID: 00000000, AdapterDriverVersion: 9.18.13.4460
D2D? D2D+ DWrite? DWrite+ D3D11 Layers? D3D11 Layers+ 
Sabertooh z97 mark 1
3 crucial m500 512gb in raid 0
closed circuit watercooler corsair h100i

The one with linux:
i7-3770k @4.5
4x4gb 1866mhz g.skill
GTX 570
Sabertooh z77
6 standard HDD 1tb WD
closed circuit watercooler corsair h100

The one with mac in VMware:
i7-2600k @4ghz
2x4gb 1333mhz g.skill
GTX 650
Sabertooh p67
1 standard HDD 1tb WD
closed circuit watercooler corsair h80

all machines are overclocked, However i did disable the overclock and under-clocked it in testing after you mentioned the CPU profile this made no difference but made the browser on both machines run slower. 

Here is a video of what is happening http://www.mediafire.com/watch/my6d1cfe4m7na7b/close_delay.mp4 I personally have not had it happen for longer then 2-3 minutes the person who told me was unable close the browser for 10 minutes, However they are now on a few weeks holiday so i am unable to get any information from them.

Upon further inspection seem to have worked out a possible cause.

The website does analytic's when you connect to the site they collect your browser information, The page you came from and the current page your on, They then start a php timer or counter and track your moments on there site then upon completion of your browsing session on the website when you click the close button php code is executed on the event similar to (beforeunload) in jquery where it gathers and calculates how long you spent on the website then updates the sites database where this information is stored.

I think the issue lies within the part where it adds the time spent on the page to the analytic data table that there is some issue on the site that at times causes very large delays in the closing window event, I the persons case who showed me the url because of the 10 minutes it took i think there was a hang that locked the browser up on the event similar to (beforeunload) in jquery.

But this is just a theory and the sites analytic may not be the cause.

Ether way there should be a way to force the window to close in events like this as unless you kill the process when its taking more then a minute you can't close the browser until the site completes what its doing.

So this maybe more a website issue then a actual bug, But still need to be able to force unresponsive tabs|windows to close.

If you require more information about my computer hardware please let me know.

Comment 5

[:Gijs (he/him)]

Yeah, this is essentially a website problem. They do a synchronous XHR when the page unloads, which then ends up hanging all the UI and so on. :-(

e10s might make this better. Otherwise, not sure what we can do here - there are millions of pages that depend on this kind of behaviour (and not just for questionable tracking things, but for things like saving your unsaved/unsent web app / form state so that you can continue where you left off when you come back, etc.). It's a bad idea, but it works and so people do it anyway.

So we can't just break the request, and we can't easily unhang the UI because of the sync XHR-ness of it... Olli, can we detect that a sync XHR is happening from onunload/onbeforeunload and make it async, but ensure it completes even if the page content otherwise goes away?

Comment 6

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

Sync XHR just spins event loop. It is not blocking main thread in Gecko.
Sync XHR is of course deprecated[1], so in a way this would be a site issue.
But why aren't we closing a tab? Is FF UI code expecting the reply from permitUnload?
Sounds like it shouldn't rely only on that, but have some timer too.

Making sync XHR async in some cases would be super regression risky so I wouldn't do that.
(it would be relatively easy to detect if we're in beforeunload or unload event listener).

This sounds like a (mostly) FF UI issue to me.



[1] https://xhr.spec.whatwg.org/#sync-warning

Comment 7

[:Gijs (he/him)]

(In reply to Olli Pettay [:smaug] from comment #6)
> Sync XHR just spins event loop. It is not blocking main thread in Gecko.
> Sync XHR is of course deprecated[1], so in a way this would be a site issue.
> But why aren't we closing a tab? Is FF UI code expecting the reply from
> permitUnload?
> Sounds like it shouldn't rely only on that, but have some timer too.

We call permitUnload and expect a reasonably-timed reply, yeah... Note that I can't actually reproduce a long slowdown, presumably because my internet connection is fast enough that the XHR takes up no noticeable time - probably the same applies to the people who wrote the site. :-\

Note that a timer on its own doesn't actually work well because permitUnload might be throwing up a dialog, and we wouldn't want to auto-close that dialog and prevent the user from making a decision.

It'd probably help if we exposed what permitUnload was blocked on somehow, so the browser code could check...

Comment 8

[Toady]

(In reply to :Gijs Kruitbosch from comment #7)
> (In reply to Olli Pettay [:smaug] from comment #6)
> > Sync XHR just spins event loop. It is not blocking main thread in Gecko.
> > Sync XHR is of course deprecated[1], so in a way this would be a site issue.
> > But why aren't we closing a tab? Is FF UI code expecting the reply from
> > permitUnload?
> > Sounds like it shouldn't rely only on that, but have some timer too.
> 
> We call permitUnload and expect a reasonably-timed reply, yeah... Note that
> I can't actually reproduce a long slowdown, presumably because my internet
> connection is fast enough that the XHR takes up no noticeable time -
> probably the same applies to the people who wrote the site. :-\
> 
> Note that a timer on its own doesn't actually work well because permitUnload
> might be throwing up a dialog, and we wouldn't want to auto-close that
> dialog and prevent the user from making a decision.
> 
> It'd probably help if we exposed what permitUnload was blocked on somehow,
> so the browser code could check...

Yeah net speed shouldn't be a factor in my case http://www.speedtest.net/result/3944321059.png 128bit cable but that doesn't rule out high latency.

Comment 9

[fireattack [:fireattack]]

A more extreme example: http://wenku.baidu.com/view/288952c1d5bbfd0a79567357 (It hangs me for good 1-2s)