339678 - No way to recover session state if network unavailable at first startup

Status: RESOLVED WORKSFORME

(Firefox :: Session Restore, defect)

Description

[Mike Shaver (:shaver emeritus)]

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.

Comment 1

[Mike Shaver (:shaver emeritus)]

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

Comment 2

[Mike Connor [:mconnor]]

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.

Comment 3

[Darin Fisher]

Why does session restore depend on a functioning network?  Is the session data stored on the network?

Comment 4

[Darin Fisher]

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?

Comment 5

[Mike Connor [:mconnor]]

Yes.  We don't serialize the entire DOM, we store key information like URL, form data, and some JS object data, iirc. 

Comment 6

[Dietrich Ayala (:dietrich)]

Right, we'll pull from cache, else reload. When restoring from a crash, we must reload everything, b/c cache has been invalidated.

Comment 7

[Simon Bünzli]

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.

Comment 8

[Jeff Walden [:Waldo]]

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...

Comment 9

[Mike Connor [:mconnor]]

Putting this back to nomination to discuss/triage.

Comment 10

[Jeff Walden [:Waldo]]

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.

Comment 11

[Dietrich Ayala (:dietrich)]

(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.

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 13

[Wayne Mery (:wsmwk)]

(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?

Comment 14

[Simon Bünzli]

Fixing bug 345135 would be one possible solution to this issue.

Comment 17

[Michael Kohler [:mkohler]]

What should be done here?

Comment 18

[Dietrich Ayala (:dietrich)]

Is this still a bug? IIRC this was fixed long ago in a galaxy far far away.

Comment 19

[Wayne Mery (:wsmwk)]

(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

Comment 20

[Rares Doghi, Desktop QA]

Hi Wayne, is this still an issue with our latest Firefox builds ?

Comment 21

[Wayne Mery (:wsmwk)]

Has anyone else seen this in support or bug triage?

I'll have to test - it may be several days from now.

Comment 22

[Negritas Sergiu, Desktop QA]

Hello I have tried to reproduce the issue as described and it seems not to reproduce it anymore. The restore session is as mentioned in comment 19. I will reduce the severity of this issue. If you consider that the severity might be higher please feel free to revert the change.

Thank you and have a nice day!

Comment 23

[Wayne Mery (:wsmwk)]

Happy to agree it's resolved, based on Negritas' testing.