Closed Bug 17088 Opened 25 years ago Closed 25 years ago

[BLOCKER] dogfood [TESTCASE] OnLoad handler not called if page comes from memory cache

Categories

(Core :: Networking: Cache, defect, P1)

Product:
Core
Component:
Networking: Cache
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: desale, Assigned: gordon)

References

(
URL
)

Details

(Whiteboard: [PDT+] no fix in hand yet. test stopped working some time in the last week) 

If we try to submit one form to same cgi again and again by calling same page
from cgi, form does not get submitted second time. N4.x does submit form in loop
again and again untill we close application, but apprunner fails to submit form
second time.
We are approaching this techniq in our driver, and its blocking our automation
test.

BUILDS TESTED:

FAILED ON THESE BUILDS: 10-22-09, 10-20-09, 10-19-09
WORKING FINE ON THIS BUILD: 10-18-12

STEPS TO REPRODUCE:
1] Please visit Urls mentioned above. [It has one page that submits data onLoad
event of page to once cgi, and this cgi calls same page again.]

OR

1] Please copy HTML code I'm providing, save it as HTML file.
2] Please copy CGI code I'm providing, Save it as cgi file.
3] Change action of form in HTML file, to your new lcation of cgi file.
4] Change last line of cgi file, set window.location to your new location of
HTML file.
5] Open this HTML file in mozilla.exe
6] You can see "Click to see Results: desaletest.html" on screen. Click this
"desaletest.html", to see how many times we submitted data.

EXPECTED RESULTS:
Form should keep on submitting data to cgi in a loop, since we are submitting
data onLoad event of page, and we are calling page from cgi too.

If you try to access Results file by clicking "desaletest.html" on screen, you
should see "Input Hidden Data" line multiple times, since we are submitting same
data in loop.

ACTUAL RESULTS:
After submitting data first time, form stops submitting data second time.

If you try to access Results file by clicking "desaletest.html" on screen, we
can see "Input Hidden Data" line just once.

[NOTE: If we perform this test multiple times, results file will keep on
apending data on it, so every time you perform test you need to delete
desaletest.html from results directory. It'll be better if you simulate problem
on your own machine using code I'm providing,  instead of using URL above.]

HTML CODE START:

<HTML>
<HEADER>
<TITLE>NGDriver</TITLE>
</HEADER>
<script>
<!--
function fixSubmit() {
   document.results.submit();
}
//-->
</script>

<BODY onLoad="fixSubmit();">
Clic to See Results: <a href=http://bubblegum/ngdriver/results/desaletest.html
target=results>desaletest.html</a><br><br>
<FORM name="results" action="/ngdriver/cgi-bin/prashant1.cgi" method="post">
<INPUT name=resultsfile type=hidden value=desaletest.html>
<input type="hidden" name="textarea" value="Input Hidden Data ">
</FORM>
</BODY>
</HTML>

HTML CODE END:

CGI CODE START:

#!/usr/sbin/perl
require "cgi-lib.pl";

MAIN:
{


    &ReadParse(*input);

    print &PrintHeader;

    #Next line for NT
    chdir("e:\\WebDocs\\NGDriver");
    $resultsdir = "results";
    $resultsfile = $input{'resultsfile'};
    $s = $input{'textarea'};

    open(hFILE, ">>$resultsdir/$resultsfile") || die "ERROR";
    print hFILE "<br>$s<br>";
    close(hFILE);
    print
"<script>window.location='http://bubblegum/ngdriver/pratesting/test2.html';</scr
ipt>";

}

1; # return true

CGI CODE END:

I'm not sure how clear I am to explain the problem. If you have any questions,
please feel free to ask me.
Priority: P3 → P1
Setting priority to P1.
Summary: [BLOCKER][TESTCASE]Can not submit same form second time to same cgi if we call same page from cgi again. → [BLOCKER] dogfood [TESTCASE]Can not submit same form second time to same cgi if we call same page from cgi again.
Reassigning to Kevin.
Assignee: karnaze → kmcclusk
Assignee: kmcclusk → pollmann
Reassigning to Eric
Whiteboard: [PDT+]
Status: NEW → ASSIGNED
Hardware: PC → All
I can not reproduce this bug, I've put up a duplicate of the page and cgi posted
here, but it works for me.  My duplicate is at:

http://blueviper/forms/qacgi.html

The files are at:  (UNIX)
/u/pollmann/work/forms/qacgi.html
/u/pollmann/work/forms/qacgi.cgi
/u/pollmann/work/forms/qacgiout.html

Since I can't reproduce the bug, I can only offer suggestions.  If you are still
blocked by this bug, try changing the method="post" to method="get".  If this
fixes your bug, please let me know.

If you are still experiencing this bug with tomorrow's build, please let me
know:
1) platform you are running on
2) are you running apprunner or viewer?
3) what is printed to the console as the test site is running?

