133946 - (hhhh) Form state restoring is not working with framesets on reload [OLD: Form elements are wiped....]

Status: RESOLVED WORKSFORME

(Core :: DOM: Navigation, defect)

Description

[Brian Hunt]

In any form, clicking reload, or going to web page accidentally and going "back"
to that web page will render all user input into that form non-existent.

That contradicts a fundamental rule of human-interface design: if the user types
it in, it has value.  The longer the user is doing it, the more value it has -
some non-volatile system of form input persistence would be worthy of
consideration ... "later".  Fixing the immediate problem of loss of data at a
single keystroke is of pivotal import.

Form data should never be wiped at a whim - hitting ctrl-r (which happens to be
next to ctrl-t for tabs) should not destroy an hours worth of email.  Yet it
seems to.

This bug is the source of *enormous* frustration for me.  You cannot imagine how
difficult it was to write this bug report without cursing and swearing. :/

Comment 1

[Frederic Bezies]

Which build are you using ? I tried reloading a page (this one), and the text I
typed wasn't lost after a reload !

Comment 2

[Waheed Islam]

humm, I thought this worked quite well for me.
until I just tested it, aggressively.

It's either intermittent or form data is lost on a page with frames Only.

build: 20020327, win95.

test site: http://www.mrc-gprf.ac.uk/contact_frameset.html

Comment 3

[Valerio Capello]

Confirmed on v0.9.9+ build 2002032708 win98 on test page with frames as in
comment #2

Comment 4

[Brian Hunt]

Using build 2002032708.

Yes, the data loss on reload (or new-page + 'back'), as I encountered it, was
inside a frameset.  Impressive job in figuring that out. :)

This occurs on Linux and Windows alike, so I am flagging OS: All

Comment 5

[Waheed Islam]

marking new.

this directly clashes with bug 46845 [clear form upon page refresh].

Comment 6

[Valerio Capello]

In order to avoid a religion war, I'd say that a plain reload would keep the
text in the forms, while a SHIFT+reload (that normally would reload the whole
page ignoring the cache) would regenerate a fresh page with all the fields empty.

Comment 7

[Alexandru Savulov]

*************************
frameset vs. single frame
*************************

ok, looks like there is a problem on frameset pages. if the above URL is loaded,
you type in the form fields and hit CTRL+R the fileds get wipped out. but if you
rightclick the form frame and chose "show only this frame", then you do the
same, the content is not removed. i tried that even with pages that have initial
values set and is still working, the typped value are not forgotten. we must fix
this for framesets.

anyone that saw this on non-frameset pages please tell us which build/os/URL.

Comment 8

[Brian Hunt]

The refresh/reload issue is simple enough: user types in data, and erases it
unwittingly with a single keystroke. That's fundamentally wrong, a source of
frustration, and a design flaw.  An application should have state of at least a
single depth to return to.

Second, an issue not addressed herein is the clicking on a link, presumably
accidentally, then hitting the back button, yields an empty field.  That is
similarly fundamentally wrong, and a poor design choice. (Not sure if mozilla is
designed with that in mind.)

Third, I can reproduce the refresh issue on a non-frameset in Mozilla with the
squirrel mail compose window (by opening the link from a frame in a new tab --
does that change the state of the frame to be equivalent to frameless?).  I have
conjured up this problem on the intranet, but the best I can offer for
reproduction is the location of squirrel mail: http://www.squirrelmail.org/. 
This might be mitigated by the opening of the link in a new tab/window, however.

Fourth, to the average user, this would be a source of insurmountable
frustration.  It has personally cost me $240 in lost hours, in the past 24
hours, due to hitting C-r instead of C-t and accidentally tapping the touchpad
so it went to a link and lost all my data since the "back" button didn't retain.

So, by design or otherwise, the easy (ie one key or one mouse click) loss of
data threatens the "safety" of the data I type into the browser.

Comment 9

[Alexandru Savulov]

i checked the following URL:

http://www.squirrelmail.org/feedback_form.php

the response header from server contains:
  Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
  Pragma: no-cache

i tried to emulate the same with my test server (setting the same header fields)
and i couldn't reproduce (although I use the same server/PHP versions as
sourceforge).

testing...

Comment 10

[Alexandru Savulov]

