Open tabs keep getting forgotten

[Sam Bull]

The browser app keeps forgetting my open tabs on a semi-regular basis. It seems to happen to me every couple of weeks or so, I will open the app and all my tabs are gone. This is very frustrating, as there is no easy way to recover them.

I think it may actually happen more frequently when there are around 7/8 tabs or more open.

OTA-12 (and previous versions), mako.

[Sam Bull (dreamsorcerer)]

This feature simply doesn't seem to work anymore. I don't remember it correctly restoring tabs in the past couple of months.

[Olivier Tilloy (osomon)]

It might very well be that the file that stores your session is corrupted, or that the corresponding lock file is stale. Can you try removing ~/.local/share/webbrowser-app/session.json* and report here if it makes things better?

[Sam Bull (dreamsorcerer)]

Seems to be working better, having deleted that file. So, maybe some better logic for detecting/handling corrupted session files is needed.

[Sam Bull (dreamsorcerer)]

Back to the original bug. It's been 2-3 weeks, and now it has forgotten my tabs yet again. Friday night, I closed the browser with 7 tabs, afterwards I shutdown the phone. Saturday morning, I turned my phone on, opened a twitter link, the browser app opened with only this tab, having forgotten my other 7 tabs.

[Sam Bull (dreamsorcerer)]

So, I think I've found the cause to atleast part of the issue. Recently, the app broke again failing to remember my tabs at all.

Looking in my files, I noticed a ~/.local/share/webbrowser-app/session.json.lock file, even though the app wasn't running. The actual session file was absolutely fine, and still contained my session from a couple of weeks earlier, the app just wasn't loading it due to the lock file. Deleting the lock file had my old session back up and running.

Before I deleted it, I had a look at the lock file, and found that it was an empty file. I would have expected the app to write its PID into the lock file when creating it. Then, when the app opens and sees a lock file, it can check if the given PID exists, and if so exit. If the process no longer exists, then it can take over ownership of the lock file.

Perhaps implementing this kind of basic behaviour would be enough to fix this issue, as it looks like it may just be a crashing application failing to remove its lock file.