[SFOS Browser] Solving the browser memory issue

General
#1

Today is a beautiful day, and nothing would make me more happy than spending it inside looking into the memory issues related to the SFOS native browser.

No surprise to anyone here that the browser crashes frequently, and when it crashes, it takes other natives apps with it. I want to address this issue.

Goal of this post is to produce a bug report as extensive as possible for the devs. Reason of this post is “how should I proceed to do so ?”

  • What tools can I run on my phone to track the live memory consumption (htop kinda) ?
  • Where can I find the crash logs of the browser ?
  • Different scenarios ideas:
    • browser only, open a few tabs that consume a lot (youtube for example)
    • browser + other native apps
    • same tasks after reboot of the phone

Can you think of other scenarios and other measurements that can be done to have an extensive bug report ?

11 Likes
[4.5.0.19] X10iii All native applications just crash
My wishes of the next release: just fixup, e. g. the OOM-killer situations
Sony XA2 Plus v Xperia 10iii Experiences
#2

Is this maybe duplicating MCE is using wrong metric to properly measure RAM usage - #21 by lkraav

1 Like
#3

from my understanding this bug report was for many apps open at the same time. Not targeting the browser, which can crash even if its the only app.

#4

Yes, the browser crash problem is independend of other open apps or no other open app, and also independent of number of open browser tabs.
On my devices it mostly occurs while scrolling big/long pages hesitantly or leaving the finger on the screen and not release it quickly after scrolling. It also occurs more frequent if some pages load a larger amount of data like images or code.

8 Likes
#5

My observation is exactly the same.
This is very annoying with particularly long texts, because you have to scroll from the beginning of the text to the current position when reloading the page. This often leads to a new crash.

2 Likes
#6

@Seven.of.nine @silta , if you have any examples of websites that crash 100% of the time, I can add it to the scenario.

2 Likes
#7

No page crashes 100%, but affected pages do crash often. Some pages never crash.
Sometimes the whole SFOS is rather lazy for unknown reasons, i have no idea on what this depends. If this is so, the browser crashes also occur more frequent.
The only idea i have is, considering that the browser is very ‘outdated’, some incompatibility with javascripts in present-day webpages. (outdated, incompatible interpreter in the browser?)

1 Like
#8

I usually read Le Temps on my phone, and that happens quite irregularly. It’s not easy to check because it’s behind a paywall. I have a subscription to Republik and they don’t use a password, but I don’t spend too much time reading that paper.

#9

As @Seven.of.nine said, no website crashes 100%. The sites I read regularly are perspective-daily.de, zeit.de and this forum.
The most affected one is perpective-daily followed by zeit.de
The sailfish forum never leads to a crash :smiley:
In case of the other two it’s the same like @pherjung wrote. I read them in a payed version, so it might be difficult to check it without access.

2 Likes
#10

If i understand/ remember mce correctly it asks apps to free ram (caches etc) maybe we could just emulate the signal which mce uses with a cronjob, or by hand and see if it reduces the memory needed by the browser?

1 Like
#11

if you know how to do so just send me how and I will try it (and any other tips for this because so far I still dont know how to do this)

1 Like
#12

Today in the morning I had to literally struggle with the browser. It crashed on me 3 times in a row. I’m slowly getting sick of it.

1 Like
#13

Yes, but never had this laziness problem since i use cpufrequtils to set govenor to performance (At least on XA2 Plus). Browser still crashes but not due to lazy os.

#14

It certainly does crash very frequently now, much more so than in the previous 4.4 releases, or so it seems.

#15

This is probably placebo, but can someone with constant crashes try to remove ‘f’ at the end of apz.touch_start_tolerance in about:config? Don’t see it in android firefox, probably is optional and again placebo but after removing it it seems to lower the crash rate (browsed 3-4 heavy pages like bbc/zeit etc and only managed to get a crash from oom - with all other app covers greyed out, unlike the random browser crashes that leave other apps alive that showed up in 4.5, links and copy-pasting seems unaffected), a reliable crashing website would be really useful to eliminate the placebo effect
BTW where is the browser code on github??? Searching for ‘apz.touch’ in the browser repo returns two commits from 2015 to a file that no longer exists in the current state (neither in 4.5 branch or next, master is unchanged in over a year)
Edit: I guess this was the fix [qtmozembed] Use physicalDotsPerInch for EmbedLiteView dpi. Fixes JB#… · sailfishos/qtmozembed@399ac59 · GitHub
Edit: nope, nvm, just had a non-oom crash, I guess if you want the browser to be stable for an hour try to crash it (at least in your mind)

3 Likes
#16

I removed the f and am very curious now what will happen.

edit: Yippie yeah! Browser is clear better now, not so lazy on taps as before, loads pages faster and typing on keyboard is much more comfortable now.

edit: for what at all came a f in this input field originally? In all apz.touch_*… config fields there is not a single letter but only numbers.
Crashes still occur but much less as before.

2 Likes
#17

Sadly doesn’t seem to work (I guess if you want the crash to happen it reads your mind and gives you an hour to tease you), it seemed somewhat plausible as old qt means old bugs (like base64 function that’s broken if you try to do a round trip, maybe float handling is also borked and the new value we recently got as a fix for long-taps is causing issues more often than old? Not entirely absurd, as the engine hasn’t changed that much, what else could be causing it. It’s definitely a recent change, so narrows down the list of culprits)

#18

This page always results in a oom-kill on my xperia 10 II:

1 Like
#19

Please keep in mind this post is about how to detect errors around the browser or procedures and not a complaint post about the browser.

I will also take the websites from the post bellow to the test bench, might be better to post your links there rather than here.

1 Like
#20

Since i updated the Volla/GS290 to SFOS 4.5.0.19 no more browser crashes!!!

Thank you @piggz and @Jolla !

edit: unfortunately i have to report my first browser crash. :cry: but it’s much - edit: very much less often now.