Open Bug 339678 Opened 15 years ago Updated 7 years ago
No way to recover session state if network unavailable at first startup
When restarting my browser after a crash (OS or application), I'm unable to restore the session if the network isn't around (possibly transiently). This could also arise in the case in which we restart for an update and are blocked in our new form by firewall/AV software. (Or where the network requires some sort of login, as is common in hotels and many wireless networks.) We should be able to restore that session once the network is available.
15 years ago
Some ways we could detect this: - load two unrelated URLs, and see if they get redirected to the same place - load a known-will-not-resolve hostname and see if we get a page loaded (though this could also give us a false positive for the working-proxy case, so we shouldn't do it on its own) Other cases in which we might want to do this: - checking for extension updates at new-version startup - checking for app update
Ok, so what we really need is an extension of the new offline/online detection that can detect whether you need to auth through a proxy. Shaver suggested using something known to not redirect, and perhaps a bogus domain that doesn't resolve, and see if they redirect to the same place, which would indicate some additional action is required. We also need something like this for checking for extension updates on startup (i.e. after upgrades) and I'm sure there's other consumers that would make use of it. ccing darin/biesi/sayrer to see if they can lend a hand here.
Flags: blocking-firefox2? → blocking-firefox2+
Why does session restore depend on a functioning network? Is the session data stored on the network?
Oh, is it that some of the web-pages that were part of the saved session are not persistently stored such that they need to be re-downloaded?
Yes. We don't serialize the entire DOM, we store key information like URL, form data, and some JS object data, iirc.
Right, we'll pull from cache, else reload. When restoring from a crash, we must reload everything, b/c cache has been invalidated.
Right: the cache will fail however for https sites, after crashes (see your bug 105843) and when its size limit is reached. These pages will be restored from the web. Note that the session information is preserved after a crash until the next clean shutdown/startup (whatever comes first). As a work-around to this issue, saving the file sessionstore.bak from the profile, closing Firefox and copying that file back as sessionstore.ini will currently allow to recover the session again.
There seem to be ~3 separate things requested here: make sessionstore handle restarting after a crash with no network connection, add networking API to determine whether network access is occurring through a proxy that prevents access to actual websites (such as those used by airport wireless services that never mention the extortion fees until you try to use them), and make sessionstore use that new API. The first doesn't look complicated -- I'll guesstimate a day. I'm unsure how long the second would take given that I've barely looked at that section of netwerk -- maybe 4 days to implement a resolve-two-addresses approach? Once the first and second are implemented, the third should fit in fairly obviously. Anyway, I'll probably do more looking through sessionstore to figure out the first over the weekend. The latter two will wait until I've figured that out. Self-assigning...
Status: NEW → ASSIGNED
Putting this back to nomination to discuss/triage.
Flags: blocking-firefox2+ → blocking-firefox2?
The thing that most has me stymied about this is how we handle cases where the user does more than just start up network-less after a crash and immediately close. Do we save the previous state if a network connection appears? What about if the network appears, the user browses, and then the network goes away? How about if the user restarts, the network appears, the user does no browsing, and then the network disappears and Firefox closes? These issues make the problem more complicated than I initially envisioned it.
(In reply to comment #10) > The thing that most has me stymied about this is how we handle cases where the > user does more than just start up network-less after a crash and immediately > close. Do we save the previous state if a network connection appears? What > about if the network appears, the user browses, and then the network goes away? IMO this bug is only about restoration at startup. Handling mid-session network drops should be a new bug. That said, a solution might be to not overwrite stored data if we get server-not-found, etc. > How about if the user restarts, the network appears, the user does no > browsing, and then the network disappears and Firefox closes? These issues > make the problem more complicated than I initially envisioned it. In this scenario, the data is culled from the already-loaded windows and tabs, so nothing is lost unless a page is refeshing on it's own, etc.
1.8.1 drivers: this is a nice to have; the important thing is to fail cleanly and if the network is missing try to pull from cache or render the pages with "unable to contact server" errors or whatnot. We'd take a patch, but aren't going to block release on it.
Flags: blocking-firefox2? → blocking-firefox2-
(In reply to comment #12) > 1.8.1 drivers: this is a nice to have; not sure what you mean by nice to have. for those that encounter this, isn't it a DATALOSS issue?
Assignee: jwalden+bmo → nobody
Status: ASSIGNED → NEW
Component: Tabbed Browser → Session Restore
QA Contact: tabbed.browser → session.restore
Target Milestone: Firefox 2 beta1 → ---
Fixing bug 345135 would be one possible solution to this issue.
What should be done here?
Is this still a bug? IIRC this was fixed long ago in a galaxy far far away.
(In reply to Dietrich Ayala (:dietrich) from comment #18) > Is this still a bug? IIRC this was fixed long ago in a galaxy far far away. Current trunk behavior ... startup with network connection disabled, pages have title: Problem loading page contents: "Server not found", with a button for "try again" If I bring network connection up and "try again" then page is reloaded with form data (at least for what I tested, which is bugzilla) Is that the recovery method? If not, what should the recovery method be - other than somehow letting me use sessionrestore.bak? bug 450711 addresses comment 11
Severity: major → critical
You need to log in before you can comment on or make changes to this bug.