134029 - "must resubmit POST data" dialog on bugzilla form submission

Status: RESOLVED DUPLICATE of bug 61363

(Core :: DOM: Core & HTML, defect, P1)

Description

[Darin Fisher]

from bug 72906:

------- Additional Comment #90 From Alec Flett 2002-03-28 09:45 -------

I'm seeing other wierd issues with certain forms where a normal submission
results in a cache warning (i.e. for instance stuff about POSTDATA expiring even
though I'm submitting the firm, not hitting forward/back/etc)



------- Additional Comment #91 From Darin Fisher 2002-03-28 10:28 -------

alec: i'm seeing that too, especially w/ the 2002-03-26-08 build under linux. 
it seems to happen very often when i focus on another window before the form
submission completes.

Comment 1

[Darin Fisher]

i should also add that i'm seeing this behavior in the 2002032608 linux build,
and to the best of my knowledge pressing cancel on the dialog doesn't prevent
the form from being posted.

Comment 2

[Alec Flett]

I've gotten this on:
1) travelocity (almost double-booked my hawaii airfare - very bad!)
2) Yahoo groups, on the calendar function
..a few other random sites... darin seems to have noticed a focus thing, but I
thought it was more that I was posting multiple times to the same url (i.e. on
some sites you are constantly posting to the same URL, with different data each
time.. 
but that's my hypothesis, I have no idea if it's correct!

I've found that once you get in this state, the url in question is cursed until
you quit & restart the browser.

I've never seen this on bugzilla, strangely.

Comment 3

[Alec Flett]

cc'ing gordon in case this is cache related.

Comment 4

[Alexandru Savulov]

Don't forget to check the server respose headers too. I saw the kind of
behaviour Alec describes:

"...the url in question is cursed until
you quit & restart the browser. ..."

with pages that have Cache-Control: no-store. Well it was another problem of
course related to no-store but there was something that made me suspicious:

 I experimented with this no-store flag to see what happens with the form state
 when hitting refresh and the flag was set.
 I observed something strange: I removed the flag and reloaded the page to see if 
 the problem persists and it did. Then i thought, is not the flag and started to 
 reduce the testcase comparing it to another page that didn't showed that 
 problem.
 I got the testcase down to an text input and the problem was still there while   
 on the comparsion page everithing was ok. (the markup was identical)
 I said, man this is insane, this cannot be so i restarted the browser and the 
 problem was gone!

 Conclusion: even though i removed the no-store flag (set by a PHP call to    
 header(...)), the flag was remebered all trough the session although the server 
 was not sending it anymore. Is this correct?

Comment 5

[André Langhorst]

Confirmed on W32 (b2002-04-03-03)
setting OS to all

this happens with numerous other pages too (eg.
http://www.wwk.de/Inhalte/Produkte/WWK%20Leben/Berufsunf%e4higkeit/Angebot/BUAngebot.jsp
; just to name the last one I browsed) => just lick on [Angebot anfordern]

increasing severity, because it prevented several online applications from working.
setting to major (if not critical, see comment #2
>> 1) travelocity (almost double-booked my hawaii airfare - very bad!)

nevertheless, this is a must-fix for 1.0 IMHO
proposing mozilla1.0

Comment 6

[Oliver Klee]

I've noticed that Mozilla sometimes seems to load a page twice while displaying
it (first only partially, and then completely). If the page is a form, we get
this bug.

BTW, I'm seeing this bug consistently on http://www.amazon.de/ (using M0.9.9,
though).

Comment 7

[Oliver Klee]

Bug 135289 may be related.

Comment 8

[Alec Flett]

Ah! here's this bug. 
I should add this is driving me NUTS. nominating for adt

sites I've seen this at:
http://www.roadrunnersports.com/ (try searching for a shoe more than once, also
try hitting "back" after looking at a shoe - you can't go back to the search
results)
http://www.performancebike.com/

