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




14 years ago
14 years ago


(Reporter: eagle3386, Unassigned)


(Blocks: 1 bug, {regression})

1.7 Branch

Firefox Tracking Flags

(Not tracked)




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

Comment 1

14 years ago
did you install extensions?
Version: unspecified → 1.7 Branch

Comment 2

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

Comment 3

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

Comment 4

14 years ago
I've just tried Mozilla 1.8b1.

This time NO extensions were loaded but the problem STILL exists! :(

Comment 5

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

Comment 6

14 years ago
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: (below the "Quixt"-image or at the right side in the

Comment 7

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

Steps to repeat:
1. load
2. enter a word in the input below the QUIXT image (below 'Ist meine Domain noch
3. click on the QUIXT image, 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=""> into the head, but couldn´t reproduce.
Bug seen working from the web, not from the local disk.

Comment 8

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

Comment 9

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


Comment 10

14 years ago
Okay, then I'll do it exactlier:

It ALWAYS happens that the formdata is lost on 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, 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. :)

Comment 11

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

Comment 12

14 years ago
Sorry, yet another correction:

Adblock v0.5 d2 nightly 39 - this is the correct version, the "d2" had just
confused me...


14 years ago
Blocks: 252729
Martin, does this happen with a clean profile too?

Comment 14

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

Comment 16

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

Comment 18

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

Comment 19

14 years ago
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
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 ( 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="" ).
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:
So that one has got something to do with the nocache headers.

Comment 24

14 years ago
Confirming, think we can dupe bug 297887 therefore.
Ever confirmed: true


14 years ago
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.
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.