User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20150108202552 Steps to reproduce: I ran an application that uses long polling technology to display updates to a moving chart. Actual results: the firefox browser slows to a crawl. it affects web pages in other tabs too. Expected results: the firefox browser should not become unresponsive. other browsers such as Chrome and Internet explorer behave normally.
Summary: long polling → long polling causes firefox to become unresponsive
Is "long polling" using sync XHR? In that case, the nested event loop that this causes might make this problem an instance of bug 1102302.
Component: Untriaged → Widget: Cocoa
Depends on: 1102302
Product: Firefox → Core
Jamie, could you post a URL to a publicly accessible testcase?
(In reply to Steven Michaud from comment #2) > Jamie, could you post a URL to a publicly accessible testcase?
Keywords: perf, testcase-wanted
Sorry, I don't have a publicly accessible URL that demo's the behavior, but I am happy to show you using Teamviewer. Just let me know. Chrome has no problem dealing with long polling operations, but Firefox slows down to a crawl after a while.
We are using Tomcat 7/8 with Comet Xhr. On the client side, we are using Google Closure https://developers.google.com/closure/library/docs/xhrio. If I leave the Firefox tab open, the entire browser (all tabs) slows to a crawl. It gets progressively worse over time. Only when I close the browser tab, does Firfox begin to work normally again. There is no such issue with Chrome.
I doubt anyone at Mozilla has the time to learn how to set up a testcase using your information. I certainly don't. Can I suggest the following? Please set up a public testcase on one of your own servers. If it makes you feel better you can require a login -- but if you do you'll need to paste the account and login into a comment here.
> I am happy to show you using Teamviewer This isn't a viable option. We need something we can play with (experiment with). Only a public testcase will do.
I stand by my assessment of comment 1 - I think fixing bug 1102302 and then asking Jamie whether a build with the fix still reproduces this bug would be better use of time than trying to reproduce this specific instance.
You may be right, Markus, but you're just guessing. Jamie, if it isn't too much trouble please do what I request in comment #6. (Bug 1102302 is one of the bugs on my list to work with Stephen Pohl on, as part of my effort to train him in the use of my debugging tools and techniques, before I retire sometime later this year. But it may be a few weeks before we get to it.)
(In reply to Steven Michaud from comment #6) > Please set up a public testcase on one of your own servers. If it makes you > feel better you can require a login -- but if you do you'll need to paste > the account and login into a comment here. And Jamie can make that info semi private by marking the bug comment as Private.
Unfortunately we need testcase to make progress. So the bug is currently incomplete
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.