This problem could let users get into Siebel's application without logging in. Here was how it happened: 1) User logs into Siebel by submitting the login form. 2) After his/her session times out, their redirected back to the login screen. 3) When the user clicks 'Reload', the previous form values are submitted instead of reloading the current URL. So we have a URL of: http://<server>/callcenter/start.swe?SWECmd=Login&SWECM=S <http://<server>/callcenter/start.swe?SWECmd=Login&SWECM=S> And a form containing the hidden field SWECmd with a value of 'null' In a java script function called when the form is submitted, we assign form.SWECmd.value = 'ExecuteLogin' Now under IE, when the page is reloaded/refreshed we get SWECmd=Login. Exactly what's in the URL. Under Netscape, when the page is reloaded/refreshed we get SWECmd=ExecuteLogin. Not what's expected!

This is currently Siebel's #2 (#1 was 105292) top bug that blocks them from releasing their application on Netscape 6.2.1.. Please help!!!

Would this be affected by the "reloading a page does not reset form values" bug?

Need reduced test case

Second the need for a testcase (any testcase is better than none). Is the URL correct after step 2?

Over to John the submission guy.

Adding AOLTW

This servlet is simplified testcase for the reloading problem. Steps to reproduce: 1. Go to login page /path/to/servlet/Stest?Cmd=Login 2. Type something in text fields and click on "Login" link. 3. Click on "error page" link 4. Close alert window. Now you should see the login page again. If you try to reload page, you will see the frameset again instead the login page. Note that this problem does not appears in the current trunk, but reproduce on ns621beta. (for me it is reproduced on Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.4) Gecko/20020225) Also note that if we use "top.location = someURL" instead "top.location.replace(someURL)" then we also avoid this problem.

this bug is reproducible in mozilla 0.9.5 but is fixed in mozilla 0.9.6 cc'ing radha... radha: do you recall the "clear form values" patches that went in between mozilla 0.9.5 and 0.9.6?

I guess what it was fixed by fix for 109319, now I try to check it.

I think that it is bug 103850 that fixed this problem.

andrew: can you try the patch from bug 103850?

I tried fix for 103850 already - it do not help (at least for 0.9.4) :((( Now I trying to find the workable fix. Darin: Do you have any other suggesions?

radha: any other suggestions? what else might have changed?

Let me dig in more and I will update later today.

I looked through all the checkins between 0.9.5 and 0.9.6. I still believe that it is the patch to bug 103850 that fixed this problem. Andrew: Did you apply the patch for bug 103850 to the 0.9.4 tree? Do you still see the problem after applying the patch? If I understand this right, the bug is not reproducible in the trunk but is reproducible in the 0.9.4 branch. I clicked on the testcase. It shows me the java source, but no html page. Please update.

Attached testcase is Java servlet source. You need for some supported servlet engine webserver or JSDK in order to run this testcase. As I understand the problem occurs when we use the "top.location.replace(some_url)" statment inside the onload handler of the body tag. I already tried to apply patch for the 103850 to the 0.9.4 tree and as I can see it does not help. I going to try it again in order to be shure.

andrew: Your latest comment on reproducibility puzzles me. I think there is also another problem here, apart from 103850. A problem related to location.replace. Please see bug 108041. Based on what you are saying, we probably need 108041 also in the branch. Is this problem clearly fixed in 0.9.6 and above? That will help me track this down faster. Anyways, Darin is trying to set up a local server with servelet support and I'm pulling the 0.9.4 branch right now. I think we can get to this fast.

i setup the servlet app internally here: http://unagi.mcom.com:4444/servlet/Stest steps to repro: 0) load URL 1) enter any username:password 2) press login 3) press "goto error page" 4) accept alert dialog 5) notice that you are back on the login page 6) now observing network traffic, press reload. notice that the first HTTP request is a POST request w/ the old username:password (you can't see the username:password, but the fact that this request is a POST request is enough to demonstrate the bug).

Radha, you are right, the fix for 108041 solve problem! Now I going to attach updated patch

This is updated patch from bug 108041. I change it a bit in order to make it applicable to the 0.9.4

excellent news... thank you radha!!

I suspect that you would need both 103850 and 108041 in the branch. who is going to checkin the patch to the branch? This bug should be fixed on trunk and in 0.9.9 branch. So, I don't see the need for a nsbeta1+.

To radha.

Please see my latest comments to bug 108041 and 103850. I would like to check in those individual patches to the 0.9.4 branch rather than try to get reviews for this one. Once those bugs are checked in, I will mark this fixed.

Thsi got fixed in the 6.2.2 branch last friday.

Plussing for AOLTW

This fix has been checked into the Sun 6.2.1 branch.

I verified this fix in Siebel today with the new release build. We can close this bug now.