"mozilla-central" gecko revision="a4c1961bf723" "gecko.git" "e1ec7bf56f833462f1f317defc6b05e697911b06" "gaia.git" revision="c7272f0b45c9fdac9d551828987e343300e87bf6" Build ID: 2013-07-25-03-02-11 MC/master build Unagi 1. launch browser 2. go to http://www.cnn.com 3. open a new tab, go to http://people.mozilla.com/~nhirata/html_tp 4. open a link in a new tab 5. check the tab tray 6. repeat 4/5 until the cnn.com tab clears out. Expected: cnn.com doesn't change Actual: cnn.com tab shows the sad face icon, when switching to it it's blank. Note: 1.
From looking at the log, I am guessing we OOM? There's no error message in terms of content crash, it's just the sad face icon. about memory-3 is w/ the browser just opened after reboot about memory-4 is w/ the browser w/ the crashed tab about memory-5 is after the browser had been closed.
> From looking at the log, I am guessing we OOM? https://wiki.mozilla.org/B2G/Debugging_OOMs
so is this invalid?
I will double check when I get back from PTO; Should the sad face appear when we OOM? This might be more of a UX question...
Yeh this is somewhat a UX thing, chrome for android from what I remember doesnt keep any tabs in the background at all so every time you visit a tab its reloading, all the page screenshots are kept at last known state, We keep them in the background and it may oom, but we cannot know if it oom'd or it died due to an error so maybe we do not want to show crash sad faces in the tab list at all? the next time we go back to the tab it will as the video showed reload and this is all expected behaviour. clearing needinfo on Naoki
FWIW, on my Nexus 4, Chrome for Android definitely does keep tabs open in the background. Maybe it's a function of available RAM or something.
Yeh my memory is hazy but I do remember reloading when switching tabs a lot, the point being that given a lot of tabs open us killing the background ones is it working as it should be and probably not something we should be notifying users about.
Just to follow up, we are OOMing: <4>[08-16 20:44:25.993] [2083: Browser]select 1566 (Browser), adj 6, size 8330, to kill <4>[08-16 20:44:25.993] [2083: Browser]send sigkill to 1566 (Browser), adj 6, size 8330 The STRs do not necessarily have to be the web sites listed. www.cnn.com seems to cause the OOM to occur faster. After a reboot of the device, I was able to reproduce the OOM with 3 websites and scrolling down the websites and back up: www.cnn.com news.google.com youtube.com Granted there are lots of images on all 3 websites, I think getting notified with only 3 websites listed will cause people to freak out...
Here's my take on this. Let's not show that frowny face in tab thumbnails. Ever. I know we just added it in bug 825089 but now that I have a better understanding of when we show it and why, I think the sad face is just about the last thing a user should see in their browser tabs list. Particularly for a problem as non-catastrophic as losing the content of one of their tabs where a simple auto-refresh when revisiting the tab will solve the issue. Given that, I have a couple of questions / suggestions: When we lose the content of a tab from memory, can we still *keep the preview thumbnail* displayed, and auto-refresh the page when the user returns to the tab? If we can't do that, even a blank white tab thumbnail would be better than showing the sad face which makes a smallish problem look like a big problem from the user's perspective.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.