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

VERIFIED FIXED in M13

Status

()

P1
blocker
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: desale, Assigned: gordon)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

(Reporter)

Description

19 years ago
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.
(Reporter)

Updated

19 years ago
Priority: P3 → P1
(Reporter)

Comment 1

19 years ago
Setting priority to P1.

Updated

19 years ago
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.

Comment 2

19 years ago
Reassigning to Kevin.
Assignee: karnaze → kmcclusk

Updated

19 years ago
Assignee: kmcclusk → pollmann
Reassigning to Eric

Updated

19 years ago
Whiteboard: [PDT+]

Updated

19 years ago
Status: NEW → ASSIGNED
Hardware: PC → All

Comment 4

19 years ago
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.
(Reporter)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Reporter)

Comment 5

19 years ago
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.
(Reporter)

Updated

19 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Updated

19 years ago
Status: VERIFIED → REOPENED
Target Milestone: M13
(Reporter)

Updated

19 years ago
Resolution: FIXED → ---
(Reporter)

Comment 6

19 years ago
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.
(Reporter)

Comment 7

19 years ago
Celaring Resolution.

Updated

19 years ago
Blocks: 11349

Comment 8

19 years ago
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

Comment 9

19 years ago
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)
(Reporter)

Comment 10

19 years ago
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.

Comment 11

19 years ago
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.

Updated

19 years ago
Whiteboard: [PDT+] → [PDT+] no fix in hand yet. test stopped working some time in the last week

Comment 12

19 years ago
Giving this to Tom because it looks like possibly a dup of 12432.
Assignee: pollmann → joki
Status: ASSIGNED → NEW
Component: Form Submission → Event Handling

Comment 13

19 years ago
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...

Comment 14

19 years ago
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

Comment 15

19 years ago
*** Bug 12432 has been marked as a duplicate of this bug. ***

Updated

19 years ago
QA Contact: cpratt → desale
(Reporter)

Comment 16

19 years ago
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.
(Assignee)

Comment 17

19 years ago
rpotts is sleeping in an ice hotel in Sweden.  Maybe warren can retarget this.
Assignee: rpotts → warren

Comment 18

19 years ago
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
(Reporter)

Comment 19

19 years ago
No Erik. Bug appeared on 01-14. 01-13 was fine. 
(Assignee)

Comment 20

19 years ago
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.
(Assignee)

Comment 21

19 years ago
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?

Comment 22

19 years ago
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

Comment 23

19 years ago
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.

Comment 24

19 years ago
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?

Comment 25

19 years ago
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.

Comment 26

19 years ago
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

Comment 27

19 years ago
Eric -- it seems like you're on this one. Reassigning to you.
Assignee: warren → pollmann

Comment 28

19 years ago
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?

Comment 29

19 years ago
Ok, how about Gordon?
Assignee: pollmann → gordon
(Assignee)

Comment 30

19 years ago
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.

Comment 31

19 years ago
Works for me on Linux, cool!
(Assignee)

Comment 32

19 years ago
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
(Assignee)

Comment 33

19 years ago
Marking Fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
(Reporter)

Comment 34

19 years ago
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.