Closed Bug 635121 Opened 13 years ago Closed 8 years ago

Suspected memory leak involving Facebook JS in app tab - FB chat

Categories

(Web Compatibility :: Site Reports, defect)

Product:
Web Compatibility
Component:
Site Reports
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(blocking2.0 -)

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: mozilla, Assigned: browser-bugs)

References

(
URL
)

Details

(Keywords: memory-leak, perf, Whiteboard: [explanation in comment 42][MemShrink:P3] [country-all] [js] [notcontactready]) 

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110217 Firefox/4.0b12pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110216 Firefox/4.0b12pre

I've been encountering a pesky memory leak problem in 4.0 betas, all the way to yesterday's nightly (haven't had a chance to reproduce with today's yet), but also including 4.0b11, b10, and earlier. 

Essentially, memory usage just grows and grows and grows and grows and grows. If Firefox/Minefield is left undisturbed for long enough (6-10 hours, maybe) on a 32-bit system, it crashes silently, with no crash reporter (see bug 633848, which I filed about that problem and where I have attached a WinDbg log). On an x64 system, given Minefield is using /largeaddressaware, I seem to always kill and restart Minefield (which, by that point, is slow and moody) before it has a chance to run out of memory.

I've seen this problem across three systems. The three systems (2 32-bit, 1 x64, all Win7) share a common set of extensions, and a common set of app tabs (Facebook with Facebook Chat running and the new Messages, LinkedIn, Google Reader, Gmail). While experimenting today, I noticed that if I go to www.google.com in the Facebook app tab, the memory usage stops increasing. Hence my suspicion that some scripting issue with Facebook is causing this problem... 

I intend to set up a clean profile on a fourth machine, running the latest Minefield, and leave it sitting there with a Facebook page open as an app tab and nothing else for 12-24 hours to see if I can reproduce the leak. But in the meantime, I thought I'd file a bug and see what information you guys would like me to gather.

Reproducible: Sometimes
Okay, on my fourth machine (x64, W7 SP1) with the brand new clean profile, newest nightly build, memory usage according to task manager was ~70M when I logged into Facebook and left it sitting there (I even forgot to make it an app tab). 

An hour later, I come back (but haven't touched the Minefield window), it's at 126-128M. And now it just went up to 134M - 6M increase suddenly while I was watching it.

I'll check in on it again in an hour or two.
No longer blocks: mlk2.0
Blocks: mlk2.0
A few questions:

1) How do other browsers behave if you open that same page in them?
2) Once you leave the page, does memory just stop increasing, or get reclaimed
   after 5-6 minutes?
3) If it doesn't get reclaimed after leaving the page, does it get reclaimed
   after closing the tab/window and waiting 5-6 minutes?
Okay, my clean profile experimental setup was at 150M when I turned the monitor back on. Then suddenly it swelled to 256-258M maybe 30 seconds later. CPU usage is now at 16-20%, memory usage going up a little teeny bit more... 278M, 280M, 283M, 287M, etc. Now 299M. 302M. 303M. 319M. 324M. It seems to be growing by a meg/second, then going down a little bit, then going back up, etc. 327M. 333M.

(I can try to answer your questions 2 and 3, or should I leave it sitting there? Sadly, no WinDbg on that box... but I do have procexp, could make a minidump? Or even try to install WinDbg hurriedly)
Re: question 1, I just opened it in Chrome (on one of my 3 main machines, NOT on the one running the clean profile experiment). Will watch it. 

I'm not going to try anything re: 2/3 right now. Watching memory usage swell instead. Since my last comment, it's now around 390M, and just had a brief peak at 417M.
Memory usage is now at 505M or so, CPU usage going between 11 and 50%. Just saw a quick memory spike to 560M, then back down to about 512M.
Meanwhile, on my netbook, where I opened a Facebook tab about 30 minutes ago, I'm also starting to see some weird things with memory. I'll let it sit for an hour or two, and then try to answer questions 2 and 3. 

(The clean profile setup, meanwhile, is now at 570M, with a peak to 620M, then went down to about 560M, now climbing again.)
Adding blocking2.0? 'cos I hear this Facebook thing is popular.
blocking2.0: --- → ?
What exactly are the steps to reproduce?
As far as I can tell:
1. Open Minefield. 
2. Go to www.facebook.com. 
3. Log in. (Note: my account has Facebook Chat and the new Facebook Messages, which no doubt means they're serving me different JS compared to accounts without those features.)
4. Open Task Manager.
5. Leave the Task Manager window active. 
6. Go away for an hour or two.
7. Come back. Do not touch/focus/whatever the Minefield window.
8. Look at the Task Manager window. 
9. Panic and file a bug. :)

