391814 - Text in TextArea and Input elements should be saved on page load to prevent data loss

Status: RESOLVED FIXED

(Firefox :: Session Restore, defect)

Description

[Michael Kraft [:morac]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6

Currently SessionStore clears out a tab's text saved data (__SS_text variable) when the tab loads.  It then saves the tab's text data any time there is a change to the textarea or input (of type text) element.  

I realize that the SesssionStore code is trying to be efficient such that is won't save input or textarea text unless the user actually types something into that field, which is good.  The problem occurs on sites with a preview function that pre-populates a user's typed text into the fields.  Once the page loads, SessionStore will clear out the __SS_text variable and if the browser crashes or restarts, the previously typed in text is lost which is completely unexpected.  

The problem is made worse if there are lots of text input/areas.  In this case say there are 5 fields and the user types 100 words in 5 of the fields and the previews the page and then makes a few changes to the 5th field and saves the page.  Well only the 5th field will be saved since the first 4 fields never changed since the page loaded.

Also because the _saveTextData function is not called from with the _collectWindowData function (or any function other than sss_onTabInput), the data will also be lost if the user closes the tab, closes the browser or saves the session using an extension that calls the getBrowserState function.  

This can be worked around by enabling the saving of POSTDATA, but there are dangers with having that enabled and the recommended and default settings are to not save POSTDATA.  So by default the textarea data will be lost in this case.


There are a few changes that would be useful here:

1. Call _saveTextData for each non-empty textarea in the page from within sss_onTabLoad.  .

2. Call saveTextData for each non-empty textarea in the page either from within _updateTextAndScrollData or from it's callers.  It seems like if the test and scroll data is being retrieved and stored, it should also retrieve the textarea data as well.

I'm not sure how much of a performance hit either of these would be, but then the textarea pre-filled in data wouldn't be lost if the user doesn't modify the text before saving or crashing.

Reproducible: Always

Steps to Reproduce:
1. Go to www.google.com
2. Search for a term so you get a result page.
3. Type in a search term (the text input with id of "q" will be saved).
4. Click to search.
5. Notice on new result page that the text entered in step 3 is in the "q" text input box.
Actual Results:  
Text in "q" is not saved in session. (ie: __SS_text for q is null)

Expected Results:  
The search term in the text box should have been saved this there is text in the input text box.

Comment 1

[Michael Kraft [:morac]]

I just remembered that there might be hidden text input boxes on the page.  I supposed they could be ignored, but usually they are needed in order to post on the page so it might be good to save them as well.  Then again they might not be needed as long as the user's text is still there.

Comment 2

[Simon Bünzli]

(In reply to comment #0)
> 1. Call _saveTextData for each non-empty textarea in the page from within
> sss_onTabLoad.

Sounds like a reasonable plan, although we should probably only do this for pages requiring POSTDATA and when the .postdata pref isn't set to -1.

> 2. Call saveTextData for each non-empty textarea in the page either from within
> _updateTextAndScrollData or from it's callers.

That would be unnecessary if we did it once onLoad, wouldn't it? The only reason to call saveTextData is when some of it is actually changed, which should really only happen onInput and (per this bug) onLoad.

(In reply to comment #1)
If we do this, we should do it for everything which would be saved otherwise (which currently includes hidden elements): <textarea>, <input type="text"> and <input> without any type="..." -- though all of them only when the have either id="..." or name="..." set.

Comment 3

[Michael Kraft [:morac]]

(In reply to comment #2)
> Sounds like a reasonable plan, although we should probably only do this for
> pages requiring POSTDATA and when the .postdata pref isn't set to -1.
> 
We may want to do it even if the .postdata pref is -1 since when the page is loaded it isn't automatically refreshed so from the user's standpoint the text would be lost, even though he could (theoretically) just reload the page to get it back (barring any server side sessions timing out).  

Though ever since someone told me that Firefox saved the entire contents of an entire POSTDATA encoded file that he uploaded to Cisco resulting in a 4.5 MB sessionstore.js file, which basically prevented him from loading Firefox, I've come to doubt the sanity of ever allowing .postdata pref to be set to -1, but that's another issue.  http://forums.mozillazine.org/viewtopic.php?p=2964092#2964092

> That would be unnecessary if we did it once onLoad, wouldn't it? The only
> reason to call saveTextData is when some of it is actually changed, which
> should really only happen onInput and (per this bug) onLoad.
> 
Yes I realized later on that that would be redundant.


> (In reply to comment #1)
> If we do this, we should do it for everything which would be saved otherwise
> (which currently includes hidden elements): <textarea>, <input type="text"> and
> <input> without any type="..." -- though all of them only when the have either
> id="..." or name="..." set.
> 

Makes sense to me.

Comment 4

[Simon Bünzli]

FIXED in bug 346337.