Closed Bug 430573 Opened 12 years ago Closed 9 years ago
lolcats website makes firefox use 1GB+ of RAM due to iframe recursion
247.39 KB, image/png
308.15 KB, image/png
70.53 KB, image/png
304.62 KB, image/png
lolcats website makes firefox use 1GB+ of RAM, at least if you believe the Windows Task Manager "Mem Usage" column I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042305 Minefield/3.0pre I don't see this in IE 7. Could it be that there are recursive iframes? (See attached screen shot from DOMi) Let me attach a few screen shots. see also bug #420986
Product: Firefox → Core
QA Contact: general → general
Confirmed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042407 Minefield/3.0pre. Memory slowly grows. Continually hits google's adservicing among others.
DOMi says the iframe in the upper right has: src="http://partner.googleadservices.com/gampad/ads?correlator=1209062556307&output=html&impl=fb&client=ca-pub-0766144451700556&slotname=ICHC-Rectangle-TopRight&page_slots=ICHC-Rectangle-TopRight&cust_params=&cookie_enabled=1&ga_vid=2050448231.1207182584&ga_sid=1209062196&ga_hid=950231353&ga_fc=true&url=http%3A%2F%2Ficanhascheezburger.com%2F&ref=&lmt=1209062555&dt=1209062556498&cc=100&u_h=900&u_w=1440&u_ah=822&u_aw=1440&u_cd=24&u_tz=-420&u_his=6&u_java=false&u_nplug=7&u_nmime=79" And yet it ends up loading ICHCB there. Could be a problem on Google's end? FF2 just shows ads, might be worth checking an older FF3 build to see if it's just a useragent problem, or if we broke something. This is also happening in http://ihasahotdog.com/, ohnoes.
IE7 doesn't have this, as it shows adds as well. note, "I has a bucket" is working: http://icanhascheezburger.files.wordpress.com/2007/01/2001982351398543517_rs.jpg (Sorry, couldn't resist)
Confirmed using Windows Vista Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042407 Minefield/3.0pre
same problem on an older build, so it doesn't look like we recently regressed this Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040100 Minefield/3.0pre ID:2008040100
It's really interesting b/c if you go to the site and keep the error console open notice that it has multiple entries for MineWidget not being defined and then after a few seconds the errors all disappear, very strange!
This just brought my Mac to its knees by slurping down more than 2G of memory. Requesting blocking, since this is a pretty evil failure mode.
Some diffbloatdump output could be useful to determine what's taking up the memory: http://wiki.mozilla.org/Performance:Leak_Tools#Leak_tools_for_debugging_memory_growth_that_is_cleaned_up_on_shutdown
I really think we should block on at least figuring out what's going on here. If iframe recursion prevention has broken that will probably cause more sites to break in similar ways.
Assignee: nobody → jonas
Flags: blocking1.9? → blocking1.9+
Just to clarify, there are two issues going on here: One is that for some reason the page is generating recursive iframes instead of ads. These are all JS injected. That's why disabling JS or using Adblock prevents the problem. Don't know why this happens, but it could be a bug with the site's (or Google's) code. The other is that when such iframes are created -- whatever the reason -- we should be taking measures to prevent excessive resource consumption. It sounds like that's not happening for some reason.
So what seems to be happening here is epic fail on the part of lolcats. http://icanhascheezburger.com/ when loaded with my tip build (which doesn't support flash) will produce a page with 5 <iframe>s, all of them pointing to various urls within http://partner.googleadservices.com/. However each load for those urls will result in a redirect to http://icanhascheezburger.com/wp-content/themes/icanhascheezburger/google_adsense_script.html This is a 404 page that largely looks like http://icanhascheezburger.com/, i.e. it will contain (only 4 this time) <iframe>s pointing at http://partner.googleadservices.com/ So basically lolcats creates infinite <iframe> recursion. We do have 2 lines of defense to protect against this type of recursion. For one we generally refuse to nest more than 10 levels deep. However since each level here contains 4 iframes that still creates a whole lot of iframes (~4^9 > 1/4 million) Second, we refuse to load a url if there is a parent frame with the same url. However this doesn't work here since the initial url is always a http://partner.googleadservices.com/, so we don't detect the recursion. We don't check for recursion on redirect. There might be additional defenses going on here which I haven't found, since clearly we're not able to load .25 million lolcat pages. It's possible that we have a limit on the total number of frames per tab somewhere Why this happens only for FF3 I don't know. Possibly because I don't have flash installed on my tip builds. This doesn't happen for me with my default profile where flash is installed. Either we could simply evangelize here since clearly lolcats shouldn't be creating infinite frame recursion. Or we could detect recursion on redirect which would fix this too.
Actually, I do have flash installed on that build, so not sure why i'm getting iframes...
We don't do any recursion protection other than the 10-deep and no loading the same URI checks. I have no idea why this isn't loading 4^9 or so frames, except for the fact that I'd expect the loads to happen slower and slower (with the browser frozen more and more) as we keep GCing and such... Note bug 305524; fixing that might allow us to usefully check for redirects, I suspect.
It might be interesting to figure out exactly when this regressed. Might give us more of an idea as to why it suddenly broke...
What exactly regressed? I get recursive frames with a current branch build, SeaMonkey 1.0.1 and Mozilla 1.7.
Ah, somehow I'd gotten the impression that this is a trunk regression. If it's not, I'm going to stop worrying about it. ;)
Given comment 24 and comment 25 I'm taking this off the blocking list.
Flags: blocking1.9+ → blocking1.9-
Hai guize, This is Cheez from I Can Has Cheezburger. This file: http://icanhascheezburger.com/wp-content/themes/icanhascheezburger/google_adsense_script.html is supposed to collapse the ad space if no ad is shown by Google. I am going to update this so that it is just a flat HTML file with no script. I'd like to see what happens if I make this change. Thanks for letting us know about this problem.
Are we sure this is specific to the lolcats site? Did anyone get back with Cheez, about comment #27? The reason I ask is that other wordpress-based pages with comments have large memory usage and slow scrolling issues, as has been reported in Bug 433469.
No, the bug isn't specific to the lolcats site. We do need to fix how we implement frame recursion prevention.
(In reply to comment #29) > No, the bug isn't specific to the lolcats site. We do need to fix how we > implement frame recursion prevention. > What about bug 420986
(In reply to comment #30) > What about bug 420986 > Not related, that's a tech-evangelism bug about the change of the userAgent string + (maybe) about getElementById changes. This is about frame recursion, which anyhow shouldn't occur on this site anymore as per comment #27.
Summary: lolcats website makes firefox use 1GB+ of RAM → lolcats website makes firefox use 1GB+ of RAM due to iframe recursion
The testcase now uses less memory, so I think we can mark this as WORKSFORME. Adding to MemShrink.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.