201–210 of 361 posts
Earlier quoted context omitted.
Probably because most people don't want their profile to be broken if their OS crashes or their computer powers off unexpectedly?
If you miss a sync, your profile isn't going to be 'broken', just out of date.
Earlier quoted context omitted.
No, "people" are not complaining about that; it's a fine attempt at a straw man, though. What the article complains about through implication is that Firefox is unnecessarily writing too much data to disk.
Why would it be unnecessary? The amount of data follows rather logically from the amount of website state it's capturing, and the interval seems totally like personal preference to me. Would you rather lose 60 seconds of work or 15? Uh, I'll take less data loss.
Because you hear the data volume, the function, and you think there has GOT to be a better way
Firefox is relying too much on session restore to deal with bugs in their code. Firefox needs to crash less. With all the effort going into multiprocess Firefox, Rust, and Servo, it should be possible to have one page abort without taking down the whole browser. About half the time, session restore can't restore the page that crashed Firefox anyway.
The Rust part of your comment is irrelevant. There is Rust code shipping in Firefox, but nowhere near the amount needed for observable changes in behavior. Work is being done to put larger components in but nothing is shipping yet. Also, IME most crashes are asserts (in all browsers) and that's not a problem Rust fixes. If you get a segfault-based crash please report it, it could be exploitable. (report normal crashes too, really)
Firefox is relying too much on session restore to deal with bugs in their code. Firefox needs to crash less. With all the effort going into multiprocess Firefox, Rust, and Servo, it should be possible to have one page abort without taking down the whole browser. About half the time, session restore can't restore the page that crashed Firefox anyway.
IIRC per-tab e10s already exists, just isn't enabled by default yet because it has some rough edges. The Rust part of your comment is irrelevant. There is Rust code shipping in Firefox, but nowhere near the amount needed for observable changes in behavior. Work is being done to put larger components in but nothing is shipping yet. Also, IME most crashes are asserts (in all browsers) and that's not a problem Rust fixe…
Wow, that's really unfortunate. I just built a new PC with SSDs, and switched back to Firefox. Even with 16GB of RAM on an i3-2120, Firefox still hiccups and lags when I open new tabs or try to scroll. This new issue of it prematurely wearing out my SSDs will just push me to Chrome. Hopefully it doesn't have the same issues.
Earlier quoted context omitted.
Android Firefox has this set to 10 seconds, rather than the 15 on a desktop.
I think there's something wrong with OP's Firefox. Looking at IO_WBYTES in htop I have exactly 42MB written after 2h11min of operation with 5+ tabs opened at any given time. I have my sessionstore.interval set to 1min. Assuming that if it ran 4x faster (default) it would write 4x more it should be 168MB in 2h of operation, whereas OP reports 1GB every 2h.
Hi, I’m one of the Firefox developers who was in charge of Session Restore, so I’m one of the culprits of this heavy SSD I/O. To make a long story short: we are aware of the problem, but fixing it for real requires completely re-architecturing Session Restore. That’s something we haven’t done yet, as Session Restore is rather safety-critical for many users, so this would need to be done very carefully, and with plent…
Earlier quoted context omitted.
Much of the recent breakage was to introduce essential features that users have been loudly asking for for years, such as multi-process support and content processes in a security sandbox. If you're intentionally running very old versions which by now have published exploits, then I can see that these are not things you would consider important.
Progress at what cost? Does maintaining security have to also mean breaking the systems that pay my bills?
Earlier quoted context omitted.
Much of the recent breakage was to introduce essential features that users have been loudly asking for for years, such as multi-process support and content processes in a security sandbox. If you're intentionally running very old versions which by now have published exploits, then I can see that these are not things you would consider important.
Progress at what cost? Does maintaining security have to also mean breaking the systems that pay my bills?