From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.5+) Gecko/20011009 BuildID: 20011009 I click on "accept" button for some lisence agreement to download something, but I got the very same lisence agreement again. Can't advance to next page. Reproducible: Always Steps to Reproduce: 1.go to http://java.sun.com 2.click "products & APIs" in left column 3.click "Java 2 Platform, Standard Edition(J2SE) 4.click on "Java 2 SDK, Standard Edition, v1.3.1" 5.click on "Microsoft Windows" 6.scroll down to find button "continue" and click it 7.The lisence agreement appears. Scroll down to end of page and click on "accept" button. 8.The next page is still the lisence agreement. But if you use IE, it will be another page containing "ftp download" button.

Confirmed on W2K 2001100903. Intriguingly, once you click the accept button, a reload of the page--it'll ask if you want to repost the FORMDATA, say 'Yes'--will display the proper download page. It looks like Moz may be caching the webpages too aggressively, so it's not updating when the current page changes.

confirming with win2k build 20011009.. -> Form submission

nominating for nsbeta1. rod, any progress on this?

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

workaround from the dupe : click the "accept" button, mozilla goes to the top of that page Press the reload button in Mozilla. A Mozilla dialog about resubmitting forms will appear. Click OK. Now, the downloadpage will be loaded.

I see this problem on Linux, and since it's in form submission, it should be safe to assume the bug occurs on all OS's.

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

from n.m.o.qa.browsers: >This workaround seems to confirm that it's a cache problem. If you set > your cache settings (Edit/Preferences, then choose Advanced / Cache) to > "Every time I visit this page", you can get past the blockage.

gordon, any idea on what could cause this type of cache issue?

cc'ing darin for an HTTP perspective.

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

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

reassinging to new owner of form submission

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

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

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

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

Comment from bug 105089: A shift+reload gets you to the download page. ccing radha

In my testing, it definitely seemed to be a cache problem: This failure happens only when the cache checking interval is set to "Automatic"; setting the interval to "Check every time" or "Once per session" or "Never" allows the servlet/forms to work correctly. Presumably the "Automatic" setting isn't recognizing that the current page was the result of a POST, and thus changing the POST parameters (and POSTing to the same URL) might result in a completely different page.

the problem resides in the action href of both forms - the one that's submitted with "continue", then the one that's submitted with "accept: ... <FORM ACTION="/Download5" METHOD="POST"> ... <INPUT TYPE="SUBMIT" NAME="button" VALUE="continue"> ... and ... <FORM ACTION=/Download5 METHOD=POST> ... <INPUT TYPE=SUBMIT NAME=button VALUE="ACCEPT"> <INPUT TYPE=SUBMIT NAME=button VALUE="DECLINE"> ... As you can see the action is the same in both cases. Obviously SUN is using the same script for handling all POST's (what is legal) but MOZ is caching the answer to the first submission and it pulls it out of the cache by the second submission be cause it is seeing the same HREF. (internaly MOZ is handling form submission in the same way it handles clicks on links, but in this case is also sending the POST values).

i think that a solution would be to ignore the cache hits in case of form submission. in the most cases (except the rare situation where the same values are used for a form twice and the answer is time independent) the use of cache content while while submitting forms does not make sense. - working on it seems to be a very important issue -

cc'ing darin. I think the problem here is, having the same url for both forms as well as same postdata? Cache is capable of distinguishing 2 identical urls with different postdatas. If what alexsavulov says is right, we might need better mechanisnm in cache to distinguish such cases. However, I will see what happens in docshell in this case.

No, HTTP can distinguish two different POSTs to the same URL, even if they have the same data. We use an ID that is (now) initialized to the current date (in seconds I believe) and incremented for each POST. The only way to retrieve the results from the cache is with the URL and the ID, so each entry would be distinct.

