New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 171316 link

Starred by 196 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: WontFix
Owner: ----
Closed: Aug 2017
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Pages constantly reload on Chrome for Android, for no apparent reason

Reported by, Jan 21 2013

Issue description

Example URL:
Any webpage, even static HTML

Steps to reproduce the problem:
1. Load up a handful of tabs.
2. Read one tab for a couple minutes, or let the screen turn off and then go back to Chrome.
3. Go click on the other tabs.

What is the expected behavior?
Simply show the already loaded pages in the other tabs.

What went wrong?
The tab reloads all over again, killing 15-30 seconds per tab every time, even for static pages.

Did this work before? N/A 

Chrome version: 18.0.1025465  Channel: stable
OS Version: 4.2.1; Nexus 10 Build/JOP40D

I realize this may be part of the Android routine of putting processes in the background to save memory, but I see no reason why the page can't be cached and only reloaded if the Reload button is hit.  I've used the original native web browser on Android 2.2 and it didn't have this problem.  Unfortunately, this bug is still there in the Chrome 25 beta and it's maddening, rendering Chrome all but unusable if you're switching between multiple tabs, as you might do on the desktop.
Showing comments 37 - 136 of 136 Older

Comment 37 by, Apr 16 2013

It happens with cnet and the verge too. In my experience it happens with
all web sites. It's a bug in Chrome for Android, nothing to do with web
developers. That's why the desktop version and all other Android browsers
work as expected.

Comment 38 by, Apr 16 2013

Also, if I have multiple tabs open, then close one tab, then press the home button to close Chrome, then reopen Chrome from the recently closed list, Chrome will reopen the last closed tab and the reload the page as well as reloading all the others!

Comment 39 by Deleted ...@, May 7 2013

With enough tabs open this behavior is seen when switching between the active tab and one previously loaded. What's the point of the cache being more than double the app footprint if its considered invalid/stale and ignored? 
Reviewing the contributions above, it seems to me that there are two (probably more) interrelated issues : on Android platforms, the inability to clear Chrome's cache reliably and the persistence of the phone's memory, and a possible interaction between the two issues. 

Which are we discussing?

My experience is that sometimes I can duplicate the aberrant behaviour (failure to clear cache or phone memory or both)in different browsers on the same Android phone. And occasionally on iOS (Safari of course).

In which case Chrome may be off the hook.

Could someone help me..... in relation to this set of problems, what action is going to be taken by whom and by when. Or do we all '...move on...'?

I am very grateful for all the effort put in by many on this project.

Comment 41 by Deleted ...@, May 9 2013

This is not a cache issue. The issue is the cache is being ignored and pages are reloading in persistent tabs. My comment about cache size was rhetorical.

Nothing is being done.

Comment 42 by, May 10 2013

Chrome for android feels super slow because of the reloading behaviour. Every time I tap on the chrome icon I have to wait for a page reload, before I can even type in a new URL in the address bar. I would expect no reload at all, unless I tap the reload button

Comment 43 Deleted

Comment 44 by, May 10 2013


Where ARE you? Chrome is giving Android a bad rap because of issues like these.

Not to sound underappreciative of your work, but FIX IT! This should be a priority!


Comment 45 by Deleted ...@, May 13 2013

Dolphin browser doesn't seem to have this issue. I would like to use chrome since it's my favourite on desktop. But for powerusers chrome is unusable imo even on wlan.
Dito.  It's near to not usable at all. If the Android launcher would behave similar, IT would reboot the Phone every time i press the home Button.  Please Do something... 
What's also very frustrating is that sometimes I would switch tabs and the page content is right there, but then Chrome starts to reload it making me wait when I could have just used what was right there!

Comment 48 by Deleted ...@, May 15 2013

I have been facing the same issue but it's not there in my friend's nexus 4. I am using SGS3. I love chrome but this is screwing my experience. 

Comment 49 by Deleted ...@, May 22 2013

I have had this issue for what seems like forever. If I'm reading an article and switch tabs for more than ten seconds, the tab I switch back to the article reloads and starts at the top instead of where I last was reading... Can be quite annoying. 

Comment 50 by, May 31 2013

