Form text is lost when going back/forward in history - for example text in compose window




Document Navigation
15 years ago
2 years ago


(Reporter: pascalc, Unassigned)


(Blocks: 2 bugs, {dataloss, regression})

Windows XP
dataloss, regression
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(2 attachments, 1 obsolete attachment)



15 years ago
build 2003060908 WINXP

1 login to hotmail
2 click on compose, type a message in the compose form
3 click on groupmark
4 click on back button to ge back to your message

expected result : resume message writing
actual result : message was deleted

Comment 1

15 years ago

*** This bug has been marked as a duplicate of 209290 ***
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 2

15 years ago
Finally this bug is of a different nature, The problem also happens with normal
browsing and not only with groupmarks.  Reopening and changing summary to
reflect it.
Component: Tabbed Browser → Browser-General
Resolution: DUPLICATE → ---
Summary: - opening groupmark clears hotmail compose window → - text in compose window form isn't remembered if you browse back or forward in History.

Comment 3

15 years ago
I see this same bug with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b)
Gecko/20030611 Mozilla Firebird/0.6.

As stated in comment 2, you do not need to use groupmarks to trigger this bug;
navigating from and back to the page will erase the message text (and the rest
of the form as well: to, cc, bcc, subject)

(The Component should also probably be changed to History: Session or DOM HTML;
I'm not sure which)

Comment 4

15 years ago
FYI, the latest 1.4 branch build also has this bug.
Product: Browser → Seamonkey

Comment 5

13 years ago
Created attachment 168414 [details]
Example of problem using <textarea>

This attachment is based on code from
It shows that the bug is not related to javascript or some other complex
coding.  The bug occurs whenever a <textarea> tag is put inside of a table. 
(View the source to see.)

Steps to reproduce:
1) Enter some data into the <textarea>.
2) Go to another page.
3) Go back.

Information entered into the form is lost.

Comment 6

13 years ago
Created attachment 168415 [details]
Testcase: input fields inside of table

An update -- this includes an <input> filed and a <textarea>
In both cases the problem occurs whenever you put them inside of a table (see

Steps to reproduce:
1) Enter some data into the <textarea> and <input> fields.
2) Go to another page.
3) Go back.

Information entered into the form is lost.
Attachment #168414 - Attachment is obsolete: true

Comment 7

13 years ago
Suggested changes:

Summary -> Something to reflect the cause?  Like maybe the following?
"Form text is lost when going back/forward in history (when form fields are
inside of a table)."

Keywords -> testcase
Keywords -> top100  (does top100 apply to bugs that affect a site in any way or
just rendering problems?)

Note: here's my browser verison:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041209

Comment 8

13 years ago
Note bug 288462.


13 years ago
Blocks: 288462

Comment 9

13 years ago
More bugs will be duped aganist this one, as it has testcases.
Component: General → History: Session
Product: Mozilla Application Suite → Core
Summary: - text in compose window form isn't remembered if you browse back or forward in History. → Form text is lost when going back/forward in history

Comment 10

13 years ago
*** Bug 246692 has been marked as a duplicate of this bug. ***

Comment 11

13 years ago
*** Bug 263490 has been marked as a duplicate of this bug. ***
Er... the testcase attached to this bug worksforme.  Is anyone still seeing this

Comment 13

13 years ago
Testcase is WFM with latest trunk build on both Windows XP and Mac OS X. Also
tried steps in comment 0 but didnt find any groupmark link. 
Clicking on another link inside Hotmail and then back, makes the text go away.
But this happends in IE as well. 
Is the hotmail page sent with no-store HTTP headers or something?

Comment 15

13 years ago
I see this in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050406
GTK2+Xft build. In fact, all forms are reset to default when I go back to them.
Everything was working fine in 20050314 build.
That sounds like a different bug... Could you please file it, and cc me?

Comment 17

13 years ago
False alert - form filling works when going forward/back upon browser restart.
Sorry for bugspam.

Comment 18

10 years ago
I'm running Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080404 Firefox/ and can't reproduce the bug with the testcase in this bug.

FWIW, I haven't seen this problem in a while.  This bug can probably be resolved WORKSFORME.

On another note, in Firefox, Windows Live Hotmail does not warn you before navigating away from the 'compose' page, leading to dataloss if you don't save the draft beforehand.  IE7 pops up a warning alert.  Even adding to the Firefox allowed popup sites doesn't help.  /me goes off to hunt in bugzilla...


Comment 19

10 years ago
Pascal, gone for you also?
Assignee: jag → nobody
QA Contact: pmac → history.session

Comment 20

