Bugs item #707758, was opened at 2003-03-21 16:16
Message generated for change (Settings changed) made by jimweaver
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=707758&group_id=61302
Category: None
Group: Release 1.2
>Status: Closed
>Resolution: Out of Date
Priority: 8
Submitted By: Leo Parker (xanaguy)
Assigned to: Nobody/Anonymous (nobody)
Summary: html page gets replaced with linked script
Initial Comment:
sample.html:
<html>
<script src="script.js"></script>
<title>The Title</title>
</html>
MyWebTestCase.java:
public void test1() {
beginAt("/sample.html");
assertTitleEquals("The Title");
assertTextPresent("The Title"); // fails
}
The offending change happens at:
wc.addClientListener(new WebClientListener() {
public void requestSent(WebClient webClient,
WebRequest webRequest) {
}
public void responseReceived(WebClient
webClient, WebResponse webResponse) {
resp = webResponse; // <=- here!!!
form = null;
}
});
[HttpUnitDialog.java:83], but I suspect the problem is
somewhere else. (It might even be in
httpunit.HTMLPage.parse() in the inner class there.
I'm using jWebUnit 1.1.1 (modula the patch I sent in
yesterday) and HttpUnit 1.5.2, although HttpUnit 1.5
does the same thing.
Here's the stack trace when the offending substitution is
made:
Thread [main] (Suspended)
net.sourceforge.jwebunit.HttpUnitDialog$1.res
ponseReceived(com.meterware.httpunit.WebClient,
com.meterware.httpunit.WebResponse) line: 83
com.meterware.httpunit.WebConversation
(com.meterware.httpunit.WebClient).tellListeners
(com.meterware.httpunit.WebResponse) line: 432
com.meterware.httpunit.WebWindow.getRes
ource(com.meterware.httpunit.WebRequest) line: 162
com.meterware.httpunit.HTMLPage.getInclud
edScript(java.lang.String) line: 108
com.meterware.httpunit.HTMLPage$1.getIncl
udedScript(java.lang.String) line: 274
com.meterware.httpunit.parsing.DOMParser.
getIncludedScript(java.lang.String) line: 165
com.meterware.httpunit.parsing.ScriptFilter.st
artElement(org.apache.xerces.xni.QName,
org.apache.xerces.xni.XMLAttributes,
org.apache.xerces.xni.Augmentations) line: 86
org.cyberneko.html.HTMLTagBalancer.startEl
ement(org.apache.xerces.xni.QName,
org.apache.xerces.xni.XMLAttributes,
org.apache.xerces.xni.Augmentations) line: not available
org.cyberneko.html.HTMLScanner$ContentS
canner.scanStartElement(boolean[]) line: not available
org.cyberneko.html.HTMLScanner$ContentS
canner.scan(boolean) line: not available
org.cyberneko.html.HTMLScanner.scanDocu
ment(boolean) line: not available
org.cyberneko.html.HTMLConfiguration.parse
(boolean) line: not available
org.cyberneko.html.HTMLConfiguration.parse
(org.apache.xerces.xni.parser.XMLInputSource) line: not
available
com.meterware.httpunit.parsing.DOMParser
(org.apache.xerces.parsers.XMLParser).parse
(org.apache.xerces.xni.parser.XMLInputSource) line: not
available
com.meterware.httpunit.parsing.DOMParser
(org.apache.xerces.parsers.DOMParser).parse
(org.xml.sax.InputSource) line: not available
com.meterware.httpunit.parsing.NekoHTMLP
arser.parse(java.net.URL, java.lang.String,
com.meterware.httpunit.parsing.DocumentAdapter) line:
55
com.meterware.httpunit.HTMLPage.parse
(java.lang.String, java.net.URL) line: 272
com.meterware.httpunit.HttpWebResponse
(com.meterware.httpunit.WebResponse).getReceivedPa
ge() line: 945
com.meterware.httpunit.HttpWebResponse
(com.meterware.httpunit.WebResponse).getTitle() line:
88
net.sourceforge.jwebunit.HttpUnitDialog.getR
esponsePageTitle() line: 121
net.sourceforge.jwebunit.WebTester.assertTitl
eEquals(java.lang.String) line: 94
ScriptTestCase
(net.sourceforge.jwebunit.WebTestCase).assertTitleEqua
ls(java.lang.String) line: 52
ScriptTestCase.test1() line: 23
sun.reflect.NativeMethodAccessorImpl.invoke
0(java.lang.reflect.Method, java.lang.Object,
java.lang.Object[]) line: not available [native method]
sun.reflect.NativeMethodAccessorImpl.invoke
(java.lang.Object, java.lang.Object[]) line: 39
sun.reflect.DelegatingMethodAccessorImpl.in
voke(java.lang.Object, java.lang.Object[]) line: 25
java.lang.reflect.Method.invoke
(java.lang.Object, java.lang.Object[]) line: 324
ScriptTestCase
(junit.framework.TestCase).runTest() line: 154
ScriptTestCase
(junit.framework.TestCase).runBare() line: 127
junit.framework.TestResult$1.protect() line:
106
junit.framework.TestResult.runProtected
(junit.framework.Test, junit.framework.Protectable) line:
124
junit.framework.TestResult.run
(junit.framework.TestCase) line: 109
ScriptTestCase
(junit.framework.TestCase).run
(junit.framework.TestResult) line: 118
junit.framework.TestSuite.runTest
(junit.framework.Test, junit.framework.TestResult) line:
208
junit.framework.TestSuite.run
(junit.framework.TestResult) line: 203
org.eclipse.jdt.internal.junit.runner.RemoteTe
stRunner.runTests(java.lang.String[]) line: 329
org.eclipse.jdt.internal.junit.runner.RemoteTe
stRunner.run() line: 218
org.eclipse.jdt.internal.junit.runner.RemoteTe
stRunner.main(java.lang.String[]) line: 151
----------------------------------------------------------------------
Comment By: Vivek Venugopalan (vivekv)
Date: 2004-06-16 21:20
Message:
Logged In: YES
user_id=131737
I added a test case to try this out and found that this worked
fine with 1.2. I will commit the changed Test Case.
----------------------------------------------------------------------
Comment By: Jim Weaver (jimweaver)
Date: 2004-06-11 12:32
Message:
Logged In: YES
user_id=619947
This has been a fun one.
Post 1.2 release someone needs to revisit this issue and see
if we still have problems. I will not that, if I remember
correctly, the listener was added so that is a javascript
function ends up changing the response, that can be tested.
The listener method in HttpUnitDialog now doea a
webclient.getCurrentPage. This problem may now be fixed -
just needs to be verified with a unit test.
----------------------------------------------------------------------
Comment By: Jim Weaver (prospero2000us)
Date: 2003-09-22 12:00
Message:
Logged In: YES
user_id=597548
Hoping to resolve this for next release. It may be that the
listener was needed to update the response when javascript
is triggered that changes the response....
Jimbo
----------------------------------------------------------------------
Comment By: Peter Held (bianchi)
Date: 2003-09-15 16:24
Message:
Logged In: YES
user_id=867127
OK, I'm an idiot. Turns out that my junit.textui.TestRunner
problem was a missing 'js.jar' reference in my CLASSPATH.
Sorry folks.
----------------------------------------------------------------------
Comment By: Peter Held (bianchi)
Date: 2003-09-15 12:08
Message:
Logged In: YES
user_id=867127
Hi there. I'm not a Java expert yet, but I thought I'd mention
some strange behavior I saw which was related to this. I
have also had problems with the linked script issue. However,
when I run my JWebUnit tests through the Eclipse JUnit
plugin, they work fine. I have no idea what the difference is
between Eclipse running the tests and the command-line
junit.textui.TestRunner doing it.
Also, a little feedback on the latest fix suggested by
xanaguy. I tried commenting out the wc.addClientListener()
code in HttpUnitDialog.initWebConversation(), and found that
the form element assertions stopped working. This occured
when running the tests with junit.textui.TestRunner as well as
Eclipse.
----------------------------------------------------------------------
Comment By: Stefan Wasilewski (smw)
Date: 2003-07-07 12:09
Message:
Logged In: YES
user_id=18328
Ok, so xanaguy's patch breaks HttpUnitDialog.submit(String
buttonName) because it's relying on the clientListener.
Obviously, this is the wrong behavior, so here's the full fix.
First of all, in httpunit 1.5.3, Webform.submit(SubmitButton
button) is public, so we upgrade to that version. Then, we
change
getForm().getSubmitButton(buttonName).click();
to
resp =
getForm().submit(getSubmitButton(buttonName));
in HttpUnitDialog.submit(String buttonName).
Then we do as xanaguy says, and remove the
wc.addClientListener() from
HttpUnitDialog.initWebConversation().
----------------------------------------------------------------------
Comment By: Christian Hargraves (engrean)
Date: 2003-07-04 09:27
Message:
Logged In: YES
user_id=60860
I just posted that this worked for me. Let me correct
myself. This corrected that problem and just as the others
stated is did cause another problem. The new problem is that
I can no longer use the submit(nameOrId) function. The
strange thing is it doesn't error out, it just doesn't
sumbit the form. Therefore I had to use the submit() method
without the name in it.
----------------------------------------------------------------------
Comment By: Christian Hargraves (engrean)
Date: 2003-07-03 19:20
Message:
Logged In: YES
user_id=60860
This also solved my problem for bug #752078!
----------------------------------------------------------------------
Comment By: Leo Parker (xanaguy)
Date: 2003-05-16 12:41
Message:
Logged In: YES
user_id=565814
What other problem did this patch cause? Clearly the line I
removed shouldn't be there. If something else is relying on it,
then it's got other problems. What that line is doing is
making it so that any time ANYTHING makes an HTTP
request through HttpUnit it stores the received file as the
HTML file to be processed. That's not how it should work.
Anytime code gets a new HTML file to work on it should
store it manually, not through the HttpUnit callback.
----------------------------------------------------------------------
Comment By: Jim Weaver (prospero2000us)
Date: 2003-05-16 00:13
Message:
Logged In: YES
user_id=597548
Very belated response,
Yes, this has been a running problem. We made the same fix
you ended up making on one of our projects, but it caused a
problem for another project, so I have to spend some time
settling this one once and for all. bumping the priority.
jim
----------------------------------------------------------------------
Comment By: Leo Parker (xanaguy)
Date: 2003-03-21 17:24
Message:
Logged In: YES
user_id=565814
Apologies for the running dialog here. That last comment
wasn't quite right -- it is important to clear the form variable
when the response comes back. Otherwise it gets
inappropriately cached between pages. So...
I think you can fix this issue by commenting out line 83 of
HttpUnitDialog.java:
resp = webResponse;
----------------------------------------------------------------------
Comment By: Leo Parker (xanaguy)
Date: 2003-03-21 17:14
Message:
Logged In: YES
user_id=565814
Looking at this a bit more, I think the problem comes from
HttpUnitDialog.initWebConversation() where it calls
wc.addClientListener() -- this makes it so that anytime
HttpUnit fetches a file, it replaces our response. Why is this
here? I commented it out, and now my problem is solved. I
don't seem to have broken anything else, but I presume the
person who put that in there did so for SOME reason.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=497982&aid=707758&group_id=61302
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Jwebunit-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jwebunit-development