Here are some more observations:
 - <HEADER> isn't a valid html tag, but <HEAD> is.
 - <SCRIPT> should appear in the <HEAD> or <BODY> but not between.

<HTML>
 <HEAD>
  <TITLE>NGDriver</TITLE>
  <script>
<!--
function fixSubmit() {
   document.results.submit();
}
//-->
  </script>
 </HEAD>

<BODY onLoad="fixSubmit();">
Clic to See Results: <a href=http://bubblegum/ngdriver/results/desaletest.html
target=results>desaletest.html</a><br><br>
<FORM name="results" action="/ngdriver/cgi-bin/prashant1.cgi" method="post">
<INPUT name=resultsfile type=hidden value=desaletest.html>
<input type="hidden" name="textarea" value="Input Hidden Data ">
</FORM>
</BODY>
</HTML>

  - There is a cool free CGI library that is even included with most
distribution of perl.  I rewrote the CGI with it like this:

#!/usr/bin/perl

use CGI;
$q = new CGI;

print $q->header,
	$q->start_html('QA Automation test');

open (FILE, '>>qacgiout.html') || die "ERROR";
print FILE '<BR>'.$q->param('textarea').'<BR>';
close FILE;

print '<script>window.location="qacgi.html"</script>',
	$q->end_html;

This means that you won't have to rely on a home-brew cgi-lib.pl, plus it
includes lots of page and form generation shortcuts.  Try 'perldoc CGI' from a
unix box.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Thank you for information Erik, about using free CGI library.
I'm going to make necessary changes to our driver.

Magically, this bug is been fixed with todays builds. I tested it with your
testcase as well as I tried to run our automation test and its running fine
today.

Thank you so much for fixes.
I'm marking this bug FIXED, and VERIFIED.
Status: RESOLVED → VERIFIED
URL: http://bubblegum/ngdriver/pratesting/... → http://bubblegum/ngdriver/pratesting/...
Status: VERIFIED → REOPENED
Target Milestone: M13
Resolution: FIXED → ---
Seems like this bug is bugging our automation again.
Reopening bug. This time there is little change in URL specified, since I
changed HTML code in testcase according to Erik's suggestions.

BUILDS: 2000-01-20.

STEPS TO REPRODUCE:
Please follow steps provided earlier. But please copy new HTML file I'm going to
provide. Or you can just visit URL mentioned above.

EXPECTED RESULTS and ACTUAL RESULTS are allready mentioned above.

NEW HTML TESTCASE START:

<HTML>
<HEAD>
<TITLE>NGDriver</TITLE>
<script>
<!--
function fixSubmit() {
   document.results.submit();
}
//-->
</script>
</HEAD>
<BODY onLoad="fixSubmit();">
Clic to See Results: <a
href=http://bubblegum/ngdriver/results/prashantdesale.html
target=results>desaletest.html</a><br><br>
<FORM name="results" action="/ngdriver/cgi-bin/prashant1.cgi" method="post">
<INPUT name=resultsfile type=hidden value=prashantdesale.html>
<input type="hidden" name="textarea" value="Input Hidden Data ">
</FORM>
</BODY>
</HTML>

NEW HTML TESTCASE END:

NEW CGI CODE START:

#!/usr/sbin/perl
require "cgi-lib.pl";

MAIN:
{


    &ReadParse(*input);

    print &PrintHeader;

    #Next line for NT
    chdir("e:\\WebDocs\\NGDriver");
    $resultsdir = "results";
    $resultsfile = $input{'resultsfile'};
    $s = $input{'textarea'};

    open(hFILE, ">>$resultsdir/$resultsfile") || die "ERROR";
    print hFILE "<br>$s<br>";
    close(hFILE);
    print
"<script>window.location='http://bubblegum/ngdriver/pratesting/test3.html';</scr
ipt>";

}

1; # return true

NEW CGI CODE END:

Setting Target Milestone to M13.
Celaring Resolution.
Blocks: 11349
Yes, I am able to reproduce this too.

It seems that either:
 1) setting window.location is not having any effect or (more likely)
 2) the onload handler isn't being fired.