10 years ago
I've just tested firefox 3 beta 5 and seamonkey (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008051102 SeaMonkey/2.0a1pre

they both keep the message form at yahoo mail and windows live mail,
but both lose input fields on yahoo mail (To, Cc, Subject) and keep them on live mail.

Comment 21

10 years ago
Is this really not just a dupe of bug 288462?
Summary: Form text is lost when going back/forward in history → Form text is lost when going back/forward in history - for example text in compose window


10 years ago
Component: History: Session → Document Navigation
QA Contact: history.session → docshell

Comment 22

9 years ago
I ran into this when using the new toolbar for MediaWiki. When the toolbar is enabled, changes in the edit box are lost during back/forward. Try that at – write something into the textarea, press back/forward, and all changes are lost.

I tried to find the heart of the problem and managed to simplify it to two reproducibles: See and Unfortunately, even the first example exhibits this behavior only when jQuery is included, and I am not able to determine what specific feature of jQuery triggers the problem. Both examples feature cloning the textarea when moving it inside a div. When the node is not cloned, everything begins to work correctly. The second example adds an input control above the textarea (which is also the case with the MediaWiki toolbar).

Comment 23

9 years ago
I can confirm both testcases presented in comment #22.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)
John, any idea which part of jquery could be hooking into the calls in that first test from comment 22?
Oh, I bet it comes in by starting layout earlier and thus forcing form state restoration before the clone.  Note that cloning does NOT clone form state.
I also seriously doubt that comment 22 is in any way related to this bug as originally filed, since said original filing predates the existence of jquery by 2 years...

Comment 27

7 years ago
I can't reproducte this bug with given testcase in Firefox 6.

Comment 28

7 years ago
(In reply to Vova Olar from comment #27)
> I can't reproducte this bug with given testcase in Firefox 6.

I can; both test cases at comment #22 still exhibit the described behavior. (Mozilla/5.0 (Windows NT 6.0; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0)

Comment 29

7 years ago
In that case Title should be changed to something like this: "Text in dynamically created forms is lost when going back/forward in history". Because with static HTML all works forme.

Comment 30

7 years ago
testcase #22 still confirmed on Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20100101 Firefox/7.0

I do get however a dialog window like this on hotmail compose window:

"This page is asking you to confirm that you want to leave - data you have entered may not be saved."

Comment 31

7 years ago
in the meantime i got enough of this and installed the lazarus form recovery extension which works for testcases #22 too, except the title in the second testcase

Comment 32

7 years ago
Created attachment 566289 [details]
Includes tests for jquery resetting textarea element on window unload

This bug is specific to jQuery1.3.2 or earlier, which resets the textarea on window unload. At least an input element must be inserted by js before the textarea in order to observe the behavior.


7 years ago
Attachment #566289 - Attachment mime type: text/plain → text/html

Comment 33

6 years ago
Just hit this bug on with Firefox 8.0.1 after somehow accidentally navigating away in the same tab to look something up.

Is this bug specifically for dynamic forms, not static forms?  How can a user distinguish?  Should I leave this comment on a different bug?
This bug, as filed, is specifically about hotmail.  If you see an issue on a different site, it's best to file a new bug with clear steps to reproduce.

Comment 35

6 years ago
The title of this bug is misleading - it indicates hotmail as an example, - please make it clear that it is not an example.  Is there an existing bug for this problem in general?


6 years ago
Blocks: 718249

Comment 36

6 years ago
For the general case, see bug 718249
Firefox: 45.0.1, Build ID: 20160315153207
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:45.0) Gecko/20100101 Firefox/45.0

Hi Pascal, 

I have tested this issue on the latest Firefox (45.0.1) release, latest Nightly (48.0a1 - Build ID: 20160324153548) build. It seems that Hotmail has changed to Outlook, so I have tested this using I composed a new message and when I navigated to another site, I got this message: "This page is asking you to confirm that you want to leave - data you have entered may not be saved". 
I have also tested with the provided test cases from comment 6 and comment 32, but I could not reproduce it. The written message is not lost when navigating to other pages and returning back. 

Is this still reproducible on your end ? If yes, can you please retest this using latest Firefox release and latest Nightly build ( and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause ( 

Flags: needinfo?(pascalc)

Comment 38

2 years ago
Confirmed fixed on Nightly with Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
Last Resolved: 15 years ago2 years ago
Resolution: --- → FIXED


2 years ago
Flags: needinfo?(pascalc)

Comment 39

2 years ago
afaict there is no patch identified with "fixing" this bug. so resolution should be worksforme
(what about bug 718249? )
You need to log in before you can comment on or make changes to this bug.