It's been more than four months since I reported this issue and there hasn't been any progress, no Chromium commits in this thread.  This is now the sixth-most starred Android issue that has been assigned, and it is far more important than whether Android ever gets extensions or WebGL, as it is a matter of basic usability.  Is anything going to be done?

Now that Chromium has some offline support, if only behind a flag, perhaps that code can be repurposed to cache background tabs, even if behind a flag.  Add a "Cache on Android" flag and let us try it out.

Comment 51 by, May 31 2013

Thanks for all of the reports here - please be assured that this specific issue is being addressed with priority.

We have been tuning the tab management mechanism to make such reloads occur less often and first improvements have been put in place for Chrome on Android 28 Beta - could you guys give it a try and let me know if your perceived experience is better?

Comment 52 by, May 31 2013

@joakim Of course, we are working on this. Unfortunately, this is a very hard problem and the cache is not going to help us very much since tab restores _already_ go through the cache. The problem is that there are several resources which are no-store. Second, rendering the page itself, even from cache takes a non-trivial amount of time on mobile devices. 

The offline support that you mention is mostly useful on the desktop. 

Comment 53 by, May 31 2013

The rendering isn't problem -- especially modern dual/quad core devices --
it's Chrome downloading the data again, or worse, trying to download when
there's no connection and thus blanking the page.

Comment 54 by, May 31 2013

I can conclusively state that page caching performs much better with Chrome 28. I noticed that before I actually came back to this page. It definitely still needs work, but sites cache more frequently without needing a reload. However, I just tried to load a page from cache and the layout was restored quite badly. Pictures are attached.

Sent from Chrome 28—Nexus 10

Comment 55 by, May 31 2013

I guess you forgot to add the pictures ;-)

Comment 56 by, May 31 2013

That... Is really weird! I attached the files. :p Oh well, haha, attaching again.
406 KB View Download
741 KB View Download

Comment 57 by, Jun 1 2013

For what it's worth, all browsers suffer from this to some degree on my One
X. Firefox is the same, if not worse, than Chrome. Opera is significantly
better but can still be provoked into doing after loading around ten tabs.

The difference in UIs is notable. Firefox's is just terrible. Opera is
innovative but is rather complex. Chrome is by far the best, "getting out
of the way" of actual browsing much more than the others, and with better
private tab and cut/paste/search UIs.

I'm looking forward to these changes going into the stable release. Thank
Philippe and sidv, thanks for the update.  I have been using the Chrome beta exclusively from the beginning of the year and I do not notice any difference in 28.  In fact, I commented here again because it seemed as bad as ever, making using my Nexus 10 for web browsing a frustrating experience.

I had assumed that my flaky and sometimes slow internet connection was making this problem worse, by slowing down the constant page reloads, but I now see I was wrong about that.  I just tested with a 4 KB static web page on my server and the page was only downloaded once, according to my web server logs.  When I go back to this tab after it has been backgrounded, it shows the loading animation for a second or two and doesn't show the web page right away, which I thought meant it was downloading again, when it appears only to be rendering from cache again, as sidv says.

I'm not sure why an Exynos 5 Dual Cortex-A15 needs that long to render a simple static web page, when it can decode 1080p video just fine, but this does go some way to explaining why more complex web pages take even longer to reload after they've been backgrounded.  I hope something can be done about this hard problem, and that this thread can be used to lay out what technical solutions are being planned, so that we, the users stuck with this frustrating user experience, know something is being done.
> I just tested with a 4 KB static web page on my server and the page was only
> downloaded once, according to my web server logs.  When I go back to this tab
> after it has been backgrounded, it shows the loading animation for a second or
> two

That's an interesting observation. Can you attach contents of your about:histograms shortly after it happens next time?

Comment 60 by, Jun 2 2013

Joakim, nice investigative work. I too have a Nexus 10, and page backgrounding; the reload times; they are slightly frustrating compared to my desktop PC. I hope that the developers can come to a solution that works, considering the depth of this problem. The main issue I had was communication—this thread would not have been updated unless you took the initiative to ask yet again. I would like to request the developers here give us some brief updates, just once in a while. Even once a week, if possible. That would placate me.