(Having done exactly this in my clean profile setup, it went from 70M when I did step 4. shortly after filing the bug and shortly before posting comment 1, to 660M of memory and 11-50% CPU usage.)

So, basically, if you leave Facebook open and just go away, it seems that within 8-10 hours, Minefield will crash in the manner described by bug 633848 on a 32-bit system, and probably do the same thing in 20 hours on an x64 system. On a non-clean profile setup where there are other tabs using memory, those times should be reduced. 

I have no idea how 3.6.13 handles it, but I certainly had no Facebook problems until I switched to 4.0 everywhere around the release of b6/b7. 

Memory usage is up to 720M, btw. So a further 50M gobbled up while I wrote the above paragraph.
How do I enable that new Facebook Messages thing?
(In reply to comment #4)
> Re: question 1, I just opened it in Chrome (on one of my 3 main machines, NOT
> on the one running the clean profile experiment). Will watch it. 

Watching the Chrome setup now in Chrome's task manager. Memory usage seems to be growing a bit too... about 500K/sec

I'm going to have to stop the Chrome test, unfortunately - Chrome's task manager is saying that this thing is using 15-20 kB/s (another FB bug?), which in this world of Canadian bandwidth caps, I can't readily afford.
(In reply to comment #10)
> How do I enable that new Facebook Messages thing?

You have to be invited. Existing users can 'nominate' friends for invites, but I don't think it's instantaneous...
(In reply to comment #2)
> 2) Once you leave the page, does memory just stop increasing, or get reclaimed
>    after 5-6 minutes?


Okay, I left the page on my netbook (where there was maybe an increase of 70M in memory usage). Memory usage dropped back down to where it was before going to Facebook within a minute or two of going to www.google.ca in that tab.
That last part (and the Chrome results) is really sounding like Facebook is may be creating a bunch of objects and then holding on to them....  Though if 3.6 doesn't show the growth that might not be the case.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm shutting down my clean profile setup right now - given it also seems to be guzzling 80 megs/hour in bandwidth (!?!?), and I don't think it's telling us anything new anymore. Memory usage up to 824M, btw. Stopped growing when it reached 824.

Okay, let's go to google.ca. Brief spike in memory to 924M. CPU at 50%, then in the high 30s. (Note, this is a dual core box, so 50% means 100% on one core). Now CPU usage is down to zero, memory usage is down to 277M and doesn't seem to drop further.
Okay, I opened a new blank tab, and closed the "Google" tab (formerly Facebook). Memory usage dropped further to 143M and seems to be steady there.

You want me to have some fun with 3.6?
If your bandwidth cap will let you, yeah...
New 'clean' (for some reason some Adobe extensions seem to have shown up) profile, 3.6.11 (sorry, trying to save 8 megs of bandwidth, and that's the newest 3.6 installer I had around - I doubt 3.6.12/3.6.13 would make a difference). I'm NOT going to let something that might be guzzling 80 megs/hour sit overnight, but I'll leave it open for a little while, try and see what it's doing. It was sitting steady at 67M, just went down to 65M... 

The mysterious thing is this - this bug or something very close to it has been driving me crazy for about 2-3 months (sorry, I'm new here! this issue is the entire reason I signed up for a bugzilla account). Assuming there's some brokenness on Facebook's side (which, I agree with you, the Chrome results suggest, not to mention the obscene bandwidth usage), did that brokenness just happen to be introduced at the same time as I switched to 4.0? Or is there something in 4.0b7+ that means that Facebook's brokenness breaks it far more than it breaks 3.6?
So far, after 20 minutes, all is quiet on the 3.6.11 front. I followed the procedure in comment 9 exactly. Memory usage is steady at 65-67M, and bandwidth usage (for the entire system, which is running... nothing but 3.6.11) has been 100 kilobytes in 12 minutes. (Big change from 80 megabytes/hour, eh?)
After a further 20 minutes, all is still quiet with 3.6.11. Memory usage is up to 68-69M, so I'm guessing it's going up by roughly... 1M every 10 minutes? CPU usage is at 0%, occasionally goes up to 2%, then back down a second later. 

Since things were _relatively_ quiet (where quiet means... a doubling in memory usage) the first hour of the Minefield test and this thing doesn't appear to be consuming much bandwidth (I can spare 3-4 megs/hour...), I'll continue observing for a few hours.
On the 3.6.11 setup, memory usage is oscillating around 70-71M. CPU usage nice and low, bandwidth usage is reasonable. IOW, no change since comment 20.
I'm shutting down the 3.6.11 test for the night; may try it again later, just in case tonight was a fluke.

Meanwhile, on the 2 systems running completely 'Facebookless' (i.e. where no Facebook was touched since Minefield was last restarted), performance is good, no memory leaks that I can see, etc. Suddenly this actually feels like software that's a week or two away from an RC :)
The cc logs seem to keep growing. Wonder what's going on.
Whiteboard: [decide on 2/21]
I have Facebook tabs open all the time on 32-bit Windows both at home and at work, and those browsers stay open for 1-many days at a time. I never get crashes from that. I do see fairly high memory usage. Right now, I have about 17 tabs open, including FB in an app tab, and WSS is about 650MB. I guess I should try closing FB and then restarting this profile, and see what I get from that.
I've had FB open in Minefield and Chrome for about 1.5 hours now. Memory usage in MB:

                    WSS        Private

  Minefield         178            128
  Chrome            116             66

So I'm not seeing anything like what's in this bug report. I wonder if it has something to do with an extension?
(mozilla@vivienm.org: thanks for the fantastic report and help here!)
(In reply to comment #24)
> So I'm not seeing anything like what's in this bug report. I wonder if it has
> something to do with an extension?

I tested it on a new profile, so I doubt it? Though certain Adobe extensions seem to show up on my so-called 'clean' profile in 3.6.11, so maybe... 

Are you on the new Facebook Messages? Do you have Facebook Chat enabled? (I personally suspect the chat feature has something to do with this, but that guess is based on nothing) Since the new messages integrates with chat, I wonder if the JS they use for chat on accounts with the new messages is completely different. 

It could be a problem with my particular Facebook account, I suppose. Not sure how to test it - yes, I could sign up for another account, but that account won't get the new messages for several weeks at least.

I'm starting another 3.6.11 test now, let's see if I reproduce the quiet nothingness from yesterday.
(In reply to comment #26)
> (In reply to comment #24)
> Are you on the new Facebook Messages? Do you have Facebook Chat enabled? 

I have Chat enabled. I don't think I'm on the new Facebook Messages.
(In reply to comment #26)
> I'm starting another 3.6.11 test now, let's see if I reproduce the quiet
> nothingness from yesterday.

Crazy wind storm here, and the UPS on the test system I am using for all my clean profile tests (including 3.6.11) proved inadequate when the power went out, so that's the end of tonight's attempted long 3.6.11 test. :(

I'll try again tomorrow (no point in tempting fate while the wind storm continues).
Figured I would test IE8. After maybe 5 minutes, memory usage is up to 287M and growing by a meg or two per second. While I wrote the rest of this comment it swelled further to 422M. (These are private working set numbers from task manager. Same testing procedure I used for the other browsers.)

So, to summarize, based on current test results: my Facebook account with new messages/chat is causing serious memory leaks in Firefox 4, Chrome 9, and IE8, but NOT in 3.6.11.

I'm going to do another quick 3.6.11 check in a few minutes; based on my IE results, it didn't take long at all (a few seconds?) for it to start guzzling memory. 

Does anybody have a developer contact at Facebook who could be pointed to this bug?
Update on my short 3.6.11 test; CPU usage low, memory usage increasing very, very, very slowly compared to what the other browsers are doing. I'm going to shut this down for the night, will try a longer test tomorrow, but so far this matches yesterday's results. 

I'm tempted to have 3.6.11 spoof its useragent and pretend it's 4.0, Chrome, or IE8.
(In reply to comment #30)
> Update on my short 3.6.11 test; CPU usage low, memory usage increasing very,
> very, very slowly compared to what the other browsers are doing. I'm going to
> shut this down for the night, will try a longer test tomorrow, but so far this
> matches yesterday's results. 
> 
> I'm tempted to have 3.6.11 spoof its useragent and pretend it's 4.0, Chrome, or
> IE8.

If FB is user-agent sniffing, that might smoke out whatever new API could be involved in the script-level bloat bug. Check the error console.

But if FB is object-detecting and falling back on older APIs and thus avoiding its own bloat bug somehow, then you won't see any errors.

/be
What page are you sitting on? I am not able to reproduce on the newsfeed in Chrome 11 (wtb about:compartments for Minefield).
http://www.facebook.com/home.php , usually after clicking the 'Most Recent' (but sometimes not). 

When I did my Chrome testing, I also clicked on a random person's name and left it sitting on his/her profile. The behaviour observed in the Chrome task manager continued just like it did on the news feed, hence my suspicion (perhaps completely wrong) it has something to do with the chat feature that's on all pages. 

3.6.11 with the spoofed 4.0 UA is quiet so far, though sometimes it's taken hours to reproduce the problem with real 4.0. I'm going to do another test with Chrome 9 now.
Okay, the spoofed 3.6.11 and Chrome started leaking badly. All was quiet, both sitting on the home page. 

Then I opened IE (on the same machine as Chrome), also went to www.facebook.com. All of a sudden, CPU/memory usage/network usage goes off the charts _everywhere_... including the 3.6.11 that was pretending to be 4.0.

I shut all three down. Restart 3.6.11, now no longer spoofing its UA. Quiet. Open Chrome, go to www.facebook.com. Chrome goes wild. 3.6.11 stays quiet. While Chrome is wild, open IE. IE going wild too. Non-spoofed 3.6.11 stays quiet.

If anyone is testing this, can you open multiple different browsers and point all of them to Facebook (just sitting on the news feed), see what happens?
Let's recap, given the additional information.

Normal situation, prior to discovering this bug:
- 3 different machines, all running 4.0b11 or Minefield, each running Facebook

Situation early last night:
- the 3 usual machines don't have Facebook open
- Facebook is opened on clean profile Minefield, memory usage slowly increases over an hour or two.

Situation after bz posts comment #2: 
- clean profile Minefield remains sitting on Facebook
- Facebook is opened on one of the 3 usual machines (netbook running 32-bit OS), in order to gather information for bz.
- clean profile Minefield goes wild. Netbook wasn't monitored as closely, but showing signs of memory issues.

Situation after I decide to test with Chrome:
- clean profile Minefield still going wild
- netbook gets shut down at some point
- Chrome is opened, goes wild, is promptly shut down

Here is what I'm now thinking. There are two problems:
1) slow memory leak in Minefield, when it's the only client (as observed in the first two hours of my initial experiment, and a memory leak which, given 8-10 hours, may... or may not... be enough to cause the original problem I was having).
2) fast memory/CPU leak in all browsers except honestly-identifying 3.6, when multiple (2-3?) clients are running. This seems to be a FB problem.

Next experiment: running multiple 3.6es.
(In reply to comment #34)
> If anyone is testing this, can you open multiple different browsers and point
> all of them to Facebook (just sitting on the news feed), see what happens?

I have my newsfeed open in Chrome, Minefield and IE8 and all of them appear to have stable usage (periodic increases, but appears to be in a steady state).

I also have a Chrome tab sitting on a friend's profile and it appears stable as well.

Have you tried on another Facebook account? It could be there's some feature enabled on yours and not on mine.
Two 3.6 clients. The usual 3.6.11, and a dirty profile 3.6.13. Opening Facebook on the 3.6.13 caused both of them to exhibit the usual symptoms (spikes in CPU usage, memory usage increasing).

Borrowing a shiny new experimental Facebook account from someone for our next test. That account has like, no friends, no new Facebook Messages, etc.
Shiny new experimental account in the usual clean profile Minefield (updated to the next day's build). I'm his only friend. Facebook chat running. Memory usage started increasing very mildly, after opening a second browser. A third browser caused Minefield's memory usage to jump 15M.

Basically, I think something about my normal account (the new Messages is my guess) causes something to go very very very bad if there are multiple sessions, but there is some minor weird behaviour with multiple sessions even on other accounts. I'm happy to send a support request to Facebook over normal channels, but I suspect that's unlikely to reach the right people? So, problem #2 (as described in comment 35) is probably a TE issue.

That leaves problem #1. I'm going to go back to my normal account, leave it sitting for a while in the clean profile Minefield. Make sure I don't open any other sessions. If there's a substantial memory leak (I did see something like 50-70M increase in memory usage over an hour at the beginning of yesterday's series of experiment), then that's probably a bug here, since other browsers don't seem to show that kind of memory behaviour in a single-session test. And no more trying to reproduce anything with two sessions at once :)
Based on recent comments, I'm going to remove the blocking nomination. Please renominate if we feel that this is a problem that we can (a) solve, and (b) should block on before releasing.

Also: we know some people at fb.com if that helps!
blocking2.0: ? → -
Whiteboard: [decide on 2/21]
I've been running the clean profile Minefield (sitting on Facebook home page, with no interaction from me) since I wrote comment 38, and I'm still seeing some interesting memory behaviour (100M private working set 14 hours ago; I turn on the monitor 10 minutes ago, I was seeing 250M, then it dropped to 140M, then back up to 191M, then 224M, then 244M, then 263M, down to 162M, then heading back up, peaked at 267M, then down to 151M, etc.). But that behaviour doesn't suggest that it's headed for a big huge crash in a few hours... 

I'm going to shut this down shortly, and open one Facebook tab in one (and only one!) of my normal Minefields (with all my usual tabs, extensions, etc). If the CPU usage/memory leaks/etc don't start up again, then I think the conclusion will be obvious.

I have to say, I am absolutely stunned at this outcome. I spend 2-3 months thinking there's something broken in Firefox 4, yet it now seems like Firefox 4's main contribution to this mess is the app tab feature, which encourages keeping a Facebook tab open all the time on all systems, apparently triggering some nasty multiple-session bug on their side that may be more or less specific to my account. No Facebook, and Minefield seems to run as well as 3.6, if not better :)

One person from fb.com has contacted me yesterday; hopefully that will lead to the right people over there figuring out what's going on. Anyone else from fb.com who sees this (or can be pointed to this), please feel free to contact me, and I'm happy to provide whatever information and do whatever testing is needed to fix this.
mozilla@vivienm.org, I give you a gold star for fantastic bug reporting and data gathering.  Thank you!
Component: General → English US
Product: Core → Tech Evangelism
Okay, after playing around with a packet sniffer and some about:config tweaks, I think I found the underlying cause. Open enough sessions, and their server starts instructing browsers to reload the chat client's data... repeatedly. And the browsers dutifully obey, creating a predictably disastrous snowball effect that probably only ends with the crash of at least one browser (I think, but haven't really tested, that if you shut down enough sessions, the reloading will eventually stop in the remaining sessions).

I've passed on the full details to the person from fb.com who has contacted me. I'm happy to explain it to anyone else, but since it is absolutely clear now that this is not a Mozilla problem, I don't see a need to post the whole detailed story here, and I moved this bug over to TE.
Presumably this affects more than just Windows 7 on x86 hardware, then?
Whiteboard: [explanation in comment 42]
In the course of testing over the last couple of days, I've reproduced this problem on Windows 7 x86/x64, along with Ubuntu x64, running Firefox 3.6, Opera, IE8, Chrome 9, whatever Chromium build my Ubuntu setup has, and Firefox 4.0b11/nightly. In other words, reproduced on every desktop OS/browser I have lying around (sorry, no Macs in the household). Sometimes it took two Facebook sessions, sometimes it took three, sometimes it took four to trigger the bug, but the browser/OS doesn't seem to matter...

But I don't think it has been reproduced (so far?) on any Facebook account other than mine... at least, not by anyone I've been in contact with. So, am I doing something unusual that triggers a (rather serious) bug in their chat system's server? Only they would know...
I mostly wanted to make sure this wasn't one of the extremely rare TE bugs that is actually platform-specific. It sounds like it isn't. Thanks :)
OS: Windows 7 → All
Hardware: x86 → All
Assignee: nobody → tellrob
Keywords: mlk
No longer blocks: mlk2.0
No longer blocks: mlk-fx5+
Whiteboard: [explanation in comment 42] → [explanation in comment 42][MemShrink:P3]
Shawn's advice is to re-assign to browser-bugs.
Assignee: tellrob → browser-bugs
Has this gone anywhere with FB?
Keywords: perf
(In reply to Wayne Mery (:wsmwk) from comment #48)
> Has this gone anywhere with FB?
Flags: needinfo?(browser-bugs)
Hi everyone,

I'm Lubuntu Communications and Support Team Leader. Lubuntu is the official lightweight variant of Ubuntu which is a Linux Distribution - this is my profile: https://wiki.ubuntu.com/amjjawad

I'm sorry if this is an old bug/thread but I'd like to share this with all of you, I do hope it is somehow valuable or useful. If not, please forgive me:

http://amjjawad.blogspot.com/2013/05/facebook-on-lubuntu-1210.html

I'm having hard time but I do know even before I check this bug that it has nothing to do with what browser I'm using nor which OS I'm using, this is something with Facebook which I used to call "Failbook" and I guess I have a point to call it that way.

The link on my blog will explain a lot in deep details.
Should you have any question/comment/suggestion/idea, please let me know :)

Sorry again if I'm posting on the wrong place!
I really think this is not a Mozilla/Chrome/IE bug, the facebook site is written poorly and can easily push memory use high, i have resorted to running facebook in IE now because of how much memory it uses when left open and even IE shows the same thing.
Component: English US → Desktop
(In reply to Danial Horton from comment #51)
> I really think this is not a Mozilla/Chrome/IE bug, the facebook site is
> written poorly and can easily push memory use high, i have resorted to
> running facebook in IE now because of how much memory it uses when left open
> and even IE shows the same thing.

I on the other hand completely agree with you. I can immediately tell a difference with this new update to 33.0.2, before then I was running almost 520K+ just with 3 tabs open and youtube playing, dont let me have Facebook I'd be at 900k+ immediately. Right now I have 8 tabs with Youtube and Im at 229K which to me seems about reasonable. When I launch Facebook, I immediately go to 600k+. SOMETHING IS WRONG!!!, but I don't think it's Firefox's issue, it may be on Facebook side requesting something from the memory which is making it spike.
The steps are given in Comment #9
But this bug needs a more detailed analysis of the source of the issue before being able to contact Facebook.
URL: https://www.facebook.com/
Whiteboard: [explanation in comment 42][MemShrink:P3] → [explanation in comment 42][MemShrink:P3] [country-all] [js] [notcontactready]
Summary: Suspected memory leak involving Facebook JS in app tab → Suspected memory leak involving Facebook JS in app tab - FB chat
mozilla@vivienm.org: thanks for the report here indeed :) Since you had some communication with Facebook and was the one originally seeing the problem - do you know if they fixed it? :)
Flags: needinfo?(mozilla)
I would assume so - really, in the last 5 years, they've probably rewritten their entire chat system a couple of times. 

Honestly, this bug is 5 years old, it turned out it was never a bug in a Mozilla product, I think it can be safely closed.
Flags: needinfo?(mozilla)
(In reply to mozilla from comment #55)
> I would assume so - really, in the last 5 years, they've probably rewritten
> their entire chat system a couple of times. 

I haven't followed it over the same period, but I wouldn't assume it is fixed.  And FWIW the memory usage sucks on my wife's computer, or something else in FB does.

> Honestly, this bug is 5 years old, it turned out it was never a bug in a
> Mozilla product, I think it can be safely closed.

Evangelism bugs (of which this is one) are not about bugs in the mozilla product :)

So the questions remain - what do we see and know about this issue today, and what does FB have to say about it?  The bug is assigned to FB in 2011, yet I don't see that anyone from FB has ever replied nor that anyone ever had direct contact with them.

HELLO FACEBOOK?
I disagree. This bug was about a specific condition which caused a specific, observable memory behaviour pattern. I've just tested this with two instances of Firefox desktop logged in to the same Facebook account, and neither had any runaway memory usage..
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
(In reply to Hallvord R. M. Steen [:hallvors] from comment #57)
> I disagree. This bug was about a specific condition which caused a specific,
> observable memory behaviour pattern. I've just tested this with two
> instances of Firefox desktop logged in to the same Facebook account, and
> neither had any runaway memory usage..

I think two instances may be too few to reproduce the problem, but fundamentally I agree.

To recap (and sorry for the vagueness, this was 5 years ago, my recollection isn't perfect): back in the Firefox 4.0 beta cycle, I was excited about app tabs and had a Facebook app tab on various machines (3-5, I would guess?) at the same time. This triggered a bug whereby the Facebook messenger code would tell the browser to reload ... something. Unless the number of sessions was reduced and fast, that reload cycle would just continue, Firefox's memory usage swelled like mad and it crashed. I eventually ended up observing the traffic between Firefox and Facebook's servers in a packet sniffer, and it became clear that JS containing that reload code was being sent to Firefox. I further reproduced the problem using non-Firefox browsers. So really, it was never a Firefox bug but for the fact that the app tab functionality caused me to do something I was not doing before.

Very, very specific condition: too many simultaneous clients triggered Facebook sending code that caused effectively an infinite reload loop, which eventually swelled up the memory usage and brought down Firefox.
Flags: needinfo?(browser-bugs)
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.