522625 - session restore may need to handle faststart "shutdown" on Windows CE

Status: RESOLVED WONTFIX

(Firefox :: Session Restore, defect, P1)

Description

[Justin Dolske [:Dolske]]

Our Windows CE builds of Firefox include a faststart component (bug 509249) so that when the last browser window is closed (with [X], not File->Exit), Firefox actually remains in memory with no windows open.

If I kill the process at this point (or, presumably, the OS crashes), the next browser startup triggers the "Well this is embarrassing" session restore page.

I think we just need to have session restore catch this form of "shutdown" and transition to STATE_QUITTING (or something like that).

Comment 1

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

We have some sort of mechanism in place actually, for handling the "oh crap I left the downloads window open" case. It'll probably need a bit of tweaking for this case specifically.

See bug 354894.

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

The suggestion was made by shaver to just disable session restore on these devices -- it's often not what you want anyway after a crash (restoring everything).

Comment 3

[Justin Dolske [:Dolske]]

Zpao - if this is easy can you whip up a patch?

Comment 5

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to comment #2)
> The suggestion was made by shaver to just disable session restore on these
> devices -- it's often not what you want anyway after a crash (restoring
> everything).

Disable completely? Or just the crash recovery mechanism?

I'm not sure it'll be possible to disable completely. Well, it's possible, but other things use it. I know Private Browsing uses it to save/restore state going in & out of PB mode. Sessionstore also updates the current URL that crash reporter reports. We'd also have to make changes to Preferences, History Menu (undo close window/tab), shutdown logic. We'd have to make some substantial changes to make this happen and look right. It'd be less work to disable it and just ignore the misleading UI left over.

Disabling just the crash recovery is better scoped. It'll still involve a bit of work. Essentially, we'd only write to disk on quit - that should eliminate the need to make any crash check changes since we'd only see good states on startup.

(In reply to comment #3)
> Zpao - if this is easy can you whip up a patch?

I can work on this. Depending on what we actually want to happen here it might be easy. I can do some locally but I'll need to jump on a board to play with the faststart stuff.

In related sessionstore news, I'll probably work on bug 524178 which should help somewhat with startup on these devices.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Isn't it just a matter of setting "browser.sessionstore.resume_from_crash" to false?

Comment 7

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to comment #6)
> Isn't it just a matter of setting "browser.sessionstore.resume_from_crash" to
> false?

... yes. Forgot about that pref & didn't look at the code to back up my answer :/

Comment 8

[Justin Dolske [:Dolske]]

Attachment: Temporary Patch v.1

This patch flips the pref, guess we can leave this bug open to implement a better fix later.

Comment 9

[Justin Dolske [:Dolske]]

Pushed http://hg.mozilla.org/mozilla-central/rev/8763e9cd419c

Comment 10

[Justin Dolske [:Dolske]]

Doh, meant to leave this open for the better long-term fix.

Comment 11

[Justin Dolske [:Dolske]]

Pushed to 192: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/bf14fab682dc

Comment 12

[Doug Turner (:dougt)]

This year we mothballed windows mobile development.  See:

  http://blog.pavlov.net/2010/03/22/stopping-development-for-windows-mobile/

Marking bugs in the windows mobile / windows ce bucket as WONTFIX.