I know there are others, I hit this at least once a day, just assumed someone
was looking at it...:(

Comment 9

[Radha on family leave (not reading bugmail)]

You are probably seeing bug 102047 and bug 61363, both with right nominations. 

Comment 10

[Alec Flett]

I've seen that too, but I think its a different bug - some kind of funky reflow,
nothing to do with form submission. Mind filing a new bug? against Layout?

Comment 11

[Alec Flett]

(oops, ignore that, I hadn't gotten radha's bugmail)

Comment 12

[Alec Flett]

also http://www.travelocity.com/, logging in for the first time.

Comment 13

[Jaime Rodriguez, Jr.]

I don't see a patch with reviews for this bug, so I am gonna remove the adt1.0.0
nomination, ok?

This sounds severe, and that it is happening on some top sites ... adt1.

Comment 14

[Alexandru Savulov]

will start looking

Comment 15

[Alexandru Savulov]

i'm on it

Comment 16

[Alexandru Savulov]

I tried for hours to reproduce this using the URL's listed here and didn't
succeeded. (pulled 2002-05-09 at ~8:00 pm PCT)

Anyone that can reproduce this please try to see if you have some different
settings from default (i recall that we load some pages twice when we have
special char encoding set for example). I would really like to be able to
reproduce this. It bothers me a lot that I can't.

Comment 17

[Alec Flett]

ok, I get this constantly on the branch, and it is still 100% reproducable, at
least for the first one I tried:
1) Go to http://www.roadrunnersports.com/
2) using the menus, navigate to Men's Running Store -> Mens Shoes -> Running
3) Choose some search terms, and search for a shoe

Argh! now its not doing it for me. It did it like 30 seconds ago. maybe its only
the first time you visit the page? or maybe this needs to be run under purify to
look for UMR's?

Comment 18

[Radha on family leave (not reading bugmail)]

Looking thro' Alec's original report, if you see the warning that "the postdata
is expiring from cache" even while submitting a form (not going back/forward),
it is highly possible you  ran into this situation due a charset detection
reload. That is covered by bug 102407. 

Comment 19

[Alexandru Savulov]

hmm still not able to repro.

btw:

attinasi is one of the people that saw that message a lot (ebay, bugzilla and so
on). however, trying to reproduce on his machine failed (probably be cause i was
looking :-). i'm wondering what is causing this irregular beahviour. here is
another ideea i have. maybe this will help to understand the cause: could
someone that is able to reproduce, log the HTTP trafic to see what is going on
please? (use ehtereal[www.ethereal.com] for that for example). If you do this,
stop the logging at the point when the POSTDATA dialog appears (the subsequent
trafic is not important).

thx

Comment 20

[Alexandru Savulov]

radha:

yes I think you're right, i know about that charset issue. however it makes me
pretty suspicios that people like attinasi saw this on bugzilla and ebay. afaik
attinasi does not use some special charset detection (particulary for ebay where
is not needed i guess, but who knows). i tested with different char coding
settings and could not reproduce this.

Comment 21

[Darin Fisher]

a lot of websites serve up content with a META tag like this:

  <META http-equiv="Content-Type" content="text/html; charset=windows-1252">

this charset is nearly identical to ISO-8859-1, but if this line is not detected
in the first chunk of data sent to the parser then there will be a
charset-induced reload of the page.

if you'd like to see an example of a document with this charset, just save a
webpage using IE... it always stamps this line in there even if the original
webpage didn't include it :-)

this bug is intermittent because it only happens when the data appears in a
subsequent packet... which is rarely the case since <META> tags must appear
within the <HEAD> section of a document.

Comment 22

[Alexandru Savulov]