I too am confused why such a powerful device takes so long to process a simple web page, although I'm fairly sure it has something to do with the fact that the GPU doesn't really get involved in the majority of heavy-lifting. Developers, is there anything that can be done (even long-term) to significantly reduce that wait time?

Thanks. We certainly appreciate your hard work.
Would be nicer to have a cached screenshot rather than a blanked page. Perhaps add a small wating animation when re-rendering. Then everybody knew what happens -> less frustration?

Comment 62 by, Jun 6 2013

Thanks for all of the remarks!

Let me elaborate a bit on the technical aspects involved here.

In certain circumstances, certain tabs are being dropped from memory and need to be reloaded when we switch back to them. There are two main reasons for that:
- Memory pressure signal delivered by the OS (we drop some tabs to accommodate the memory needs of the rest of Chrome and the system itself)
- Chrome is being silently killed by the OS after a period of inactivity - this problem is not Chrome-specific, all backgrounded apps were created equal in that matter

Between M27 and M28 we did significant work on tuning the behavior in the memory pressure scenario in order to preserve more tabs while still abiding the memory good citizenship rules (and I am happy to hear that you see the improvement, cwalkop), but we may still be losing tabs when Chrome stays in the background for a prolonged period of time.

As to the reload itself, the observations made by joakim match my understanding of Chrome policies - we are *not* reloading the resources from the network if we have them in http cache. 

Unfortunately, load from cache is not necessarily fast, as we can clearly notice, but we may hope to improve on that as well, see .

Could you give us more details about your use scenario, joakim? Do you notice tabs being reloaded while you actively switch between them in one session, or just after bringing Chrome back to foreground?

Comment 63 by, Jun 6 2013

Thanks for the explanation. That helps a lot. I can't go into an in depth discussion ATM, I have to work soon. However, I will complement whatever Joakim has to say with this: suffice it to say that I can never trust Chrome to keep more than two tabs actively cached in memory WITH the browser open, even on my Nexus 10.

Also, I'm very interested in that new caching system. Any idea on a timeframe for that? Chrome 29, perhaps?
I can confirm that the Nexus 7/10 acts the way that post #63 mentions, it truly annoys me to no end.
Considering this also happens on a newly rebooted Nexus 10, I doubt there is a shortage of memory that causes this.
Oddly enough, my gf's nexus 4 does not exhibit the same tab-reloading behavior as my HTC One.  Both phones with multiple tabs open, sitting idle for about 10 mins.  You open up chrome on the n4, and the tab looks exactly the same.  On my HTC One, the tab instantly reloads.

Comment 66 by, Jun 7 2013

Sometimes the page is definitely reloaded from server because I'm promted to log in again.

Very often it happens that I have only 2 tabs open, switch from A to B then from B to A in less than 20 seconds and A is reloaded. 

I have plenty of RAM available.

Comment 67 by, Jun 7 2013

Thanks for the reports!

