3 ms·
And while I'm on the topic of offline pages, let me add another rant: As far as I know all Android browsers, including Firefox, keep commiting the cardinal sin
by morsch 6y ago
And while I'm on the topic of offline pages, let me add another rant: As far as I know all Android browsers, including Firefox, keep commiting the cardinal sin of computer applications. They lose user data.
I cannot count how often I returned to the browser only to find a previously loaded page reloading. Good luck with that if you're temporarily in a dead spot.
Of course most of the time you aren't, but the browsers still lose your data, namely the scroll position. This makes these programs that are, to a first approximation, document display tools eminently useless for displaying documents longer than 140 characters.
Even when Firefox had an offline reader mode - built to read longer documents and with complete control over js and rendering - the scroll position was never persisted. I resorted to copy pasting a sentence to a notepad and using Find in page to resume reading. Ridiculous.
And that's not even mentioning form content and other more application-y state.
Of course I know it's an Android thing; apps don't get to hold on to stuff. So store everything to disk. I'll reload it when I'm good and ready. My podcast app doesn't restart the episode from scratch if I leave it stopped in the background for 5 minutes. I'm sure there are a thousand edge cases, but there's very little evidence of fixing even the simple path.
Imagine a desktop browser pulling shit like that. Again, not just a Firefox issue, from what I can tell none of the vendors think this is important.
- iggldiggl 6y ago> but the browsers still lose your data, namely the scroll position. [..] > Imagine a desktop browser pulling shit like that. Again, not just a Firefox issue, from what I can tell none of the vendors think this is important. A bug for storing the current scroll position at all was opened shortly after the release of the 2nd generation Firefox for Android (which is the one that's being replaced now, the 1st generation being the attempt to use a XUL/JS interface on mobile as well, which led to horrible performance problems), and then remained open for 3½ years – at which point it was only fixed because I personally was getting fed up enough about it. So there might be something to that observation… session restoring originally had a number of other annoying bugs as well, one of which had amassed half a dozen duplicate bug reports, but still didn't get much in the way of official attention [1]. On the flip side it did get me contributing to Firefox for quite some time, which was a nice experience, but on the other hand it does make me a bit apprehensive how long some of those lost features and UX regressions will potentially remain that way… I'm mildly curious about the reader mode issues, though. While I never used reader mode much and so never extensively tested it, I do remember writing some code to handle reader mode as well – on the other hand I guess it doesn't matter much now any more what with the old codebase being shunted away into the sidings for good… [1] Maybe it's because commercial developers (which includes the fulltime Mozilla staff, since they are being paid for working on the browser) tend use more expensive phones that are less memory-constrained and hence run into session restoring problems less often? Who knows…