I have an apache with mod_expires turned on and I experimented with the following directives: ExpiresActive on ExpiresDefault "access plus 1 year" and is reproductible even though <meta HTTP-EQUIV="Pragma" CONTENT="no-cache"> is included in the HTML response. Seems that IE ignores the HTTP field "expires" because is working correctly no matter what the server sends. (the test environment server serves an PHP script that has a form with an action that references the same script where is contained).

BTW: it works with NS6.1

FWIW: this isn't a problem on the 0.9.4 branch. with a 2001-10-17 linux build i can confirm this bug. and once i get to the license page, i can get "unstuck" by clearing my cache and again pressing ACCEPT. then the FTP page comes up. so, this definitely looks like a cache problem. the correction to the PostID initialization was done on 10/22, but i have my doubts about whether that problem is related. there are a couple of things that could cause this bug. the most obvious one being that it could be that docshell is setting an old CacheKey on the new channel which would result in retrieving the POST results from the cache. i'm not sure how this matches up to the fact that this only happens when the cache validation pref is set to AUTOMATICALLY. anyways, once i have a debug build, i'll be able to confirm what's actually going on here.

UPDATE: be cause SUN has <meta HTTP-EQUIV="Pragma" CONTECNT="no-cache"> (please note the misspelling of CONTENCT) the bug is reproductible, no matter which kind of caching is turned on: AUTO..., ONCE..., NEVER Using CONTENT, the bug is reproductible only for: ONCE..., NEVER

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