This sounds a lot like a bug I noticed last night, bug 12432
Status: REOPENED → ASSIGNED
I've put my testcase up inside the firewall at:
http://blueviper.mcom.com/forms/ngdriver.html

The html and CGI are equivalent to yours (using the CGI library because I don't
have your cgi-lib.pl).  I added a "dump('About to submit form');" to the onload
handler of ngdriver.html so we could see if the onload handler was firing.  I
get the following output to the console when I run the CGI:

FindShortcut: in='http://blueviper/forms/ngdriver.html'  out='null'
failed to set the page title.
about to submit form.
Document http://blueviper/forms/ngdriver.html loaded successfully
Document: Done (0.681 secs)
title string = [NGDriver - Mozilla]
title string = [QA Automation test - Mozilla]
failed to set the page title.
Error loading URL http://blueviper/forms/ngdriver.cgi 
Document: Done (1.734 secs)
failed to set the page title.
Document http://blueviper/forms/ngdriver.html loaded successfully
Document: Done (0.84 secs)
title string = [NGDriver - Mozilla]

The two interesting things to note is "Error loading ngdriver.cgi" and no onload
handler is fired the second time ngdriver.html is loaded (else we would see a
second "About to submit form".

CC'ing Tom Pixley on this one. (And Rick because this may be network related)

This is really interesting that we get this error "Error loading ngdriver.cgi", 
and onLoad is also not firing.
On top of that, one more interesting thing I found out with your testcase is, 
sometimes it stops submitting the firm second time, but some times it really 
does submit form repetative. If I try to load page again and again, then 
sometimes it start working properly [What we expect], but most of the times it 
does not. This concludes that problem si not in Form Submission or so, its 
something else.
May be network.

When we get the error "Error loading URL ngdriver.cgi", I see the a request from
the cgi to go to a new location on the stack (LocationImpl::SetHrefWithBase)

This causes the webshell to start a new request, but first it calls
nsDocLoaderImpl::Stop (in nsWebShell::StopBeforeRequestingURL).  This calls
nsLoadGroup::Cancel which sets an error code (NS_BINDING_ABORTED)  This error
code gets propagated through to nsBrowserInstance::OnEndDocumentLoad where the
error message is printed out.

All that is to say that the Error message is probably nothing important, because
it's just saying "We stopped loading the CGI in the middle and started loading
th html" and that's what is supposed to happen based on what the CGI tells the
browser to do.
Whiteboard: [PDT+] → [PDT+] no fix in hand yet. test stopped working some time in the last week
Giving this to Tom because it looks like possibly a dup of 12432.
Assignee: pollmann → joki
Status: ASSIGNED → NEW
Component: Form Submission → Event Handling
As Warren suspected, this is not a necko bug - I set a breakpoint 
in nsWebShell::OnEndDocumentLoad and this is called even 
when the onLoad handler for the page is not evaluated.

I also just noticed that the "failed to set page title" message that we 
see every page load (including the one where the page's onload 
handler is not evaluated) is also registered as an onload handler 
via javascript (xpfe/browser/resources/content/navigator.js), and it 
*is* being called.

So, webshell is being notified by netlib that the load
has completed and webshell is calling at least some of
the onload event handlers all of the time.  Strange...

I agree with Eric, this is a dupe of 12432.  However, since this bug already has 
all the pertinent status I'll dupe that one onto this.

For testing, though, the test case on 12432 is a much simpler one and I'd 
recommend using that one.  So this is what I'm seeing, in both cases.

The first time we load the page I get what I expect.  I get a webshell Embed 
followed by an EndDocumentLoad.  However, when I reload the page I get an 
EndDocumentLoad followed by an Embed.  We keep a lot of state based on the embed 
call since that is when we (at the js level) are notified of the old document 
going out and the new coming in.  We cannot get the onload for the new document 
before we're told about it.  It doesn't work.

The reason that Eric is seeing on onload fire is that the event is firing as 
expected.  However, at the time it fires the new handler has been registered 
with the previous document's state still in place and doesn't work.  The onload 
handler Eric mentions in navigator.js lives in the window above the content 
frame/window and doesn't have to be cleared and re-registered correctly as this 
one does.

I'm still not sure who owns this but I'll take a guess at rpotts.  He can 
probably at least re-target this bug more effectively than I.
Assignee: joki → rpotts
*** Bug 12432 has been marked as a duplicate of this bug. ***
QA Contact: cpratt → desale
Actually this problem was seen first time in 2000-01-14-09 builds. 
It was fine on 2000-01-13 builds. This information might help you where you 
exactly made changes. After 2000-01-13, its broken in all the builds. I tested 
all the builds after 01-13. 2000-01-13 is running fine.
rpotts is sleeping in an ice hotel in Sweden.  Maybe warren can retarget this.
Assignee: rpotts → warren
Going on the above hint (bug appeared on 1/13), I noticed that memory cache was
enabled that day (gordon@netscape.com), tried disabling it and this bug went
away.

Add this line to your prefs.js to try it yourself:
user_pref("browser.cache.enable", false);

I don't know if it's memory cache that causes this bug or just the speed of the
memory cache that exposes this bug.  At any rate, changing component to
Networking: Cache to investigate that area.
Component: Event Handling → Networking: Cache
No Erik. Bug appeared on 01-14. 01-13 was fine. 
The Memory cache was enabled on the 13th, so it would have been first picked up 
by the verification builds on the 14th.  Since Erik has tested this with the 
cache turned off, and the bug disappears, it does look like the cache is a 
factor.  Adding fur, and davidm to the cc list for their amusement.

Okay, I don't quite get the output of the test case on bug#12432.  With mozilla I 
get "Load 1 was executed successfully", the first time and on reloads.  With 4.7 
I get "Load 1 was NOT executed successfully", all the time.  What am I doing 
wrong?

Surprising that this is affected by enabling the cache since HTTP POSTs 
(theoretically) do not call any cache-related code.  See:

http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHTTPChannel.
cpp#673
Fur, it's not the POST that is causing the problem, but loading a standard html
file with an onload handler.  See bug 12432 for a reduced test case.  And the
problem in *this* test case is when loading ngdriver.html (qacgi.html)

Gordon, I can't explain why the testcase fails in nav either - perhaps I'm not
document.writing something valid or ???  But it does work the first time you
load it in Gecko, then fails every time you hit reload after that.
I think Tom's explanation above (10:24 AM today) is the closest we have to
what's going wrong - are the nsWebShell::Embed and the OnEndDocumentLoad both
driven from the same thread?  Is there a way to prevent the OnEndDocumentLoad
from firing until after the Embed call completes?
I tried debugging this in viewer and set a breakpoint in the following three
places:

A  nsWebShell::Embed
B  nsHTTPResponseListener::OnStopRequest
C  nsWebShell::OnEndDocumendLoad

The requirement for this bug to be fixed is for A to come before C
I notice that B always seems to leads to C, so let's see what's up with B?

Then I browsed over to: http://blueviper.mcom.com/forms/x.html the breakpoints
were hit in this order: A B B C

Then I clicked on the URL bar and hit Enter to reload the document.  The
breakpoints were hit in this order: B C A B

It seems there are always two StopRequests sent (why?) and one always comes
after the Embed.  The one that comes before in the failing case causes the
OnEndDocumentLoad to be fired before the Embed call, which breaks the testcases.
Updating Summary.
Summary: [BLOCKER] dogfood [TESTCASE]Can not submit same form second time to same cgi if we call same page from cgi again. → [BLOCKER] dogfood [TESTCASE] OnLoad handler not called if page comes from memory cache
Eric -- it seems like you're on this one. Reassigning to you.
Assignee: warren → pollmann
I'm just on this as it's holding M13 and I don't have any other M13 issues to
work on.  I've got 88 bugs that don't want me to be on it, but it's blocking me
and everyone else.

Much as I'd like to say so, I can't claim to know more than the tiniest inkling
of netlib and even far, far less about how the memory cache works.  Isn't there
an owner for these areas that would like to step up?
Ok, how about Gordon?
Assignee: pollmann → gordon
This bug may have been fixed by Jud's change to nsCacheEntryChannel.cpp to fix 
bug 24250, earlier this afternoon.  It seems to be fixed on Mac, and I'm testing 
Linux now.

Works for me on Linux, cool!
Works form me on all three platforms.  We have Scott MacGregor and Jud Valeski to 
thank for this one.  Their changes for bug #24350 are what fixed this. That bug 
had similar problems of calls completing out of order. Marking fixed.
Status: NEW → ASSIGNED
Marking Fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
I tested this one today, and everything is working perfect now!!!!!!!!!!!!!!!1
Thank you all for putting so many efforts to make it work. This one was pretty 
important for us in order to run our automation harness. AND IT WORKS FINE NOW.
Marking it verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.