Closed Bug 293203 Opened 19 years ago Closed 19 years ago

Refreshing / going back and then forward again on a page with <input>-fields will NOT restore form data

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Version:
1.7 Branch
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: eagle3386, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414

On a forum like phpBB, if I type some chars and then reload the page (or going
back and then forward again), the form(s) are empty and my chars are lost.

Before Mozilla 1.7.5 this did NOT happen - the data was ALWAYS restored.

Reproducible: Always

Steps to Reproduce:
1. Go to any page with <input>-field(s), i. e. a forum like phpBB

2.1 Type in something and then go back
2.2 Alternatively reload the page with the <input>-field(s)

3. Go forward again to the page with the <input>-field(s)

Actual Results:  
Field(s) will be empty

Expected Results:  
Form data should be restored

Well, SOMETIMES the form data is indeed restored.

But, infact, I can't figure out on what this depends on...
did you install extensions?
Version: unspecified → 1.7 Branch
Yes, some extensions were installed:

- Adblock
- AutoForm
- Google Bar
- Mozilla Amazon Browser (MAB)
- Nuke Anything
- Popup ALT Attributes
- Print
- Tabbrowser Extension
- Tab X (I'm not sure if I installed it separately or if it's already included
in Tabbrowser Extension)
- text/plain


But, infact, I had already installed these extensions since Mozilla 1.7.1 (my
first Mozilla installation ;)).
Well, I've updated my Mozilla to version 1.7.8 - the bug still exists.

Also, I can surely say that the "Tab X"-addon was not installed by myself, I
only installed the other extensions listed in the comment above this one.
I've just tried Mozilla 1.8b1.

This time NO extensions were loaded but the problem STILL exists! :(
is it https? do the headers include nocache? please be nice and provide a url
for this site.
Assignee: general → nobody
Component: General → Layout: Form Controls
Product: Mozilla Application Suite → Core
QA Contact: general → layout.form-controls
No, the pages, where I've tried it, were not https - but, infact, here at
Bugzilla it doesn't happen.

An URL with an example, were the formdata is lost? - No Problem! :)
Just click here, type something in, click on any other link and then click the
back-button of your mouse or the back-button of the Mozilla-navigation bar, it's
just the same. ;)
Examples:

http://www.my-ct.de/ (below the "Quixt"-image or at the right side in the
login-form)
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050516

I've tried here to reproduce, didn't see the bug.

It is reproducable at http://www.my-ct.de/

