[Note: I'm a tab-hoarder - but that doesn't really cause this problem] tl;dr: we should look at something (roughly) like the existing "page is making your browser slow" dialog for website leaks.
Over the last several months (and maybe the last year), I've noticed an increasing problem in websites: runaway leaks, leading to a poorly-performing browser or OOM crashes. Yes, these have *always* occurred (people write bad code, shock!), but the incidence seems to have gotten much worse 'recently' (anecdotally). This may be the result of ads/ad networks (in some cases it provably is), in other cases it's the sites themselves (like the 4M copies of ":DIV" that facebook was creating over a day if you left a message visible, plus GB of related leaks (80K copies of many strings/objects). Many of the pages causing these leaks are major sites, like nytimes.com, washington post, cnn, arstechnica, Atlantic, New Yorker, etc. However, regardless of who's making the error or the details, I've been noticing that I'm having to "hunt for the bad tab" more and more frequently (usually via about:memory, which users wouldn't do/understand). Multi-e10s helps a bit and some tabs won't degrade, but also enables my system to get into phyical-memory-pressure faster. (The machine I notice this on is Win10, 12GB ram, quad-core AMD 8xxx (older, but 3.5GHz). I'm running Nightly (32-bit) with one profile (for facebook), and beta (64bit) with another profile). While physical-memory pressure causes problems (including for the system as a whole), the leaking can make Content processes unresponsive, to the point where about:memory doesn't get data for them (or it's incomplete). This makes it hard-to-impossible to fix the problem; I kill Content processes by hand in that case - regular users would just force-close the browser (and perhaps start Chrome instead of restarting.....) We see an insanely high number of OOMs in the field; likely this is a major contributing factor. Chrome will *tend* to have less tabs impacted by one leaking, though the leaking tab will still be ugly. Sometimes the leak manifests simply as a leak (like the washington post tab I just killed and got 3.5 of the 5GB in use by a content process back). Others (depending I assume on what is leaked and how it's kept alive) cause a core (each) to be chewed doing continual GC/CC (or processing events in app JS touching some insanely-long internal structure), slowing the process (and system) to a crawl. *Generally* these are caused by leaving a page up for a while - navigate and leave, and you never notice it (part of why website developers don't fix these, or perhaps don't care (much)). But even walking away from a machine with one or a couple of tabs, and coming back the next day can present you with an unusable tab/browser, or a "this tab has crashed" screen. Hoping site owners (or worse, ad producers) will fix their leaks is a losing game, though we should encourage it and offer tools where possible. However, we need a broader solution (or at least tools) for dealing with this for users. I don't have a magic-bullet solution, and I'm sure there isn't one given JS and GC as a core of browsers. I do think we need to talk about it (and perhaps not just Mozilla), and find some way to help users here. One half-baked idea is to provide a UI intervention similar to what we do on JS that runs too-long, and ask the user if they want to freeze the tab (or better yet in this case, reload it). If we trigger before the side-effects get out of hand, freezing may be ok. We should also identify the tab (in the message/popup, and visually in the tab bar - we don't do either today). This solution has issues (though freezing tabs now that "slow down your browser" does too, but it's still useful overall). We can also look at tools to characterize site leaks or identify patterns that point to a leak before it gets out of hand. Also tools that help website builders identify if their pages are leaking in the field (memory-use triggers? within-tab about:memory dumps available to the page?) Perhaps we can also push to limit memory use (CPU use??) in embedded ads/restricted-iframes/etc, so sites can stop ads from destroying the website performance for users over time. I've often seen ads taking 300MB-2GB. I'm sure there are better/more ideas - suggestions? What thought has gone on in the past? (this *can't* be a new observation or idea) Also, I suspect that website behaviors/leaks like this are part of why many users have developed a habit of browsing and closing, opening few tabs at any point in a session (since leaving them open *sometimes* hurts you a lot). Part of why I care about this is that I'm looking at how far we can go with multiple content processes, site isolation, and moving (more) security-sensitive and/or crashy services into separate processes -- all of which come into play here. Side-note: removing the process-id from tabs in mult-e10s has made it harder for me to hunt down offending tabs, since I track down runaway memory/CPU in things like Process Explorer. (Usually after I notice that the browser has gotten slow/non-responsive) Totally reasonable, though I'd like to see the ID back on Nightly at least - makes starting GDB against the right content process *much* easier, and I don't have to limit the browser to 1 to avoid the problem. -- Randell Jesup, Mozilla Corp remove "news" for personal email _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
