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

*** This bug has been marked as a duplicate of 209290 ***

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.

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)

FYI, the latest 1.4 branch build also has this bug.

This attachment is based on code from hotmail.com 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. Result: Information entered into the form is lost.

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 code). Steps to reproduce: 1) Enter some data into the <textarea> and <input> fields. 2) Go to another page. 3) Go back. Result: Information entered into the form is lost.

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 Firefox/1.0+

Note bug 288462.

More bugs will be duped aganist this one, as it has testcases.

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

*** Bug 263490 has been marked as a duplicate of this bug. ***

Er... the testcase attached to this bug worksforme. Is anyone still seeing this issue?

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?

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?

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

I'm running Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 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 live.com to the Firefox allowed popup sites doesn't help. /me goes off to hunt in bugzilla... David

Pascal, gone for you also?

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.

Is this really not just a dupe of bug 288462?

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 http://usability.wikimedia.org/wiki/Project:Sandbox?action=edit – 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 http://mormegil.info/firefox/testhistory1.htm and http://mormegil.info/firefox/testhistory2.htm 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).

I can confirm both testcases presented in comment #22. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.2) 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...

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

(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)

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.

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."

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

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.

Just hit this bug on http://www.varsitytutors.com/tutoring-jobs 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.

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?

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 Outlook.com. 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 (https://nightly.mozilla.org/) 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 (https://goo.gl/PNe90E). Thanks, Cosmin.

Confirmed fixed on Nightly with Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0

afaict there is no patch identified with "fixing" this bug. so resolution should be worksforme (what about bug 718249? )