103850 - accept license agreement to go to next page failed [form sub]

Status: VERIFIED WORKSFORME

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

Description

[Wenqing Jiang]

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.

Comment 1

[Phil Bordelon]

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.

Comment 2

[Matthias Versen [:Matti]]

confirming with win2k build 20011009..

-> Form submission

Comment 3

[Matthias Versen [:Matti]]

Attachment: Page source

Comment 4

[Brian Ryner (not reading)]

nominating for nsbeta1.   rod, any progress on this?

Comment 5

[Matthias Versen [:Matti]]

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

Comment 6

[Matthias Versen [:Matti]]

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.

Comment 7

[Daniel Perup]

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.

Comment 8

[Matthias Versen [:Matti]]

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

Comment 9

[Matthias Versen [:Matti]]

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.

Comment 10

[Brian Ryner (not reading)]

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

Comment 11

[gordon]

cc'ing darin for an HTTP perspective.

Comment 12

[Matthias Versen [:Matti]]

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

Comment 13

[Matthias Versen [:Matti]]

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

Comment 14

[rods (gone)]

reassinging to new owner of form submission

Comment 15

[Matthias Versen [:Matti]]

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

Comment 16

[Boris Zbarsky [:bzbarsky]]

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

Comment 17

[Bradley Baetz (:bbaetz)]

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

Comment 18

[Boris Zbarsky [:bzbarsky]]

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

Comment 19

[Boris Zbarsky [:bzbarsky]]

Comment from bug 105089:

A shift+reload gets you to the download page.

ccing radha

Comment 20

[W. Craig Trader]

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.

Comment 21

[Alexandru Savulov]

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

Comment 22

[Alexandru Savulov]

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 -

Comment 23

[Radha on family leave (not reading bugmail)]

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. 

Comment 24

[gordon]

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.

Comment 25

[Alexandru Savulov]

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

Comment 26

[Alexandru Savulov]

BTW: it works with NS6.1

Comment 27

[Darin Fisher]

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.

Comment 28

[Alexandru Savulov]

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

Comment 29

[Matthias Versen [:Matti]]

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

Comment 30

[Peter Bär]

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

Comment 31

[Boris Zbarsky [:bzbarsky]]

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

Comment 32

[Damian Yerrick]

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?

Comment 33

[Alexandru Savulov]

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

Comment 34

[Matthew T (active 1999-2002)]

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

Comment 35

[Bradley Baetz (:bbaetz)]

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

Comment 36

[Alexandru Savulov]

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

Comment 37

[Alexandru Savulov]

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 :-)

 

Comment 38

[Darin Fisher]

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?

Comment 39

[Radha on family leave (not reading bugmail)]

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. 

Comment 40

[Alexandru Savulov]

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?

Comment 41

[Darin Fisher]

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.

Comment 42

[Alexandru Savulov]

oh... i forgot to mention:

else if (mLoadType == LOAD_NORMAL_RELOAD)

is not working (LOAD_NORMAL_RELOAD unknown)

so i used:

else

Comment 43

[Radha on family leave (not reading bugmail)]

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. 

Comment 44

[Radha on family leave (not reading bugmail)]

Alex: You can not use just 'else'. it should be 

else if (LOAD_RELOAD_NORMAL).

I will post a better patch soon. 

Comment 45

[Darin Fisher]

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.

Comment 46

[Alexandru Savulov]

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)

Comment 47

[Radha on family leave (not reading bugmail)]

Taking over from Alex. Thanks for the debugging.

Comment 48

[Matthias Versen [:Matti]]

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

Comment 49

[timeless]

would this cover the jakarta bug?

Comment 50

[Radha on family leave (not reading bugmail)]

Attachment: Patch to docshell

Comment 51

[Darin Fisher]

Comment on attachment 55951 [details] [diff] [review]
Patch to docshell

sr=darin (looks good to me)

Comment 52

[Darin Fisher]

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?

Comment 53

[Radha on family leave (not reading bugmail)]

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

Comment 54

[Alfonso Martinez]

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

Comment 55

[Adam Lock]

Comment on attachment 55951 [details] [diff] [review]
Patch to docshell

Looks good to me, r=adamlock

Comment 56

[Radha on family leave (not reading bugmail)]

Fix checked in.

Comment 57

[Matthias Versen [:Matti]]

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

Comment 58

[Matthias Versen [:Matti]]

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

Comment 59

[Matthias Versen [:Matti]]

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

Comment 60

[Gilles Durys]

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

Comment 61

[Matthias Versen [:Matti]]

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

Comment 62

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 63

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 64

[Boris Zbarsky [:bzbarsky]]

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

Comment 65

[Joe Chou]

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

Comment 66

[Asa Dotzler [:asa]]

0.9.6 is long gone. -> 0.9.7

Comment 67

[John Keiser (jkeiser)]

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

Please confirm.

Comment 68

[André Dahlqvist]

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.

Comment 69

[Brian Ryner (not reading)]

marking worksforme per comments.

Comment 70

[Peter Bär]

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

Comment 71

[Vladimir Ermakov]

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

Comment 72

[Radha on family leave (not reading bugmail)]

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.