Closed
Bug 943254
Opened 11 years ago
Closed 10 years ago
[B2G][Browser] limit the number of the browser history
Categories
(Firefox OS Graveyard :: General, defect)
Tracking
(blocking-b2g:1.3+)
RESOLVED
WONTFIX
blocking-b2g | 1.3+ |
People
(Reporter: seinlin, Assigned: seinlin)
References
Details
Attachments
(3 files)
For low memory device such as device in bug 929945, it could be better to limit the memory consumption of the browser to a reasonable amount. If the browser consume more and more memory after using for some time and the system will be in a very low memory condition and browser will be killed by OOM killer even it is on foreground.
Comment 1•11 years ago
|
||
I'm also investigating the memory usage of browser. Could you please name a few use cases/sites that kills? It would be great if we have benchmarks before starting to code.
Comment 2•11 years ago
|
||
Usually there are two problematic cases. Slow leaks (we run out of memory over time), and sudden OOM (we can't render a specific site). It would be great to get comparison with other systems. Any site a 128 MB Android device can render we know can be rendered in 128 MB. If you can give us examples of such sites, we can figure out the sudden OOM case. For leaks, we would need instructions how to make it leak so we can reproduce.
Assignee | ||
Comment 3•11 years ago
|
||
I also found a case that it is not browsing to a specific sites, but it is quite practical. For example when browse to a news page or google search result page and there will be some related links, if keep continue browsing to more and more links, finally OOM and the browser could be killed. I think it will benefit devices with low memory if the browsing history could be limited according to the total memory consumption.
Comment 4•11 years ago
|
||
Kai-Zhen, you can try to turn off the bfcache by setting this pref to 0: https://mxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#69 and also limit the history entries with the next pref.
Comment 5•11 years ago
|
||
Should we redefine this bug as finding a better max value of history entries for low-end (memory) devices? I think it is an approach of improving the usability of low-end devices to downgrade the service quality and avoid OOM, just like this bug.
Updated•11 years ago
|
Whiteboard: [tarako]
Updated•11 years ago
|
blocking-b2g: --- → 1.3?
Comment 6•11 years ago
|
||
triage: this is needed for tarako device (or device of similar size memory) but this should not be uplifted to 1.3. Using [NO_UPLIFT] to create a query of bugs that needs to happen on 1.3t branch if it gets created
blocking-b2g: 1.3? → 1.3+
Whiteboard: [tarako] → [tarako][NO_UPLIFT]
Updated•11 years ago
|
Assignee: nobody → kli
Assignee | ||
Comment 8•11 years ago
|
||
I setup a test to verify the different between when browser.sessionhistory.max_total_viewers is set to 1 and 0. During each test, I did the same action and visit to the same sites and pages. The memory usage of browser is logged every second. Test result shows that there will some different when zram is not enabled; And there will be almost no different when zram is enabled. Uss-1: browser.sessionhistory.max_total_viewers = 1 Uss-0: browser.sessionhistory.max_total_viewers = 0
Flags: needinfo?(kli)
Assignee | ||
Comment 9•11 years ago
|
||
Based on the same test as described in comment 8, I collected another value, the amount of memory used by zram. The result shows that there is almost no difference between when browser.sessionhistory.max_total_viewers is set 1 and 0.
Comment 10•10 years ago
|
||
triage: base on comment 8 and comment 9, this provides no major saving. Closing as invalid
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Summary: [B2G][Browser] limit the memory consumption of the browser → [B2G][Browser] limit the number of the browser history
Updated•10 years ago
|
Resolution: INVALID → WONTFIX
Comment 11•10 years ago
|
||
clear [tarako] whiteboard as this is not needed anymore for tarako
Whiteboard: [tarako][NO_UPLIFT]
You need to log in
before you can comment on or make changes to this bug.
Description
•