Closed
Bug 1126689
Opened 9 years ago
Closed 8 years ago
long polling causes firefox to become unresponsive
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: jamie, Unassigned)
References
Details
(Keywords: perf, testcase-wanted)
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
Comment 1•9 years ago
|
||
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.
Comment 2•9 years ago
|
||
Jamie, could you post a URL to a publicly accessible testcase?
Comment 3•9 years ago
|
||
(In reply to Steven Michaud from comment #2) > Jamie, could you post a URL to a publicly accessible testcase?
Flags: needinfo?(jamie)
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.
Flags: needinfo?(jamie)
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.
Comment 6•9 years ago
|
||
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.
Flags: needinfo?(jamie)
Comment 7•9 years ago
|
||
> 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.
Comment 8•9 years ago
|
||
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.
Comment 9•9 years ago
|
||
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.)
Comment 10•9 years ago
|
||
(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.
Comment 11•8 years ago
|
||
Unfortunately we need testcase to make progress. So the bug is currently incomplete
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Flags: needinfo?(jamie)
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•