user.js: 1020: SR max_undo* & 1022: SR after crash : make inactive or remove
🔺 Suggestions
-
1020- remove max_windows- it does not control what is recorded (tabs does that), does not stop any recently closed windows (because the data is gathered with tab activity)
- it does control how many windows to restore, but that has nothing to do with this repo’s objectives. And if a user wants SR, then why change this on them
-
1020- fix up the remaining pref, max_tabs to properly say what it does- IMO not worth being active. If you want to properly control SR, then clear history on close
- make
1022resume from cash inactive or remove it- even if you wipe history on close, a crash is not a graceful exit, so the file remains, and 99% of people would want to restore from a crash, surely
- add info to
0102- that SR is not used in PB Mode (see 0110) & clearing history (2803, 2804) wipes SR
- add info to
2803/2804(that clearing history clears SR)- it would be nice to have this info directly with the pref, but will only impact those who want to use SR and to do that they would have to change
0102
- it would be nice to have this info directly with the pref, but will only impact those who want to use SR and to do that they would have to change
🔺 ToDo:
- Check if disabling history stops any data collection in
recovery.jasonlz4- done, it has no effect AFAICT - Check if wiping history does anything - done, see below
- MOAR tests
- even MOAR tests
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 1
- Comments: 16 (16 by maintainers)
Commits related to this issue
- 1020: remove max_windows #575 — committed to arkenfox/user.js by Thorin-Oakenpants 6 years ago
- browser.sessionstore.max_windows_undo #575 — committed to arkenfox/user.js by Thorin-Oakenpants 6 years ago
- 0102 add SR info #575 — committed to arkenfox/user.js by Thorin-Oakenpants 6 years ago
my mistake for typing
1023… I meant for resume from crash (1022), my bad - will edit title (edit, title was fine) and OP (once) and 2nd post (once). 🤕OK, I did some playing around. In my main FF rather than a new profile, so it was a bit messy. And the combinations of prefs can quickly escalate. Additionally, it often took two or three open/closes to get things consistent, due to when things get triggered.
one:
2803privacy.clearOnShutdown.historyYou control the persistent local storage of SR thru the above pref. If this is set to true, then ALL data in
profile\sessionstore-backups\is wiped.Doing it manually (
2804privacy.cpd.history) also wipes all data, but then SR files kick back in after x seconds (as per the timing pref in1022). I did not test and do not care if it doesn’t re-record already open tabs etc (I don’t think it does, as the history has been wiped?).Notes : Once you have SR working (don’t clear history on close, and in my case my startup was to resume sessions), you end up with a
previousrestore file (it would take a couple of restarts to build that). I also got anupgrade.jsonlz4-20181114214635file the first time round, but after clearing history in my tests, it never came back.two:
0862: places.history.enabledDisabling history does not stop recovery files. They are still recorded and SR as startup still works. The first time my FF just opened as normal (on a blank page), but after opening a couple of websites etc, it then seemed to behave. Like I said in the top paragraph, it might take several goes to get consistency.
three:
0804: browser.sessionhistory.max_entriesNot tested and I don’t think it really matters. But max history
per tab, is this respected in the recovery file, e.g. if I set it to 2, what is recorded for a tab I visited 4 sites on - just the last 2, or all 5 (yup, it includes the original page: e.g your startup/newtab page?