4 ms·

What would an updated version of Session Restore look like? I mean, what would be your vision for a new version?

Yoric 10y ago
I haven't worked on Session Restore in some time. But from the top of my head, it would be as follows. On the back-end, I believe that Session Restore should be backed by a database, with each tab updated independently, rather than a big bunch of JSON data. The rationale being that: - it's performance-critical; - it's safety-critical; - we have users with 300+ Mb of data in their Session Restore and JSON isn't meant for this scale of data; - we wouldn't need to rewrite x Mb of data every 15 seconds, just a per-tab update; - if we're using a relational database, it would be easier to trust the code to not screw up with the data; - we wouldn't need to load the entire Session Restore upon startup. (On the minus side, this might make backups a bit more complicated.) On the front-end, we would need a high-level API for Session Restore, which would let us do things such as accessing per-tab data, (de)hibernating tabs, etc. Oh, and it would need to be accessible by WebExtensions. In the middle, we would need to re-engineer Session Restore to make sure that we don't need to maintain this huge object representing the entire state of the session. We would also need improvements e.g. to cookie management, to avoid having to re-collect cookies so often.
- Dylan16807 10y ago
  How does that much data get into Session Restore? Mine are only about 3KB per tab, and Firefox starts melting at more than a thousand tabs.
  - Yoric 10y ago
    I seem to remember that DOM Session Storage and Session Cookies are pretty big offenders. Other websites (e.g. Google Docs) use lots and lots and lots of hidden forms to remember lots and lots and lots of data. Also, people who keep Session Restore tabs open (you know, the tab that lets you restore your session, when you have crashed) and continue browsing – Firefox needs to store several nested Session Restore JSON files.
    - db48x 10y ago
      I've always been impressed by that, because it's essentially bullet-proof.
      - alphapapa 10y ago
        I wish it were, but every now and then, I restart Firefox and get empty, title-only tabs that go to about:blank when I reload them, completely losing the tab. I have to use a Python script to dump the session data (which still appears in the JSON file, even though Firefox won't use it), eyeball the list to figure out which tab was broken, and reopen that URL manually.
- alphapapa 10y ago
  Using a SQLite database for Session Restore seems to make sense. However, it would make it even more difficult to get data out of it when necessary. As ugly as a mess of JSON is, at least it's text, and I don't have to write a SQL query to grep for URLs. Why not just use the filesystem? Imagine a layout like this: + profilename.default |--+ sessionrestore |--+ <timestamp> |--+ window1 | |--+ tab1 | | |--- cookies | | |--- formdata | | |--- title | | |--- url | ---+ tab2 | |--- cookies | |--- formdata | |--- title | |--- url ---+ window2 |--+ tab1 | |--- cookies | |--- formdata | |--- title | |--- url ---+ tab2 |--- cookies |--- formdata |--- title |--- url One directory per timestamp, containing one directory per window, containing one directory per tab, containing one file per data type. All plain-text. Change a tab, just write to that tab's files, and update the timestamp directory name. Every x minutes, make a new timestamp tree, keeping y old ones as backups. No serializing and writing entire sessions to disk at once. Only small writes to small files. All plain-text, easy to read outside of the browser. Easy to copy, backup, modify, troubleshoot. No complex JSON, serializing, or database code. Use the write-to-temp-file-then-rename-over-existing-files paradigm to get atomic updates. Need to know if part of a session on disk is stale? Check the mtime for that file, see if it's older than the last time that data was changed in memory. Simple stuff. Straightforward. No overengineering. No bloat. Why not do this?
  - cwillu 10y ago
    Not cross platform, without a tonne of extra work that, surprise surprise, things like sqlite already take care of. Overengineering is ignoring the off-the-shelf part that solves your problem because you "know" you could do it better yourself, in a simpler fashion. It's a non-issue anyways, I have yet to see anyone show any actual evidence of an ssd dying prematurely or suffering degraded performance from this behaviour.
    - arpa 10y ago
      what operating system does not have filesystem support? :(

Yoric 10y ago

I haven't worked on Session Restore in some time. But from the top of my head, it would be as follows. On the back-end, I believe that Session Restore should be backed by a database, with each tab updated independently, rather than a big bunch of JSON data. The rationale being that: - it's performance-critical; - it's safety-critical; - we have users with 300+ Mb of data in their Session Restore and JSON isn't meant for this scale of data; - we wouldn't need to rewrite x Mb of data every 15 seconds, just a per-tab update; - if we're using a relational database, it would be easier to trust the code to not screw up with the data; - we wouldn't need to load the entire Session Restore upon startup. (On the minus side, this might make backups a bit more complicated.) On the front-end, we would need a high-level API for Session Restore, which would let us do things such as accessing per-tab data, (de)hibernating tabs, etc. Oh, and it would need to be accessible by WebExtensions. In the middle, we would need to re-engineer Session Restore to make sure that we don't need to maintain this huge object representing the entire state of the session. We would also need improvements e.g. to cookie management, to avoid having to re-collect cookies so often.

Dylan16807 10y ago
How does that much data get into Session Restore? Mine are only about 3KB per tab, and Firefox starts melting at more than a thousand tabs.
- Yoric 10y ago
  I seem to remember that DOM Session Storage and Session Cookies are pretty big offenders. Other websites (e.g. Google Docs) use lots and lots and lots of hidden forms to remember lots and lots and lots of data. Also, people who keep Session Restore tabs open (you know, the tab that lets you restore your session, when you have crashed) and continue browsing – Firefox needs to store several nested Session Restore JSON files.
  - db48x 10y ago
    I've always been impressed by that, because it's essentially bullet-proof.
    - alphapapa 10y ago
      I wish it were, but every now and then, I restart Firefox and get empty, title-only tabs that go to about:blank when I reload them, completely losing the tab. I have to use a Python script to dump the session data (which still appears in the JSON file, even though Firefox won't use it), eyeball the list to figure out which tab was broken, and reopen that URL manually.
alphapapa 10y ago
Using a SQLite database for Session Restore seems to make sense. However, it would make it even more difficult to get data out of it when necessary. As ugly as a mess of JSON is, at least it's text, and I don't have to write a SQL query to grep for URLs. Why not just use the filesystem? Imagine a layout like this: + profilename.default |--+ sessionrestore |--+ <timestamp> |--+ window1 | |--+ tab1 | | |--- cookies | | |--- formdata | | |--- title | | |--- url | ---+ tab2 | |--- cookies | |--- formdata | |--- title | |--- url ---+ window2 |--+ tab1 | |--- cookies | |--- formdata | |--- title | |--- url ---+ tab2 |--- cookies |--- formdata |--- title |--- url One directory per timestamp, containing one directory per window, containing one directory per tab, containing one file per data type. All plain-text. Change a tab, just write to that tab's files, and update the timestamp directory name. Every x minutes, make a new timestamp tree, keeping y old ones as backups. No serializing and writing entire sessions to disk at once. Only small writes to small files. All plain-text, easy to read outside of the browser. Easy to copy, backup, modify, troubleshoot. No complex JSON, serializing, or database code. Use the write-to-temp-file-then-rename-over-existing-files paradigm to get atomic updates. Need to know if part of a session on disk is stale? Check the mtime for that file, see if it's older than the last time that data was changed in memory. Simple stuff. Straightforward. No overengineering. No bloat. Why not do this?
- cwillu 10y ago
  Not cross platform, without a tonne of extra work that, surprise surprise, things like sqlite already take care of. Overengineering is ignoring the off-the-shelf part that solves your problem because you "know" you could do it better yourself, in a simpler fashion. It's a non-issue anyways, I have yet to see anyone show any actual evidence of an ssd dying prematurely or suffering degraded performance from this behaviour.
  - arpa 10y ago
    what operating system does not have filesystem support? :(