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?

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.

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

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.

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.