ok, with the original page from my server I was able to reproduce.

********************
TEST WITH THIS URLs:
********************
- on a normal page
http://www.squirrelmail.org/feedback_form.php

- on a frameset page
http://www.mrc-gprf.ac.uk/contact_frameset.html

Comment 11

[Alexandru Savulov]

ok, here are the results:

on the URL

http://www.squirrelmail.org/feedback_form.php

the Cache-Control: no-store flag in the server's response header causes the
content to be deleted and is NOT A BUG.
(see HTTP 1.1 - RFC 2616 / sec. 14.9.2)

the only issue remaining here is visible on the URL

http://www.mrc-gprf.ac.uk/contact_frameset.html

and is a frameset problem.

Reassigning to Jkeiser since he's the state recovery agent ;-)

Comment 12

[Brian Hunt]

------- Additional Comment #11 From Alexandru Savulov 2002-03-29 11:01 -------
...
the Cache-Control: no-store flag in the server's response header causes the
content to be deleted and is NOT A BUG.
(see HTTP 1.1 - RFC 2616 / sec. 14.9.2)
...

It is reasonable to believe, given that I have been driven to rage enough times
to post here, that many users will be frustrated beyond reason by hitting ctrl-R
to refresh a page and have Mozilla destroy hours of work without a hesitation. 
The words "Destroy" and "work" highlighting the most operative consequences of
not addressing this, albeit minor in most cases now, issue. :)

A confirmation that the user will lose all their form data when they hit c-r
would be a sufficient fix, allowing Mozilla to remain standards compliant, and
nevertheless stave off ignoring fundamentals of human interface design and the
impotent wrath of bitter and cynical computer users such as me.  Plus, it should
be a relatively trivial fix to ask "This page requires that you will lose
everything you just typed in to refresh" prior to refreshing.

The frameset issue is a different beast altogether.

Comment 13

[Alexandru Savulov]

reporter:
please file a new bug to User Interface Design for the message box improvement.
they have to decide if the feature is implementable or not since the events
fired by c-r and mouse-click are the same from the perspective of form submission.

thanks!

Comment 14

[Jon Hall]

Of course this if "fixed" just further destroys javascript in forms and
perpetuates the dataloss problems talked about in bug 46845 
But I guess Mozilla should be consistent in making sure javascript isn't used in
forms at all. Then again reseting hidden form fields and not reseting visible
ones is inconsistent in the first place, and setting your cache to retrieve a
page every time, really doesn't do that. So consistency really doesn't matter
apparently.

Comment 15

[Bernd K.]

I am frustrated by this bug, too, but *not* on a framed page!

It notice it the most on www.livejournal.com while writing comments.
When I press the 'Preview' button instead of Submit, I get shown the preview of
the comment. To correct any mistakes, I have to use the Back-Button and presto..
the comment is gone.
I can still go forward again, grab the text, go back and insert it again, but
this is damn frustrating (and HTML tags loss nags, too).


To test this, you can do the following:
- visit any journal on www.livejournal.com
- click on the comment link on an entry
- write some comment text
- press Preview button
- go back a page

Comment 16

[Jonas Jørgensen]

I'm not able to reproduce the case where hitting Back loses the contents of text
fields (neither on frameset nor on non-frameset pages). Can anyone provide an
URL and some steps to reproduce, please?

Comment 17

[Jonas Jørgensen]

(sorry for accidentally changing the summary.)

There are two issues described here: One is about form fields getting cleared
when you press Reload, the other is about form fields getting cleared when you
go to another page and press Back. Those are two separate bugs (though I would
argue that the first is invalid) and should not be in the same bug report.

The first issue mentioned in this report is the one about pressing Reload. If
you are still experiencing the other bug, please file a separate bug report
about that.

Comment 18

[John Keiser (jkeiser)]

If both are happening, then they are the same bug.  We generally treat reload
and back the same way, and any fix would fix both.

Comment 19

[Jonas Jørgensen]

> We generally treat reload and back the same way, and any fix would fix both.

But the one about reload isn't a valid bug. Reload is *supposed* to clear form
fields -- the fact that it very often doesn't do it is bug 46845. The one about
going back, OTOH, is a valid bug which should be fixed.

Comment 20

[John Keiser (jkeiser)]

