An application uses a series of POSTs to the same URL. The FORM does not contain an ACTION parameter at all, which the browser interprets as "same location" (I know this is slightly incorrect HTML :-) In this situation Mozilla 0.9.6 seems to pop up the POSTDATA warning on every submission.

provide a testcase please setting milestone

Well, it happens a lot when I read Yahoo! email. If you want examples, go signup and have a try.

I can confirm this (W2K, build 2002011803) Steps to reproduce: Open an email on Yahoo!Mail and press 'Delete' -> The folder page starts loading and you get a POSTDATA warning Expected: The page should load without comments Reproducible: Always

also affecting Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020202 testcase: try shopping amazon.de : adding anything to your shopping cart will popup this warning. quite annoying and discomforting ("post again? so how many items do i get?"). i'd therefore vote to increase the priority and tackle it asap, for it will severely impact usability.

Same here, Using Mozilla 0.9.8 (the fresh new build) It is VERY annoying especially when you use mozilla for online shopping. You don't want your credit card getting charged multiple times for obvious reason.

I cannot reproduce on window 2k build 2002-02-04-??-trunk

still happening on linux: 2002022421 (please set os->all) when testing with amazon.de i noticed that they do specify a form action and also set method=post, but use input type=image instead of type=submit

The warning is issued on every POST, with the ACTION parameter, and with type=submit.

Why is this bug Futured? /be

I can say that this is a very annoyng and frustrating since some times it cause 2 sendings of data (on forums). It happends on www.osta.ee (auction) when submitting a bid. It submits 2 times (with POSTDATA warning). I tried out to get a test account (since you need to be from Estonia), but without result. :( I believe Mozilla/Netscape officials can contact them and get the accound. You need to write to "Eva Tomson" <eva@osta.ee>.

Ok, here's an explanation for FUTURE: The initial reporter reports that there are problems with apps that "...uses a series of POSTs to the same URL..." and this with a form that "...does not contain an ACTION parameter at all..." I asked him for a testcase since i cannot figure out what he means with "series of POSTs..." A lot of the comments complain about the double form-submission bug handled in bug 72906 (that's not a dup of this one!!!) I doubt that applications like yahoo-mail and e-business can work without having the action="" attribute set reasonably

since today's attempts to create testcase were in vain, i investigated some more. it would appear that my description would rather apply to bug 105636 , since i do not get mentioned warnings anymore once i set charactercoding-autodetect->off

Update from reporter: I just tried to reproduce this on the original problem application with Mozilla 0.9.8 under Linux but got a different problem which prevents it from working at all. Still investigating. Btw. the app is at http://www.allianz.de/versicherung/gesundheit/zusatzversicherung/rundumschutz/index.html under the link "Top-Paket online" (sorry, in German only). The problem appears/appeared with every "Weiter" (="continue") button.

Ok, i know now what you ment with "series": consecutive forms (like a chain) each refering the same source page. right? Now the other problem you encounter is: https://... that "Top-Paket Online" link calls a javascript functions that opens a secure page. That means that you need the PSM package that is not installed by default on linux (Personal Security Manager), but on Windows is default. Ok, don't worry about the german page: Hier zwingt man uns Deutsch zu lernen! Wir werden geprueft, und falls wir das nicht koennen, muessen wir Ueberstunden leisten. Das Leben eines Entwicklers ist hart! . . . . . . . (Scherz, es ist nur ein Zufall! :-) Schoene Gruesse nach Deutschland!

