Closed Bug 522625 Opened 12 years ago Closed 11 years ago
session restore may need to handle faststart "shutdown" on Windows CE
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).
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.
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).
Priority: -- → P1
Zpao - if this is easy can you whip up a patch?
Assignee: nobody → paul
(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.
Isn't it just a matter of setting "browser.sessionstore.resume_from_crash" to false?
(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 :/
This patch flips the pref, guess we can leave this bug open to implement a better fix later.
Attachment #409250 - Flags: review?(vladimir)
Attachment #409250 - Flags: review?(vladimir) → review+
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Doh, meant to leave this open for the better long-term fix.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: --- → Firefox 3.7a1
Attachment #409250 - Flags: approval1.9.2? → approval1.9.2+
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.
Status: NEW → RESOLVED
Closed: 12 years ago → 11 years ago
Resolution: --- → WONTFIX
Whiteboard: [nv] → mothballed
You need to log in before you can comment on or make changes to this bug.