777272 - The Session Restore tab's list of windows/tabs is empty until the Session Restore tab is refreshed

Status: RESOLVED INCOMPLETE

(Firefox :: Session Restore, defect)

Description

[Jonathan Watt [:jwatt]]

I just crashed, and as it is want to do, Firefox (14 in this case) "lost" my session...or so it appeared. There were no windows or tabs listed - just an empty white area - and the restore button was disabled leaving only the start new session button enabled. On refreshing the Restore Session tab though, suddenly it was populated with my windows and tabs, ready to be restored!

This is pretty serious, and as far as most users are going to be concerned this bug is loss of their data, since almost none are likely to refresh the tab.

Comment 1

[Jonathan Watt [:jwatt]]

Given the seriousness of the impact on users' experience of Firefox of loosing their session, I think this should track firefox 17. Seems like maybe we at least need some sort of delayed logic to check "is the list of windows/tabs we're displaying consistent with what we have in our database"?

Comment 2

[Jonathan Watt [:jwatt]]

This just happened again, this time after having to force power-off my Mac.

Comment 3

[[e-mail] (:bhearsum)]

I may have hit this or something similar/related. I restarted my computer this morning and when Firefox opened it didn't restore my session. about:sessionrestore was empty, and I didn't think to refresh it before doing another restart. I ended up losing my session entirely, but I wonder if it would've been there had I refreshed about:sessionrestore.

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

This is a pretty serious user concern - putting qawanted in to get some reliable STR if possible. Johnathan can you provide the crash report from about:crashes that preceded this issue?

Comment 5

[Lukas Blakk [:lsblakk] use ?needinfo]

Given comment 0 I'm going to nominate this for tracking on 15/16 as well since we don't know yet if this is reproducible on those versions as well (comment 0 mentions being on FF 14).

Comment 6

[Jonathan Watt [:jwatt]]

(In reply to Lukas Blakk [:lsblakk] from comment #4)
> Johnathan can you provide the crash report from
> about:crashes that preceded this issue?

I didn't get a crash report for the actual crash, and naturally I didn't get one for the force-power-off either.

Comment 7

[Marcia Knous [:marcia]]

jwatt and bhearsum: I will try to reproduce this - are you both running on Mac, and also running with any addons?

Comment 8

[Jonathan Watt [:jwatt]]

Attachment: jwatt's enabled add-ons at time of dataloss

Yes, OS X 10.7, and here are my currently enabled add-ons (although they wouldn't be my first suspect in this case).

Comment 9

[:Gavin Sharp [email: [e-mail]]]

bhearsum, jwatt: are you both seeing this only in Firefox 14?

Comment 10

[[e-mail] (:bhearsum)]

I saw it on Nightly.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

I don't think we have enough information here (or enough reports of this being a problem) to usefully make progress for 15, so I'm not sure we need to track this there.

Comment 12

[Jonathan Watt [:jwatt]]

Regarding the "not enough reports" comment, note that virtually nobody is going to think to refresh the page, so direct reports are unlikely.

As far as "session restore is flaky in general" goes, consensus at the recent layout/gfx work week when session restore came up briefly in passing in a side discussion was that pretty much everyone has had it screw up on them, and not infrequently. (I got the impression it's pretty much accepted as having always been that way.) Getting an impression of how widespread the issue is may require a survey of some sort, or better yet some Telemetry work.

Comment 13

[u279076]

I've been trying with the crashme.xpi extension to try to force hitting this scenario but Session Store has worked as expected in every case. Removing qawanted due to my inability to reproduce this bug, the lack of reliable steps, and the sporadic nature of this bug. Please re-add qawanted if someone can provide more leads for QA to pursue or some steps to reproduce.

Comment 14

[Lukas Blakk [:lsblakk] use ?needinfo]

I agree with comment 11, we don't have near enough to go on and it's too close to 15 now to imagine we'd uncover the root issue of something this slippery in time. I'll file a bug on getting some telemetry data to try and help with investigating how wide-spread this is and will also mention this to SUMO since it couldn't hurt to have the tip about refreshing the page somewhere in our support documentation to help in case someone hits this more than once or if they access SUMO from another window with the session restore tab still open in another.

Comment 15

[Jonathan Watt [:jwatt]]

Just happened to me again, this time after having to hard reboot my Mac.

Comment 16

[u279076]

Comment 12 makes me wonder if we should put this on the 2013 radar as a product requirement. Trying to plug this and similar holes might be a fruitless effort. It may be more practical to do a complete tear-down of the Session Restore feature and rebuild it from the ground up.

Comment 17

[Wayne Mery (:wsmwk)]

(In reply to Jonathan Watt [:jwatt] from comment #12)
> ... virtually nobody is going to think to refresh the page, so direct reports are unlikely.

Yeah. I never did.  That said, I no longer see bug 699423 so I can't test.

Does anyone still see this?

Comment 18

[Jonathan Watt [:jwatt]]

It's been about a year for me. Hmm, which may mean it's about to happen again very soon...

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Have you seen this recently, Jonathan? I'm inclined to WFM the bug at this point if not.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Closing this as incomplete due to inactivity and lack of response from the reporter. Feel free to reopen the bug if the issue still reproduces on a current build.