Steps to repeat:
1. load http://www.my-ct.de/
2. enter a word in the input below the QUIXT image (below 'Ist meine Domain noch
frei?')
3. click on the QUIXT image, http://www.quixt.com/ is loading
4. click back, text in Input box is gone.

It didn´t matter if JS was enabled or not. A local testcase didn´t show the
behaviour, so I downloaded the full page as HTML only, inserted <base
href="http://www.my-ct.de/"> into the head, but couldn´t reproduce.
Bug seen working from the web, not from the local disk.
 
Well, as I said from the first post on:

Sometimes it's working, sometimes not - even on the same page, AFAIK.
So the page shouldn't be a factor which is influencing this dataloss-behavior.
(In reply to comment #8)
> Well, as I said from the first post on:
> 
> Sometimes it's working, sometimes not - even on the same page, AFAIK.
> So the page shouldn't be a factor which is influencing this dataloss-behavior.

Please tell if you follow my steps to repeat exactly, that you can´t reproduce
the bug always? As long as it is not known where the bug comes from, and to
verify it is fixed when it got fixed you need to have URLs and testcases where
the bug is always or often seen.

If you see errors only SOMETIMES on SOME sites, you can start looking for the
ads, or your adblocker, as a flash ad can trigger this sort of bug, when the
plugin is buggy or your adblocking extension is buggy.
I tested my steps to repeat a lot, they were always working, so I don´t care if
I can´t reproduce here. But please tell how you have seen the bug here on this
page, what did you do, exactly? Not 'use any input, use any link', but 'using
THIS input, using THIS link' I've seen the bug once/sometimes/often/always.


Okay, then I'll do it exactlier:

It ALWAYS happens that the formdata is lost on www.my-ct.de when typing various
chars into the input-field below the "Quixt"-image, clicking on the
"Quixt"-image and then going back.

It DOES NOT happen when I type various chars into the upper-right input-field
below the text "Search Query" at www.phpbb.com/phpBB/search.php, clicking on the
big "phpbb"-logo at the upper-left corner and then going back.
In this case the formdata is NOT lost and is still in the input-field.


Hopefully this helps you - if you need more websites to test with, just leave a
note and I'll post some more. :)
Sorry, I've forgotten to answer the adblocker-hint:

On the 1.7.8-version Adblock v0.2 is used.
But, infact, currently I'm using the 1.8b1-version, WITHOUT ANY extension and
the problem still occurs.
Sorry, yet another correction:

Adblock v0.5 d2 nightly 39 - this is the correct version, the "d2" had just
confused me...
Blocks: 252729
Martin, does this happen with a clean profile too?
(In reply to comment #13)
> Martin, does this happen with a clean profile too?

Yes, as I said: installing Mozilla 1.8 Beta 1, with NOTHING installed
additionally, results in the same bug.

Anyway, I moved to FF 1.0.4, and what's that? - FF does NOT forget form data, it
correctly restores the data!
Nothing installed additionally and the default preferences?

Firefox 1.0.4 is the same as Mozilla 1.7.7 core-wise, so this is really sounding
like a profile issue somehow...
No, nothing was installed in 1.8 Beta 1...

The fact is that my FF 1.0.4 uses some extensions, including Tabbed Browser -
and it even works! :-/
I realize nothing was installed.  Preferences were at their default values?

I'm sorry to be asking all these questions, but the problem is that I also
cannot reproduce the issue you describe...
AFAIK, I only changed some things (print-settings and something like that).

But I can't really imagine that this is the cause for the bug...
I recently upgraded to Firefox 1.0.4 from an earlier 1.0.X version, and now I am
having this issue (along with coworkers). It appears that pages requested via
form submission (GET/POST) are affected, but other pages are not.

Steps to reproduce:
1) Go to http://www.google.com/
2) Submit a search query for "test".
3) On the next page, change the textbox value from "test" to "testing" and submit.
4) Go back to the previous page using the browser's back button.

Expected Results:
The textbox should contain "testing", since that's what you changed it to.

Actual Results:
The textbox contains "test", the value originally displayed when the page was
first visited.


5) Go back to the previous page (http://www.google.com/) using the browser's
back button.
6) Notice that the textbox contains "test", the value you typed in, instead of
the original empty value.
OK, with the steps in comment 19 I do see the bug.  Would be nice to have a
minimal testcase...
I too can reproduce when following the steps in comment 19.
However, I think what Mozilla is doing is correct here.
Google calls the form reset() function on page load (
onLoad="document.gs.reset()" ).
That page has as a default value "test" (<input type=text name=q size=41
maxlength=2048 value="test"> ). 
So I think this is just a case where javascript is overriding the browser's
natural behavior.
Ah, excellent.  I was looking for the onload handler on that page and failing to
find it; thanks for spotting it, Martijn.

So is there a page where there is a reproducible issue in trunk builds that's
not messing with the inputs itself?
Well, I can reproduce, when I follow the steps from comment 7. 
However, that one I can also reproduce with IE6.
See this testcase, which does basically the same:
http://wargers.org/mozilla/test/bug293203/293203_input_expired.php
So that one has got something to do with the nocache headers.
Confirming, think we can dupe bug 297887 therefore.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Markus, this is not the same as bug 297887.
This is rather a vague bug that lacked a clear testcase that showed the bug,
that is the reason why people were adding various url's.
Bug 297887 is typically a bfcache issue, this bug is not.

It's probably better if this bug just got resolved worksfore, unless a clear
url/testcase that shows the bug pops up. 

Yeah, the testcase in comment 23 is working as designed.

Marking worksforme until people can come up with a testcase which actually shows
a problem.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.