893943 - Firefox hang with intellicast.com animation

Status: RESOLVED INCOMPLETE

(Firefox :: Untriaged, defect)

Description

[Jim Vance]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

After FF is launched, in the past several days one of the tabs I consistently open reflects an Intellicast animated radar loop on the following webpage (the specific drop-down selection is set to San Antonio, Texas): http://www.intellicast.com/National/Radar/Current.aspx?animate=true


Actual results:

After a few minutes with that radar animation running in the background, it becomes impossible to refresh any of the other tabs' pages or achieve a successful transition to any link when clicked -- Firefox just hangs up and becomes non-responsive, requiring closure AND either a system reboot OR manual termination of the still-continuing process within Task Manager before it can be re-launched.  This behavior never occurred prior to v22.  By a trial-and-error process, I discovered that the dysfunction seems to be associated with the simultaneous presence of that animated Intellicast webpage, though at first I ascribed the issue(s) to problems with my wireless internet service and/or home office network (a wired + wireless combination).


Expected results:

FF should continue to be responsive and not become dysfunctional.

Comment 1

[Jim Vance]

The Intellicast webpage may not be the causative feature of this bug -- on the last re-launch, I didn't open it as I wanted to get some things accomplished.  After I had taken care of many of those, I stepped away to get some coffee and remained away from this laptop for about 25 minutes, but returned to find several tabs whose pages have autorefresh scripting hanging and the non-responsive behavior had once again occurred.  So, I'm not sure what's triggering it, but this behavior definitely began with v22.

Comment 2

[Jim Vance]

Okay, I think this is some sort of memory-handling issue, as I have not launched the Intellicast webpage since my last comment but the incidence of non-responsiveness has occurred several more times -- usually after perhaps 20-30 minutes of browsing.  When I've been forced to terminate the process (usually by killing the process tree) in Task Manager, I've noticed that the column for "Memory (Private Working Set)" displays an extraordinarily large number in comparison with all of the other processes.  This is similar to a memory leakage issue which arose in the previous browser I used (Opera) and which was a pernicious detraction to its functionality for many -- it wasn't the only reason I stopped using Opera, but it was definitely a contributing factor.

While I have 8Gb of RAM installed in this Win7 Pro x64 laptop, it seems the ballooning memory load from Firefox may be forcing the OS performance to degrade significantly and perhaps producing the non-responsive behavior.  For anyone who is able to interpret them, I'm also uploading two DMP files from the past incidents when I've been forced to terminate Firefox manually.

Comment 3

[Jim Vance]

Thanks for responding, Aleksej -- I've tried to upload two separate DMP files which were created with the Task Manager debug action, but they're both too large and well above the threshold limit for the bugzilla reporting system to accept.  If there's an alternate method for submitting such large files, then perhaps you or someone on the team can send a private message to explain how to get them uploaded.

Since I originally submitted the bug report, I haven't experienced too many further instances where the nonresponsive behavior has developed, though I have occasionally launched that Intellicast webpage to check the weather as there have continued to be some rainstorms in this region over the past few days but I haven't kept it working in the background for long each time.

Comment 4

[Jim Vance]

It's happened again -- this time when I brought up Task Manager to examine and ultimately kill the process tree, the memory load was >650K, and rose to >900K as the debug file was being saved.  As with the first two, they are too large (even compressed) for the bugzilla system to accept.

Comment 5

[Jim Vance]

What IS the deal with FF and its memory-handling (or -hogging) activity?  I use a nifty little app named CleamMem to monitor the load on my RAM and have Task Manager's process tab set up to display the associated memory loads.  With FF v22.0, the memory load builds to several hundred MB and can approach 1GB -- if I use CleanMem to force the active processes to release unneeded holds on RAM the level which is displayed for FF will quickly drop to around 50KB, but then just as quickly ratchet back up to several hundred MB again.  When the use of RAM becomes extremely high, FF becomes less and less responsive despite a high-quality broadband connection.  The memory-hogging aspect of this browser version really, really needs to be improved!

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

Hi Jim, perhaps you can upload your files somewhere and give us the link.  I'm sorry you've had this memory issue. We definitely need more information to be able to investigate the bug, though. 

I have tried to replicate this bug and have not been able to with Firefox 24 or with the Nightly release.  

Are you still experiencing this problem with Firefox 24?

Comment 7

[Jim Vance]

Regrettably, I no longer appear to have them archived in the default folder where Task Manager saves them, and while I didn't intend to erase them those large .DMP files may inadvertently have been purged in my unthinking quarterly-or-so run of CCleaner as I took that step for all of my computers after the latest Patch Tuesday a few weeks back  I suspect DMP files are included into the default list with TMP files when the generic "temporary file" toggle option is incorporated, and so were eliminated in that process -- sorry.

To answer your last question more directly, I'm not having problems, but am running v23.0.1 (can't find a v24 official release as you recommended yet, but if you can point toward the pre-release version I'll consider it), and the really atrocious behavior seems to have been largely or perhaps completely remediated with either one or both of the following actions during the meantime:

1. upgrading Firefox to first v23.0 and then v23.0.1;
2. discovering that Ghostery was experiencing memory leakage issues in v5.0.1 (which was exactly my version), that were fixed with the release of v5.0.2 beta+final and v5.0.3.

Memory loading currently shown in Task Manager as I type this with 17 tabs open is up around 350Mb, and that's much less than I was seeing during those episodes which triggered the bug report.  My suggestion at this point is to close the report.

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

Thanks Jim!