Open Bug 823030 Opened 8 years ago Updated 5 years ago

sync xhr with slow cors server from tab close stalls tab switching for a long time


(Firefox :: Tabbed Browser, defect)

18 Branch
Not set



Tracking Status
firefox18 - ---
firefox19 - ---
firefox20 - ---


(Reporter: mcmanus, Unassigned)


(Depends on 1 open bug, )


(Keywords: hang, regression)

+++ This bug was initially created as a clone of Bug #819044 +++
The essence of this bug is that a sync xhr is generated on closing the open tab.. in this case it generates a CORS preflight to twitter because the tab is from google and the xhr is to google. When the bug was filed the CORS transaction hung (no response headers were generated by the server) due to a server side bug on twitter which has since been fixed server side - so the URL below won't reproduce anymore.

While the cors transaction was hanging tab switching just stopped working - it wasn't the usual jank, some highlighting of the new tab happened for instance and the title bar changed, but no paints were happening in the newly selected tab. When that transaction timed out the normal http channel events occured and tab behavior returned to normal.

[from the original bug below]

Using Firefox nightly (is that "20 branch" or "trunk"?), I opened the Google cache version of a Twitter page, e.g.

in a new tab. I then closed that tab.

Actual results:

Firefox became really sluggish for a while. Switching between two tabs, which was pretty much instantaneous before I closed the tab, now takes a noticeable amount of time. Sometimes several seconds. Oddly enough, I couldn't see that Firefox was using any undue amounts of CPU or memory at the time.

Eventually things settled down and went back to normal. At least most of the time. There was at least once where I waited a couple of minutes and it was still sluggish.

I have observed this with Firefox Nightly on my Debian Linux box, but also with Firefox Beta (18) under Windows 7.

I've tried restarting Firefox with add-ons enabled, but that didn't make any difference. With Windows Firefox 18, I even tried resetting my profile, to no avail.

Expected results:

I can understand if Firefox momentarily gets a bit bogged down when a tab is closed, but not like this. I would have assumed Firefox would go back to its old snappy self in seconds at most, not minutes.
Blocks: 798423
No longer blocks: 798243
Component: DOM: Core & HTML → Tabbed Browser
Product: Core → Firefox
As far as I see _beginRemoveTab doesn't expect that content might spin event loop.

It is not clear to me what behavior we want here.
bah, wrong bug.
Depends on: 952169
You need to log in before you can comment on or make changes to this bug.