that might be the case where huge javascript code parts are in front of the meta
tags i guess (how are linked scripts requested? immediately or after the
document has finished loading?). however bugzilla is not making use of this kind
of tags (neither do the HTTP header fields contain any kind of information about
that

here is the header of the response page:

<head>
<title>Bug processed</title>
<link rel="icon" href="http://mozilla.org/images/mozilla-16.png" type="image/png">

</head>

here is the captured HTTP header:

HTTP/1.1 200 OK
Date: Fri, 10 May 2002 21:47:26 GMT
Server: Apache/1.3.19 (Unix) mod_throttle/3.1.2
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html


I don't see anything about charset or cache control or whatever that might
trigger the reposting, still attinasi saw this happening when posting comments
on bugzilla.




Here is the http://www.ebay.com stuff (reporter: attinasi):

<head>
<title> Items matching ( boss gt6 ) </title>
<meta http-equiv="Expires" content="Sat, 11 May 2002 00:36:49 GMT"></head>

HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Connection: close
Date: Fri, 10 May 2002 22:04:40 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Fri, 10 May 2002 20:18:25 GMT
ETag: "fc38ad75ff8c11:8609"
Content-Length: 1808


here is the http://www.roadrunnersports.com/ header (reporter: alecf):


<head>
<title>Running shoes...</title>
<meta NAME="Description" Content=" Road Runner...">
<meta NAME="Keywords" Content=" running shoes...">
<!-- Server-side javascript -->
<script language="javascript" src="/include/validateEmailFormat.js"></script>
<script LANGUAGE=javascript1.2>
</SCRIPT>

<!-- Client-side javascript -->
<script language="javascript" src="/include/utils.js"></script>
<!--  stylesheet -->
<link rel=stylesheet href="/include/corestyle.css" type="text/css">
<script language="javascript">
[some javascript
</script>
		<script language="javascript" src="/include/global_all.js"></script>	
<!-- HOST IS: bv02prd
 -->
<link rel='shortcut icon' href='http://www.roadrunnersports.com/favicon.ico'>
<link rel="P3Pv1" href="http://www.roadrunnersports.com/w3c/p3p.xml">
</head>


HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Fri, 10 May 2002 22:09:39 GMT
Content-type: text/html
Connection: close

Comment 23

[Jaime Rodriguez, Jr.]

is this still an issue after resolving bug 102407?

lowering impact to ADT2, until we know this is still affecting top sites in a
very bad way.

Comment 24

[John Keiser (jkeiser)]

darin: this is probably the Transfer-Encoding: chunked thing we also saw bug
137936 for details.

Comment 25

[patrik]

Attachment: libpcap dump of traffic that generates the problem

This is a dump of the traffic on port 80 when clicking the "Angebot anfordern"
button on
http://www.wwk.de/Inhalte/Produkte/WWK%20Leben/Berufsunf%e4higkeit/Angebot/BUAngebot.jsp,
until the dialog that tells me to resend comes up. It's in libpcap format (the
default suggested by ethereal).

Comment 26

[patrik]

Attachment: Full dump of traffic until page is loaded

This is a libpcap dump of the traffic generated when clicking the button as in
the previous attachment, but includes the traffic after pressing the "Ok"
button on both the resubmit dialogs that come up.

Comment 27

[Alexandru Savulov]

thanks for the libcap dumps. i went trough them and couldn't find a reason for
the reloading. the server is serving a file that has content-type=text/html
charset=iso-8859-1. so i think there is no reload performed because of the
charset used. could it be that javascript triggers that?

Comment 28

[Vladimir Ermakov]

Anybody still seeing this? If so on which website and build?

Comment 29

[Alexandru Savulov]

good question, this one has a bunch of keywords, but there are no dups or
whatever to tell us that this is a frequent issue. afaict, i never had any
problems with the  re-posting thing. for me that dialog is shown correctly. i
don't say that the reports were wrong. but maybe we should reconsider the keywords.

Comment 30

[Vladimir Ermakov]

I asked Alec Fett if he was able to reproduce the problem and he said that he
has not seen it in a while. I have not seen the problem either so marking it
works for me. If you are still seeing this, feel free to reopen. Give details
about your build and platform please.