browser is limited to 2 live webviews

[lgd]

I often open far more then 3 tabs but when I have 3-6 tabs open only and chance back to another one this tab is cleared already and have to reload.

It's not the same but similar to this bug:
https://bugs.launchpad.net/webbrowser-app/+bug/1268055
But while this bug is a wishlist for me this behaviour is very unhandy and annoying:

This is very bad because you run more fast then necessary into the traffic limit of your UMTS provider. And when it is a limited speed it takes really really long to load the other tabs again and again when you have to often chance between them.

In combination with other (maybe unreported until now) bugs it is more bad than this because I have to load the site a while and then stop it because advertisement blocks the view of the website until I stop it - or wait until 30s again for nothing (ads).

How should it work: For example my opera mini on my old andoid device with only 256 MB RAM works much better then this browser with 1 GB RAM on Ubuntu phone - but this can chance. There I can open 50 tabs or more and no tab have to reload!

How could it solved: Maybe there's the possibility for a new option in the optional configuration file for a bigger cache size, a tab number limit or something like this. I have enough RAM but no time and traffic for reloading again and again. Please help as soon as possible.

I used stable and vivid-proposed channel on a BQ phone with all Updates.

Greetings, lgd

[lgd (lgd)]

This takes also effect when I switch to a webapp and back. Even webapps themselves are affected because they use the browser.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Olivier Tilloy (osomon)]

There currently is a hardcoded limit of two live tabs. When opening a third tab, the webview for the least recently consulted tab is destroyed to free up memory. This limit could probably be made a configurable setting, and ideally we shouldn’t have to do that at all, but we’re currently hitting an issue where the system’s out-of-memory handler tends to select the process for the current tab when killing processes to release memory, having the undesirable effect that the current tab goes blank. There needs to be a way for oxide to instruct the system about which renderer process to kill first.

[Pat McGowan (pat-mcgowan)]

Perhaps basing the number on the available memory would be a compromise. I would not expose this to users as they will not know the right answer.

[Bill Filler (bfiller)]

@osomon
Is this still the current behavior or have we changed the implementation?

[Olivier Tilloy (osomon)]

This is still the current behaviour.
We could implement a smarter mechanism that unloads background tabs only under memory pressure.

[lgd (lgd)]

Since last version of webbrowser-app it often under memory pressure kills all my tabs except (the last?) exactly 10. They are in history but this workflow to reopen them is horrible. Please don't kill the tabs on memory pressure - only unload them so they have to and can reload.

[Launchpad Janitor (janitor)]

This bug was fixed in the package webbrowser-app - 0.23+16.04.20160223-0ubuntu1

---------------
webbrowser-app (0.23+16.04.20160223-0ubuntu1) xenial; urgency=medium

  [ CI Train Bot ]
  * Resync trunk.

  [ Olivier Tilloy ]
  * Remove the 'formFactor' context property, and replace all its uses
    by more meaningful conditions. (LP: #1446904, #1542375)
  * Update translation template.
  * Work around a bug in the UITK that prevents touch scrolling to the
    left of the address bar by ensuring that the x coordinate of the
    text field is an integer. (LP: #1546346)
  * Work around bug #1546677 (UITK), by destroying the bookmark options
    popover instead of hiding it. (LP: #1546627, #1546677)

 -- Olivier Tilloy <email address hidden> Tue, 23 Feb 2016 11:24:49 +0000