Thanks all you for your hints. When I switch off the cache (ie, set it to ""Every time I visit this page") the accept button works as expected, therefore I tend to agree that it is a cache probem. Also thanks for the hint to use Shift+Reload: This works, too! And I confirm that the problem occurs with the Linux RPMs for Red Hat 7.x under - SuSE Linux 7.2 German - SuSE Linux 7.3 German and the Windows version under - Windows NT 4.0 German with Service Pack 6. Regards Peter

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

This workaround met with 100% success on Windows 98SE, build 2001102309: http://java.sun.com/j2se/1.3/jre/download-windows.html Click begin US version Click ACCEPT Click Refresh and repost form data. Click HTTP Download Click Refresh and repost form data. Would it be a good idea to add the word Java to the subject? When searching for this bug, I found bug 56780 instead of this one. Does this block 56780?

This bug does not have anything to do with Java!!! Please don't add Java to any of the fileds of this bug report. Adding Java to the fields of this bug would disturb the work of our QA troops. If you want to publish the workaround for the existing mozilla versions, please use mozillanews, #mozilla, news groups or whatever is best suitable to make this workaround public. thx

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

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

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

who is in charge of generating the cache keys on cache channels? this causes the problem here because the cache key mechanism works like this: nsDocShell::AddToSessionHistory(nsIURI * aURI, nsIChannel * aChannel, nsISHEntry ** aNewEntry) { ... if (cacheChannel) { cacheChannel->GetCacheKey(getter_AddRefs(cacheKey)); ... // the next time we access the same URL: nsresult nsDocShell::DoURILoad(nsIURI * aURI, nsIURI * aReferrerURI, nsISupports * aOwner, nsIInputStream * aPostData, nsIInputStream * aHeadersData) { ... else if (mOSHE) // for reload cases mOSHE->GetCacheKey(getter_AddRefs(cacheKey)); // that retrieves the same cache key set previously and so ... if (cacheChannel && cacheKey) cacheChannel->SetCacheKey(cacheKey, cacheFlag); // sets the same cache key for the next POST and this will go forever Only the first time it works, as long as there is no cache key set yet. If I change the code to: if (cacheChannel && cacheKey) { nsCOMPtr<nsISupportsPRUint32> container = do_QueryInterface(cacheKey, &rv); if (NS_FAILED(rv)) return rv; PRUint32 post; rv = container->GetData(&post); post++; // increment the ID rv = container->SetData(post); cacheChannel->SetCacheKey(cacheKey, cacheFlag); } it works I need some explanations guys, coz I'm not a cache expert :-)

interesting... http generates a unique cache key for each POST request. however, if docshell assigns a cache key to a http channel, the http channel will use the passed in cache key. docshell is not supposed to know the structure of the cache key... docshell is only supposed to set the cache key when going back or forward. it sounds like the problem may be that docshell is setting the cache key for normal loads. can someone confirm this? radha?

I think that is what is going on. I think this is a regression happened as part of my checkin for bug 89309 in v. 1.357 of docshell. I think changing the last part of code to if (cacheChannel && cacheKey) { if (mLoadType == LOAD_HISTORY || mLoadType == LOAD_RELOAD_CHARSET_CHANGE) cacheChannel->SetCacheKey(cacheKey, PR_TRUE); else if (mLoadType == LOAD_NORMAL_RELOAD) cacheChannel->SetCacheKey(cacheKey, PR_FALSE); } will fix the problem here.

Yes it works, but the POST ID is not changing between different post. If the ID is meant to be generated once per form access and not after every POST, I would suggest we apply the patch. Any suggestions, oppinions?

radha: i don't think we should be setting a cachekey for normal loads. it just doesn't make sense. doing so would wipe out old cache entries, and making going back not produce the old form post results. we should only set a cachekey when loading for back/forward.

oh... i forgot to mention: else if (mLoadType == LOAD_NORMAL_RELOAD) is not working (LOAD_NORMAL_RELOAD unknown) so i used: else

Darin: I agree with you. CacheKey was getting set for only back/forward and reloads only. But this behavior was broken when I fixed 89309. Now with the suggestion I have made, we will re-instate the proper (old) behavior and take care of 89309. I don't understand this post id that Alex is mentioning. Can you comment on it.

Alex: You can not use just 'else'. it should be else if (LOAD_RELOAD_NORMAL). I will post a better patch soon.

ok.. i was a bit confused: LOAD_NORMAL_RELOAD can set a cacheKey since we'll be reloading the page... it doesn't matter that the post ID is not incremented in this case because the data is going to be replaced.

radha: do you want to take over this bug? if you need a test page try: http://206.222.241.94/multiform.php (is my LINUX machine that provides a php script that generates a form after every post, referencing itself in the "action". the HTTP field "expires" is set to access + 1 y)

Taking over from Alex. Thanks for the debugging.

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

would this cover the jakarta bug?

Comment on attachment 55951 [details] [diff] [review] Patch to docshell sr=darin (looks good to me)

radha: one question... will the user still be prompted to rePOST data if they press the reload button? or does SetCacheKey(cacheKey, FALSE) preclude this?

darin: Yes. User will be prompted with the repost dialog, if they pressed reload on a post result page.

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

Comment on attachment 55951 [details] [diff] [review] Patch to docshell Looks good to me, r=adamlock

Fix checked in.

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

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

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

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

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

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

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

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

The problem still happens for the linux version downloads under java.sun.com/j2se. Reopen the bug.

0.9.6 is long gone. -> 0.9.7

WFM Linux 2002011808. I can get all the way through the Linux J2SE JRE download, from start to finish (including license). Please confirm.

WFM with 2002-01-20-16 on Linux. I could pass the license page for both the Windows download and Linux download of jdk 1.3.1 as well as 1.4 beta. I used to see this bug before, but it seams to be definately gone now.

marking worksforme per comments.

The problem has definitely disappeared in recent version --- my thanks to thedevelopers! Specifc: In the 0.9.7 release it works as expected. Peter

verifying on win98 2002-01-29-03-trunk and linux 2002-01-28-08-trunk

Nominating for 0.9.4 branch. we need this patch in the 9.4 branch to take care of some serious siebel problems(see bug 128379) I have a tree with this patch ready to go. This has baked in the trunk for almost 3 months. I would like to check this into 0.9.4 branch today. Sun has also verified that this patch fixes their problem.