LarsenAndroid, erikiksaz, jbtibor - could you check what version of chrome (available in chrome://version) are you on? If this is 27 or earlier, you guys could try the newest Chrome Beta ( ).

At least for the tabs that are in active use in one browsing session, the experience should be better.

Comment 68 by, Jun 7 2013

I have 27.0.1453.90 and Beta 28.0.1500.37
I don't feelt there is a relevant difference between the two regarding this issue. It might be in code but it doesn't feel so.
Philippe, like many others, I was seeing constant page reloads while actively switching between tabs in one session, not to mention bringing Chrome back to the foreground.  However, I think I've stumbled across one reason for this, at least on the Nexus 10.

There appears to be a long-standing memory leak with Android 4.2.2 on the Nexus 10, where the Mali T604 driver leaks memory over time and eventually takes up 4-500 MBs, making the Nexus 10 unstable.  This appears to show up as SurfaceFlinger, the Android window manager/compositor, taking a bunch of memory.  I just checked and the SurfaceFlinger process was up to more than 400 MBs RSS, according to ps from a terminal, after 7 days of uptime.

I rebooted my Nexus 10 and it was back down to 23 MB RSS and Chrome 28 beta was working great again.  No tab reloads, everything was instantaneous.  I will stress it some more with a bunch of tabs and let you know how it responds when SurfaceFlinger hasn't leaked.

I recommend that everyone else experiencing this problem on the Nexus 10 with Android 4.2.2 try the following:

1. Install the free Android Terminal Emulator app from the Play Store.  I installed the one by Jack Palevich.
2. Open it and type in "uptime" followed by "ps su".  These commands will tell you how long your tablet has been running and how much memory /system/bin/surfaceflinger is using.
3. Reboot your Nexus 10 and then check the same info, along with how the Chrome Beta works after the reboot.

I found about this bug from the following xda thread and Android issues:

It appears that my problems with Chrome on the Nexus 10 are an interaction between that memory leak and Chrome.  That leak probably needs to be fixed before looking at Chrome, but I'll stress Chrome when that leak hasn't ballooned and see what I find.  The commenters in those threads seem to have tracked this leak down to the graphics driver, thanks to those devs for the great detective work.
That is one big memory leak, nice find.

But, I'm a little confused since I still have the problem on my newly rebooted Nexus 7/10 with the latest stable and Chrome Beta.

I'll attempt to reflash it and see what happens over time.
In response to post #67, we are both running the most updated version of chrome on the play store.  But, before that, I was running chrome beta version 28.0.1500.37 (1500037).

I've recently updated my 4.1 JB version to the leaked 4.2.2, and the issue with reloading tabs has decreased a bit than compared to 4.1  But, it still definitely does still reload tabs compared to the stock nexus 4.
I can confirm that after rebooting and without a seperate login of another user account there is no tab reloading. At least i didn't experienced one in several hours, even after bringing chrome back to front after an hour of inactivity. I'm on Nexus 10 and have the latest chrome (non-beta).

Comment 73 Deleted

Comment 74 Deleted

Blockedon: chromium:218507
Fixing dependency. Resolution of this bug is dependent on the work being tracked on  Issue 218507 . 
Blocking: -chromium:218507
Labels: Hotlist-ConOps

Comment 78 Deleted

Comment 79 by, Jun 23 2013

Any Chrome developers out there willing to explain what the latest update for Chrome did as regards tab management? I did not see anything in the changelog, but Srika referenced  Issue 218507  and stated that a dependency was being fixed.

I infer from this that  Issue 218507  (obviously) is directly related to this issue, perhaps being a core cause? If so, what exactly is this issue? The thread is vague. Is this a massive step in the right direction? Is it aiming to improve the caching of tabs, the ability for tabs to remain in active memory (so they don't need to be reloaded at ALL), or what, specifically?

Comment 80 by, Jun 23 2013

cwal, all that means is that this issue depends on  issue 218507 , which is where all the tab management issues are tracked.  Try clicking on one of the issues linked there, for example,  issue 249214 , where they are experimenting with increasing the number of Chrome processes on Android from 3 to 10.

I didn't notice that they made those issues public on May 31st, as they were private to Google before that, until the dependency was changed here a couple days back.  Now we have more visibility into the kinds of changes that are being made to make Chromium tabs more responsive on Android. :)

Comment 81 by, Aug 8 2013

I have encountered this issue on most mid/low-end Android phones, but even the Galaxy Nexus with 1GB RAM can't hold up. Stock or CyanogenMod - Chrome always reloads when I switch to it and it doesn't even stop loading when I quickly hit the stop button. I don't have this issue on the Nexus 7 - several tabs happily stay open even overnight. That device has 1GB too.

Comment 82 by, Aug 8 2013

Again, I'm experiencing the same issue even on the Nexus 10 with the latest Chrome Beta on Android 4.3. Chrome doesn't want to stay in memory for more than a few minutes, and I can only trust the currently open tab to actually stay in memory.

And this is with 1100MB of free system memory, after GPU allocations. Seriously: its bad. Although no browser really seems to have nailed this formula on mobile yet, sadly. :\ 

At least Chrome has gotten a lot smoother! That's a plus.

Comment 83 by, Aug 8 2013

(1100MB being the total system RAM, not necessarily "free" at the time.)

Comment 84 by Deleted ...@, Aug 21 2013

I have this exact same problem on my Galaxy Nexus. If I load a page, hit "home", and then select Chrome from recent apps, it will automatically load the page again and force me to wait. The other really annoying thing is that sometimes I just want to click on the address bar and type in a new webpage address or search, but because the page is auto-loading, it will refresh and delete everything I was typing in the search bar. So I have to first wait 30 seconds for the page to fully reload after Chrome regains focus, and THEN I can enter in my search and actually navigate to a new page. This is so incredibly annoying that I'm considering ditching chrome until the bug is fixed.
Same problem on my Nexus 10, which is running 4.3 and latest Chrome. Super frustrating when I type in a field and switch tabs to copy/paste then return to original tab only to have it reload, taking all my typing with it. Makes my Nexus 10 an expensive paper weight. Going to try Dolphin. Wish I had never bought the Nexus 10; aside from not being able to use it in summer due to the tremendous heat output, my 2005 Dell desktop is more functional than my Nexus 10.

Comment 86 by, Aug 31 2013

The most frustrating problem with such an otherwise great browser. Makes Chrome feel so slow.
Galaxy Nexus 4.3 Stock
Chrome Beta 31.0.1650.11

I open two web pages, and when I change de tab it allways reload the web page.
This happen every time, every version of Chrome for Android.

Don't happen in Firefox, Opera, Dolphin Browser, ...
the web pages are: and
Same problem still. Makes Chrome Mobile very slow. Have to wait 10 secs to type in a new web address, as it is trying to load the last visited page. Had to switch to Opera Mini.

Chrome: using latest version available in play store

Comment 90 Deleted

Comment 91 by Deleted ...@, Oct 15 2013

Godamn Google what are you doing! After 1 YEAR this isn't solved yet?
This is super frustrating ! when I am in the train and loaded while being in town say, a huge Wikipedia page to read during my travel, the simple fact of switching between 2 tabs force this dumb reload behaviour and my page is lost forever because the train is in the middle of nowhere without any connection!
Not to mention the horribly frustrating lost of a long forum post answer for the same reason.

As a software engineer let me tell me that you have no excuse for having not solved such a stupid bug yet! 
What's difficult in adding an option to disable page refresh , or simply force the current loaded pages to be saved if you can't workaround your caching problem... which is absolutely incomprehensible for a company like yours having the best engineers on this planet!!
If you chromium devs can't solve that by yourselves its time to admit your complete failure and walk towards the next office where the competent people are, seeking for help !

I am sick of this and returns to Firefox for now

Galaxy Nexus latest build
This is blocked on:
Which itself is blocked on:

Please star these other issues to get them noticed ;)
another annoyed user saying sort it out you lazy tards 
Is this ever going to get fixed? I've been following this since January... It is now November. 

I have been using Opera Mobile since, as Chrome mobile is just too slow.
Labels: triage-te
Is there a way to force a process to stay loaded? I specially have a problem with a public transit website. I use it to find a route to my destination then on the way if I want to check the path it reloads the page and gives me an empty form.. or sometimes  session lost related error.. it's not only the question of time, but I won't even get my  back... the website is

also, I was wondering if there is a way to force android to keep a process.. in that case may be a "pin it" button or something like that could help the user keep important pages explicitly .. like addresses, contact info etc.. what I do currently is take a snapshot. 

Labels: -triage-te
I skimmed through the comments and it seems like the direction this is going is towards making the actual refreshing better and loading more resources from cache. Sounds fine for a blog or static site, but this would still break webapps, like Grooveshark, that are interacting with the user in some way, like playing media, because when you go back to the site, it refreshes, interrupting the playback. Can there be an exception added for tabs with active video/audio tags?

Comment 99 by, Dec 5 2013

What about a solution like this:

Simply don't rerender if there is no way to get new data.

What makes this bug so unpleasant is, that it leaves you with a blank page when you don't have a good connection, although you loaded this very page before.

Chrome can try to refresh, but please don't display a blank page if refresh wasn't successful.

#98 #99

I don't like neither a exception for media tags or refresh if not blank page will be shown.

In my case I have a webapp than renders articles, every time I switch to chrome it refresh the page and this re-renders the article (in milliseconds), making it scroll top. Every time I switch to chrome my article scroll is lost.

Not to refresh is the simpler solution for this.
It occurs on a first-generation (grouper) Nexus 7 running Chrome for Android but not on a netbook with the same amount (1 GB) of RAM running Chrome for Ubuntu. So either Android or Chrome for Android is doing something inefficiently.

Comment 103 Deleted

Even with 2GB Ram (Nexus 4, Nexus 7 2013)and a fresh booted device, a single opened Tab will be reloaded, if you switch to the homescreen and switch back after 5 seconds. The Problem appeared some weeks ago, for that reason i use dolphin as a browser, where you can open 10 Tabs and it wont reload...
Please indicate both Chrome version and Android version when reporting issues.

There was a known issue in Android 4.4, which is fixed in 4.4.1. 
I sideloaded 4.4.1 on the Nexus 4 and it seems to have fixed the issue. I've opened 6 Desktop Sites and no reloading after switching to other apps.

I forgot to save Version Number of Chrome (dont know if the update changed it) and Android Build was KRT16S.

On KOT49E with Chrome 31.0.1650.59 1650059 the issue isn't present.

31.0.1650.59 on HTC One, happens on most websites.
Labels: Performance-Battery

Comment 109 by Deleted ...@, Jan 17 2014

Chrome version 31.0.1650.59 on Lenovo S820, reload matter happens while I write this. These is really take my time. 
Labels: Performance-Power
Is this still being tracked and managed by Google? Still having this issue on latest update of chrome 33 and android 4.4. 
See #105, there is a bug in 4.4.
This bug has been opened before KitKat even existed.
Ta, sorry should have said I'm on 4.4.2

Sounds like Google still won't be fixing this any time soon then. Shame as I had to move over to dolphin to fix this issue, but Im missing the link between chrome mobile and desktop
This problem is over a year old, some boff from Google must be able to sort this out

Comment 116 Deleted

If it is the system kill the process due to low memory, we don't have much option. If this happens and you can take a bugreport, please do so and attach in the bug. So that we can confirm whether the tab is gone because low memory. If you can also describe briefly what you did right before you take the bugreport, that will be helpful. We want to solve this problem. But we need some data.
Whether a bug or not, if the process is killed because of low memory then the option is to restore from cache surely?
Yes, that is what we are doing.
Are you unable to recreate the issue? (I sound sarcastic here but I'm not being) I've followed the thread here the best I can, but maybe I'm missing something. What can I supply you with that will help fix this issue?
ppi@, can you reproduce the issue? According to #62, the issue has been addressed to some extent. 

Comment 122 by, Mar 19 2014

Thank's for all the feedback. There's some confusion in this thread, let me try to clarify.

- on Android the operating system is at liberty to kill any background processes, including the renderers of background tabs
- when the OS kills a background renderer because of memory pressure, the tab needs to be loaded again upon tab switch. While this may look like "Chrome reloading a tab for no apparent reason", the tab is already lost at this point
- when we load the tab that was lost in this way we *do* use the http cache to avoid reloading resources from the network
- load from cache is not necessarily particularly fast, because retrieving the resources rarely dominates the page load time

There's been a lot of work focused on addressing this issue on different levels (switch to system-wide oom killing of renderers in order to avoid unnecessary evictions, simple cache speeding up the restore load), but ultimately the fact that we sometimes need to reload a tab upon a switch is a manifestation of multi-process browser running in strictly limited memory, not necessarily an accident / technical bug.

That being said, the problem is complex, affected by many external (platform behavior, other apps holding too much memory in persistent services) and internal factors, and we're constantly looking for things to improve and should watch out for any regressions.

Thus, like Grace said, please provide precise feedback (device, OS version, scenario, available memory as per Settings -> Apps -> Running) when you feel that we're loosing more tabs that we should, but please note that some tab reloads are to be expected for devices with limited memory (e.g. 1GB RAM and apps with persistent services running).

On my side I will take a look at recent UMA to see if there are any red flags.
When I had this issue (It doesn't seem to be happening anymore, but I'm now on ViperOne for HTC One, based on 4.4.2 w/ Sense UI 5.5) I was running Android 4.4 on HTC One Google Play Edition. It seldom had more than 1.2GB of RAM used of the available 1.8GB, and even CPU usage stayed fairly low.

I'm not sure of the criteria but I was having text-only pages reloading while full pages like EBay that weren't.

Unfortunately, since I'm on a different rom, I can't provide any more details, but this particular rom I'm on now usually runs at 1.5G of 1.8G used (I keep a lot of games running in the back, then complain about my battery life, typical American) and I don't see this issue ever until I hit around 16 tabs.

Comment 124 by, Mar 19 2014

In my situation, I have 1GB currently free. I have three tabs open that were properly cached. Nexus 5, stock ROM unrooted; I haven't messed with anything on the phone.

Those three stayed open properly.

However, this page didn't cache at all (it wouldn't load on Airplane Mode):

And this one, the 5th tab back, had to reload from cache:

Then I have tabs from previous browsing sessions, but those obviously wouldn't be in RAM still.

Sorry for my aggression earlier, but it seemed as if there was zero developer activity on this thread and it was getting  frustrating. It was a little over the top. Chrome has gotten a LOT better in recent mobile releases, especially with the touch latency drop in Chrome://flags for desktop sites. That should DEFINITELY be made a default, as a side note.

Comment 125 by, Mar 19 2014

There is an easy solution for Android:
If an application includes a "service", it doesn't get killed by oom priority consideration.

I got a version of opera mobile where a fake dummy service is included. That version was created by a member of the opera forums, I wish I knew how. His post is deleted know (opera didn't want any other than the official versions), but I got the .apk and use it regularly because in fact tabs get NEVER killed with that version. Contact me if you want that .apk, too.

So for Chrome for Android it would be an option, to have a setting whether a service is running which prevents Chrome from being killed by oom (out of memeory) consideration, that would be great!
I'm trying to use a web-based IDE on my ASUS Transformer and this is driving me up the wall sideways - I'd love a copy of that Opera .apk.

Comment 127 by Deleted ...@, Jun 5 2014

Chrome for Android is terrible. Resource hog, fills up my system memory, no flash support, now this. I was trying to fill out a form on one tab, finding links to copy/paste in the other. But the tabs kept reloading, clearing my fields. I had TWO tabs open. I'm done with chrome, Puffin browser for me. Android ICS on tablet.
I also find this issue very irritating especially when memory space is plenty available on the device. 

Comment 129 by Deleted ...@, Aug 6 2014

 #125 I would love a copy of that opera .apk chrome gets really frustrating when working with multiple tabs.
Totally unbelievable. My wife wanted to drop Android because of this incomprehensible bug. I convinced here it was just a problem with Chrome and switching to Dolphin fixed it.

Your failure to fix this boggles the mind. just add a setting to prevent autoreload/rerender unless triggered by the user.
Blockedon: -chromium:218507
Labels: Restrict-AddIssueComment-EditIssue
Status: Available
For everyone interested in reasons for this behavior, please take a look at #122. In particular,

"There's been a lot of work focused on addressing this issue on different levels (switch to system-wide oom killing of renderers in order to avoid unnecessary evictions, simple cache speeding up the restore load), but ultimately the fact that we sometimes need to reload a tab upon a switch is a manifestation of multi-process browser running in strictly limited memory, not necessarily an accident / technical bug."

For a detailed explanation of Chrome process management on Android, please refer to the public doc:

I will keep to bug open to note any future developments in this area, please star the issue if you want to track the progress; and please file individual bugs if you see a regression between two specific versions of Chrome or two specific versions of Android (like in  issue 322336 ).

Comment 132 by, Nov 26 2014

Owner: ----
Labels: -Performance-Battery
Status: WontFix (was: Available)
Maria - can we close this? It's been inactive for 3 years, and I cannot think of any action which would trigger anyone closing this. I believe we've done a lot of work, and anything outstanding makes this bug invalid. Also, comment#131 speaks to it being invalid. I'm going to close but feel free to re-open if you disagree with my action.
Showing comments 37 - 136 of 136 Older

Sign in to add a comment