Wow, I didn't realize that.  I have been abusing that feature for a while now on
Bugzilla pages, reloading to get the new comments before I submit.

Comment 21

[Jonas Jørgensen]

> I have been abusing that feature for a while now on
> Bugzilla pages, reloading to get the new comments before I submit.

That can be very handy, true, but if someone made changes to the bug (other than
just adding a comment), you will overwrite their changes when you submit,
without getting a mid-air. And this is just Bugzilla -- imagine the amount of
critical dataloss this could cause in other applications. That's why form
elements *must* be cleared on reload. (I'm not implying that *you* don't
understand this; just trying to make the point to the people who wants bug 46845
to be wontfix'ed.)

Comment 22

[Jean-Pierre Matsumoto]

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

Comment 23

[John Keiser (jkeiser)]

Let's keep the Reload discussion out of this bug.  We will do for frames
whatever we do for normal documents, if we fix this bug.

Comment 24

[John Keiser (jkeiser)]

Attachment: Testcase

Google normally restores form controls on reload / forward / back.  When it's
in a frameset (as it is here) it is not.

Comment 25

[paxunix]

I find this to be exceptionally annoying in the case where the user selects
'View only this frame' and suddenly all form data in that frame is destroyed. 
If frames are interpreted as presenting content, simply changing the size of the
frame (or removing adjacent frames) should not change the content within the
given frame.  I don't know what actions mozilla takes internally when showing
only a single frame, but it appears to at least to reload on the page.  Is it
acceptable to just redraw the content, so the only thing changed is the size of
the frame?  I should think it would be because that is the case when the user
resizes the browser window itself--imagine how perturbed you would be if
everytime you resized your browser window the current page was reloaded and all
your form data was lost.

Comment 26

[Kevin McCluskey (gone)]

Bulk moving P1-P5 un-milestoned bugs to future. 

Comment 27

[Brian Duff]

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

Comment 28

[Brian Duff]

John - I can't reproduce your testcase on 2003041009 WinXP using the Back 
button (though I agree it reproduces on reload - but this may not be a bug as 
mentioned above).

The form-wipe-on-back-button bug only reproduces when you click on a link 
which has target="_top", as in the following test case:

http://www.sgaclan.com/moz133946/frameone.html

In the above form, type some text in the Test Text field, click the "Click Me" 
link, then click Back. The form is wiped.

Comment 29

[Brian Duff]

By Jove... this bug seems to be fixed in Gecko 20040120 (Firebird 0.7+), at 
least with the testcase I included above. I can, at last, switch to Firebird :D

Comment 30

[Boris Zbarsky [:bzbarsky]]

Hmm... so back/forward work now, as far as I can tell.  At a guess, reloading
wipes out the child frames completely and rebuilds them, so they have new
docshells and the session history state is not applied to them....

Comment 31

[Jonas Jørgensen]

bz: That's interesting, as per bug 46845, reloading shouldn't remember form fields.

Of course, the whole dataloss argument in bug 46845 is due to the fact that
visible form fields are remembered on reload, while hidden form fields get the
new value from the server. Come to think about it, this seems awfully wrong.
Would it be an idea to make hidden and visible form fields behave the same on
reload? That would fix the corrupted-data-being-submitted,
bugzilla-midairs-don't-work dataloss bug, actually regardless of whether form
fields are restored or not, as long as hidden and visible fields are treated the
same. What do you think?

Comment 32

[Boris Zbarsky [:bzbarsky]]

Please, let's keep the bug 46845 discussion in bug 46845.

Comment 33

[Kevin Brosnan]

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

Comment 34

[Ryuichi KUBUKI]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050505
Firefox/1.0+

Form contents are wiped on pages *without* framesets.

Comment 36

[Vincent Lefevre]

Still occurs on Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20140610 Firefox/24.0 Iceweasel/24.6.0, e.g. in SourceForge bug reports: when I post a comment, SourceForce sometimes complains that I'm already logged in (!!!), so that I need to go back, but my comment is lost!

Comment 37

[Marcela (Please NI request to Brindusa Tot)]

This issue no longer occurs on our end. Due to firefox has changed pretty much I will close this issue as Resolved WFM.
Please feel free to open a new bug in case you are able to reproduce the issue.