So I went to that page pointed by the URL (form the link the reporter mentioned in comment #13 "Top-Paket Online") and went trough the process of applying for a health insurance up to step 2: " IHRE ANGABEN IM ÜBERBLICK ... Person A, geboren am 12.12.1942 Zusatzversicherung für Krankheitskosten und Zahnleistungen (incl. Auslandsreisekrankenversicherung) 14,40 ..." I used build 2002031103 on Windows2000 and is working without any problems. Now it is possible that that page was changed (there is a form and it has an action= set) and the submission seems to be executed trough javascript (javascript:commandRequest('Weiter');) Reporter: Was the submission executed trough java script as you first noticed the problem?

alexsavulov@netscape.com, please read my comment #10. Try to get a test account - you'll see how huge the problem is. When you get it I'll write how to repro it.

OK, some more testing. Looks like the problem is actually a bit different than originally assumed. I tried the allianz.de page with Mozilla 0.9.9 under NT and it still gives me the POSTDATA warnings. Looks like this is independent of the following settings at least: - cache mode - mem cache size (although setting that to 0 gives bogus "you are leaving an encrypted site" warnings) - form manager settings The interesting thing is that the first few pages of the application now actually do have an ACTION parameter, and it gives the warning nevertheless. The javascript looks OK (it has always worked that way). I'll re-try under Linux asap, this could even be a PP issue. A possible hint on the real reason is comment #7. This app uses images for submit too, in this case it's <A HREF="javascript:commandRequest('foo')"><IMG SRC="..."></A> and commandRequest() does document.forms[0].submit(). Might be related. Changing the summary (and fixing broken URL).

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

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

everyone that has seen the bug and has some spare time, please test the testcase and tell us if is usable to reproduce the bug. thanx

Alexandru, no problem for me with the testcase... I were yesterday on www.osta.ee and again I is unusable in mozilla. I get how to test it without an account. Test case: http://www.osta.ee/listings/details/index.cfm?itemnum=936361613 1. Open it. 2. Press the white bar "Pakkumise tegemise lehele". 3. Now enter some in "Kasutajanimi" and "Parool" 4. Press "Tee pakkumine" 5. You'll get the POST dialogs.

If my testcase does not work restart mozilla and try it one more time.

Eugene Savitsky, i had a look at your testcase. i only get a postdata warning if i set view-charactercoding-autodetect->russian, on (off) i dont. please have a look at bug 105636 .

I raise the severity to critical since I couldn't buy online today. I filled in my request in a store, then pressed "pay with Sampo bank" (my second bank and I used it for the first time for online shopping), entered my ID number, entered all passwords, but one were not correct so it asked me again for all passwords. When I entered them it showed me the POST dialog 2 times (I pressed OK) and then again promted me I had entered the wrong password. I tried this with IE and all wlrked fine. The URL is https://www.sampo.ee/cgi-bin/pizza. How can I make this moz 1.0 stopper? PS CCing Asa for decision.

BTW: The URL is https://www.sampo.ee/cgi-bin/pizza is only the first page, after it there is one more with 3 passwords, but the source looks same. I believe the problem is indeed the cache, since on the first time all works, but then provts the POST. Please add some who works on cache. Radha?

Lars, that's true - deactivating "autodetect Russan" fixes all the problems... What's the difference between this bug and 105636?

I can't reproduce the problem on a 3/12/2 Win2k debug build using the test case or with a yahoo email account.

eugene: so which charsets and encoding do you haev installed?

i mean, which language packs?

Comment on attachment 74230 [details] testcase from www.bhphotovideo.org - looks like input type=image causes the problem invalid

i was able to reproduce what eugene savitsky reported on comment #21. there is bug 105636 that reports the same problem. everybody on this bug that had the same problem should check if after setting view-charactercoding-autodetect to (off) the problem persists. if nobody claims problems after changing that setting, i will dup this bug to bug 105636 thx

I have Autodetect Russian on. If I turn it off all forks fine.

captured TCP packages

this is not form submission!!! we request any page 2 times as soon as view-charactercoding-autodetect = russian I captured the HTTP trafic and there are 2 GET requests from the client (for the same document) but when I set autodetect = (off) there is only one. Maybe this is an interesting hint: Before the document gets requested a second time, i can see 2 TCP packets with the [RST] flag set!!! Then the document is requested again. (see attached PNG) please also check bug 105636 if is a dup of this one

oh, to get that dump i used http://www.osta.ee/listings view-charactercoding-autodetect = russian Western ISO-8859-1

This is essentially a duplicate of bug 61363 -- the charset detector reloads the page once it detects the charset.

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

sorry for the wrong reassignment but if bug 61363 gets repaired, what happens when cache is turned off? it means that we will re-fetch from server posting the data again? this would result in double submission what is not acceptable. i will leave this bug open and dup bug 105636

Yes, often meet this when working with Elance.com

Alexandru: no, the summary for bug 61363 is wrong. the solution will not require the presence of the cache. i think this bug should be marked as a duplicate of bug 61363, since this bug is the biggest reason for bug 61363 being major _dogfood_. *** This bug has been marked as a duplicate of 61363 ***

darin: thanx for duping this!

verifying