Bug 133946 (hhhh)

Form state restoring is not working with framesets on reload [OLD: Form elements are wiped....]

NEW
Unassigned

Status

()

Core
Document Navigation
--
critical
15 years ago
3 years ago

People

(Reporter: Brian Hunt, Unassigned)

Tracking

(Blocks: 1 bug, {dataloss, testcase})

Trunk
dataloss, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
Confirmed on v0.9.9+ build 2002032708 win98 on test page with frames as in
comment #2
(Reporter)

Comment 4

15 years ago
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
OS: Windows 2000 → All

Updated

15 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

15 years ago
marking new.

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

Updated

15 years ago
Keywords: dataloss

Comment 6

15 years ago
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.

Updated

15 years ago

Comment 7

15 years ago
*************************
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.
(Reporter)

Comment 8

15 years ago
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

15 years ago
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

15 years ago
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


Summary: Form elements are wiped, erased, deleted, lost → Form state restoring is not working in all cases [OLD: Form elements are wiped....]

Comment 11

15 years ago
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 ;-)
Assignee: alexsavulov → jkeiser
Summary: Form state restoring is not working in all cases [OLD: Form elements are wiped....] → Form state restoring is not working with framesets [OLD: Form elements are wiped....]
(Reporter)

Comment 12

15 years ago
------- 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

15 years ago
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

15 years ago
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

15 years ago
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

Updated

15 years ago
Priority: -- → P2

Updated

15 years ago
Summary: Form state restoring is not working with framesets [OLD: Form elements are wiped....] → Form state restoring is not working with framesets [OLD: Form elements are wiped....]

Comment 16

15 years ago
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

15 years ago
(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.
Summary: Form state restoring is not working with framesets [OLD: Form elements are wiped....] → Form state restoring is not working with framesets [OLD: Form elements are wiped....]
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

15 years ago
> 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.
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

15 years ago
> 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.)

Updated

15 years ago
Keywords: testcase
*** Bug 138895 has been marked as a duplicate of this bug. ***
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.
Created attachment 87566 [details]
Testcase

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

Updated

15 years ago
Keywords: mozilla1.1

Comment 25

15 years ago
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.
Bulk moving P1-P5 un-milestoned bugs to future. 
Target Milestone: --- → Future

Comment 27

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

Comment 28

14 years ago
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.

Updated

14 years ago
Alias: hhhh
Blocks: 191182

Comment 29

14 years ago
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
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....
Assignee: john → nobody
Component: HTML: Form Submission → History: Session
Priority: P2 → --
QA Contact: vladimire → core.history.session
Summary: Form state restoring is not working with framesets [OLD: Form elements are wiped....] → Form state restoring is not working with framesets on reload [OLD: Form elements are wiped....]
Target Milestone: Future → ---

Comment 31

14 years ago
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?
Please, let's keep the bug 46845 discussion in bug 46845.

Comment 33

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

Comment 34

12 years ago
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.

Updated

12 years ago
Blocks: 293024

Updated

12 years ago
No longer blocks: 293024

Updated

9 years ago
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
Duplicate of this bug: 191182

Comment 36

3 years ago
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!
You need to log in before you can comment on or make changes to this bug.