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

Status: RESOLVED WORKSFORME

(Core :: DOM: Navigation, defect)

Description

[Pascal Chevrel:pascalc]

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

[Hermann Schwab]

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

Comment 2

[Pascal Chevrel:pascalc]

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.

Comment 3

[djk]

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

[djk]

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

Comment 5

[Kevin Ar18]

Attachment: Example of problem using <textarea>

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.

Comment 6

[Kevin Ar18]

Attachment: 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
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.

Comment 7

[Kevin Ar18]

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+

Comment 8

[Daniel B.]

Note bug 288462.

Comment 9

[Robin Monks]

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

Comment 10

[Robin Monks]

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

Comment 11

[Robin Monks]

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

Comment 12

[Boris Zbarsky [:bzbarsky]]

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

Comment 13

[José Jeria]

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. 

Comment 14

[Boris Zbarsky [:bzbarsky]]

Is the hotmail page sent with no-store HTTP headers or something?

Comment 15

[kmike]

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.

Comment 16

[Boris Zbarsky [:bzbarsky]]

That sounds like a different bug... Could you please file it, and cc me?

Comment 17

[kmike]

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

Comment 18

[djk]

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

Comment 19

[Wayne Mery (:wsmwk)]

Pascal, gone for you also?

Comment 20

[costinel]

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

[Wayne Mery (:wsmwk)]

Is this really not just a dupe of bug 288462?

Comment 22

[Petr Kadlec]

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

Comment 23

[costinel]

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)

Comment 24

[Boris Zbarsky [:bzbarsky]]

John, any idea which part of jquery could be hooking into the calls in that first test from comment 22?

Comment 25

[Boris Zbarsky [:bzbarsky]]

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.

Comment 26

[Boris Zbarsky [:bzbarsky]]

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

[Vova Olar]

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

Comment 28

[Petr Kadlec]

(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

[Vova Olar]

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

[costinel]

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

[costinel]

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

[Ufku]

Attachment: 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.

Comment 33

[Shad Sterling]

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?

Comment 34

[Boris Zbarsky [:bzbarsky]]

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

[Shad Sterling]

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?

Comment 36

[Shad Sterling]

For the general case, see bug 718249

Comment 37

[Cosmin Muntean [:cmuntean], Ecosystem QA]

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.

Comment 38

[Pascal Chevrel:pascalc]

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

Comment 39

[Wayne Mery (:wsmwk)]

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