345135 - Session restore shouldn't throw away form data even if there's no form on the page to restore the data into

Status: NEW

(Firefox :: Session Restore, enhancement)

Description

[Nickolay_Ponomarev]

Consider this situation:
1. User types a long post into a text area on a forum, which disallows guest posting.
2. For whatever reason Firefox crashes
3. When user restarts Firefox his session on that forum is expired, and since the forum disallows guest posting, the loaded page doesn't have a textarea in it. [Alternatively, the page with the textarea is on a page loaded from post-data]
4. User logs into the forum again, but the post he typed is gone.
5. User is frustrated and tells himself once again to never write long posts in Firefox.

(User may be savvy enough to restore the lost text from sessionstore.bak, but I wasn't the several times it happened to me.)

Session store should provide a user-visible way to restore the typed text easily. It could be implemented as a notificationbox on the affected tabs. Bonus points for letting user re-login and filling the form - once a sufficiently similar page is loaded into the tab - from the session store data.

Comment 1

[Simon Bünzli]

One possible plan for implementing this once bug 346337 is fixed:

1. On SSTabRestored collect all form data that couldn't be restored.

2. If there is any (possibly at least one missing text field), display a notification bar:
-----------------------------------------------------------------------------
 /!\  Some data could not be restored completely.  [Try Again][Show Data][X]
-----------------------------------------------------------------------------

3. When the user hits Try Again, we go through the data again and try to fill in as much as possible, discarding used data. The notification bar remains open, as long as at least one text field still hasn't been filled.

4. If the user hits Show Data instead, we present him/her with all the text data we've collected (and possibly a hint as to what field it might have belonged to - as far as we can tell). This could happen in form of a dialog, a page overlay, a new page or a temporary file opened in the default text editor. This form is yet to be decided. Alex: Suggestions are welcome!

Note: While we will save all form data, we only save an internal link to the fields and the fields' values, so we can't really present the user with the fields' names.

We could try additionally collecting the innerText of the <label>s belonging to fields where they exist (which is far from everywhere), but even then I'm not sure whether the facts that the radio "Leave as NEW" was selected, that the checkbox "Remove selected CCs" was not and that "Product" 10/"Firefox" was selected, etc. will be useful when not restored for this specific page...

Comment 2

[Simon Bünzli]

Attachment: extension (somewhat) implementing the described behavior

This is a newer version of the extension from bug 448976 which now also somewhat implements the behavior described in comment #1 for experimentation and feedback.

This implementation displays a notification bar when text data couldn't be restored (e.g. because you've gone offline during a restart or because you've deleted a file containing form data) and lets you restore it once you're back at the page or at least view it (currently in the internal source viewer).

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

Comment on attachment 335199 [details]
extension (somewhat) implementing the described behavior

ui-r+ with the following changes:

One thing I think I forgot to mention was that mconnor wanted this content area message displayed if the crash occurred more than 24 hours ago (under the assumption that the user may want to just start a fresh session).

Here are some suggested string changes:

-Title case for "Your Last Minefield Session Closed Unexpectedly"

Trying to shorten the text a little, remove the word "crash" and added a direct apology:

--------------------------------------------------------------------
You can restore the tabs and windows from your previous session, or start a new session if they are no longer needed.  Our apologies for the inconvenience.
--------------------------------------------------------------------
If Minefield closes repeatedly:
* Try disabling any recently added extensions in the Add-ons Manager.
* Try restoring your session without any Web pages you suspect might be causing the crash:

[list view]

-removed "uncheck the tabs that you don't want to restore" since this should be self explanatory, and is referenced in the second bullet

-----------------------------------------------------------------------------
 /!\  Some data could not be restored completely.  [Try Again][Show Data][X]
-----------------------------------------------------------------------------

Perhaps say "information" instead of "data" or "your information" to imply that it was things that the user typed.

>This could happen in form of a dialog, a
>page overlay, a new page or a temporary file opened in the default text editor.

A new tab seems like the best way to go, since we don't want to navigate them away, give them a modal popup, or invoke any external applications (possible security concerns?). I would use the content area message style, with the information icon and the user's data placed into an editable text field so that they know they can select and copy it, and it visually resembles the information they lost.

Comment 4

[Alex Faaborg [:faaborg] (Firefox UX)]

>but even then I'm not
>sure whether the facts that the radio "Leave as NEW" was selected, that the
>checkbox "Remove selected CCs" was not and that "Product" 10/"Firefox" was
>selected, etc.

yeah, I don't think the main thing we want to save is data that is hard for the user to recreate, like a long blog post.  Also, exposing the field names would break the implementation model / interface model boundary.

Comment 5

[Simon Bünzli]

Thanks for the review, Alex. A few further questions WRT this specific bug:

(In reply to comment #3)
> A new tab seems like the best way to go [...] I would use the content area
> message style, with the information icon and the user's data placed into an
> editable text field so that they know they can select and copy it
(In reply to comment #4)
> Also, exposing the field names would
> break the implementation model / interface model boundary.

I'm not quite sure what exactly you imagine that the new tab with the restored data should look like. A design mock-up, e.g. for the following data snapshot taken from this very page, would help a lot.

#short_desc: "Session restore shouldn't throw away form data even if there's no form on the page to restore the data into",
#keywords: "dataloss, helpwanted, uiwanted",
#qa_contact: "[e-mail]",
#comment: "(In reply to comment #3)\u000a> A new tab seems like the best way to go [...] I would use the content area\u000a> message style, with the information icon and the user's data placed into an\u000a> editable text field so that they know they can select and copy it..."

The first three of these don't contain line breaks and less than say 128 characters and could thus be presented in single-line text boxes whereas the #comment will surely need a textarea (of how many visible lines?).

And should the notification bar hide itself once this new tab has been created or should it remain so that the user could still have Firefox fill in all that data into the correct page once s/he gets back to it later?

Comment 6

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Information the user created in a content area message

>I'm not quite sure what exactly you imagine that the new tab with the restored
>data should look like. A design mock-up, e.g. for the following data snapshot
>taken from this very page, would help a lot.

A mockup is attached

Comment 7

[Jason Spiro]

(In reply to comment #0)
> Bonus points for letting user re-login and filling the form - once a
> sufficiently similar page is loaded into the tab - from the session store data.

If you could do that, that would be ideal.

(In reply to comment #6)
> A mockup is attached

If you can't reach Nickolay's ideal, then I think Alex's idea of a restored-data tab is the best alternative.  It helps all users, even those who ignore the Information Bar, by giving the restored data its own tab.

May I suggest that you make the restored-data tab be the active tab, so that even inexperienced users who ignore the tab bar can benefit from it.