When I refresh a page and display a value that was
sent along to the server as a cookie, the value that I get
from the server is not "foo" but "foo," (note extra comma).
The page that I'm setting up the test for (we're to
change some parts of our GUI) does not do this when I
repeat the same input I'm putting into the test.
Attached test (that fails due to the presumed bug) works
as follows.
I store an email adress in a cookie and show the user
the current adress in a text input field. The user can
change the email value by entering a new adress in a
text input field and submitting.
I now try to test that I
a) get a correct default value (OK)
b) can set the value of the text field (i.e. change the
field value, then submit the form) and get the new value
displayed (OK)
c) refresh the page and see that the new setting remains
(it does, but with a ',' added at the end)
The lines that show the problem are
HtmlForm form = page1.getFormByName
("clabSettings");
HtmlTextInput textField = (HtmlTextInput)
form.getInputByName(CLabConstants.EMAIL);
// Tests no value from start
assertEquals(originalAdress,textField.getValueAttribute
());
// Test setting new adress
textField.setValueAttribute(testAdress);
// submission by javascript
HtmlPage page2 = (HtmlPage)form.submit();
form = page2.getFormByName("clabSettings");
textField = (HtmlTextInput)form.getInputByName
(CLabConstants.EMAIL);
assertEquals(testAdress, textField.getValueAttribute());
// Test that adress remains changed
page1 = (HtmlPage)webClient.getPage(url);
form = page1.getFormByName("clabSettings");
textField = (HtmlTextInput)form.getInputByName
(CLabConstants.EMAIL);
// *** BUG HERE! ***
assertEquals(testAdress, textField.getValueAttribute());
testAdress now contains "foo" and textField.getValue..
contains "foo,"
The stacktrace from the failing test is below.
I run HTMLUnit 1.2.2 , but 1.2.1 was the same
(downloaded 1.2.2 this afternoon). The test was run with
JBuilder 8's internal testrunner.
Hope that this is any help!
Yours sincerely,
Anders Egneus
junit.framework.ComparisonFailure: expected:<...> but
was:<...,>
at junit.framework.Assert.assertEquals
(Assert.java:81)
at junit.framework.Assert.assertEquals
(Assert.java:87)
at
settingspage.SettingsHTMLUnitTest.testAdress
(SettingsHTMLUnitTest.java:71)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke
(Method.java:324)
at junit.framework.TestCase.runTest
(TestCase.java:154)
at junit.framework.TestCase.runBare
(TestCase.java:127)
at junit.framework.TestResult$1.protect
(TestResult.java:106)
at junit.framework.TestResult.runProtected
(TestResult.java:124)
at junit.framework.TestResult.run
(TestResult.java:109)
at junit.framework.TestCase.run
(TestCase.java:118)
at junit.framework.TestSuite.runTest
(TestSuite.java:208)
at junit.framework.TestSuite.run
(TestSuite.java:203)
at
com.borland.jbuilder.unittest.JBTestRunner.run
(JBTestRunner.java:206)
at
com.borland.jbuilder.unittest.JBTestRunner.initiateTest
(JBTestRunner.java:248)
at
com.borland.jbuilder.unittest.JBTestRunner.main
(JBTestRunner.java:554)
Logged In: YES
user_id=46756
The cookie support is actually handled by commons-httpclient
and not by HtmlUnit itself so the first thing I'd like you
to try is a newer version of commons-httpclient to see if it
fixes the problem.
The nightly gump builds can be found at
http://gump.covalent.net/jars/latest/jakarta-commons/
Logged In: YES
user_id=746184
I've tried using the 030410 build of commons-client (taken
from the nightly builds on the Jakarta site), but the problem
remains.
(And gump.covalent.net seems to be very much offline.)
Logged In: YES
user_id=46756
If I'm reading this correctly, the problem is with the value
being passed down in a text field, not in a cookie. Can you
look at the html being send down from the server? The html
as sent by the server can be retrieved with
page.getWebResponse().getContentAsString()
The html after it's been cleaned up by NekoHTML can be
retrieved with
page.asXml()
Can you see if the comma is present in either one of these?
Logged In: YES
user_id=746184
The comma is present in both.
The value that is put into the textfield (the value with the extra
comma) is read by the server from a cookie, so I still think
the problem lies in the cookies....
I.e the flow is
1)Browser sends submit form with value X to server
2)Server send Set-Cookie with value X to browser (along with
new page). (Correct values are recieved, both in the cookie
form and as html)
3)Browser requests page.
4)Server responds, including textfield value "X,".
So it seems to me either the browser stores the cookie with
an extra comma (unlikely ?) or passes it to the server with an
extra comma added (little more likely). I don't think the error
is on the server side since the extra comma doesn't appear
when I do the same submission manually.
I looked at the cookie sent along with the server's response to
the submit and this was correct (no comma).
After that I tried to access the state of the HttpClient
reponsible for the URL to look at the current cookie set after
the form submission, but rebuilding HtmlUnit failed (I seem to
be missing .base.testing.BaseTestCase).
Logged In: YES
user_id=46756
I'll answer the simple part first: BaseTestCase is part of
the GSBase project (which I also maintain) and can be found
at http://gsbase.sourceforge.net
If the problem really is with the cookie support then we'll
have to log a bug with commons-httpclient - none of that
support is actually handled inside HtmlUnit. That's why I
hoping it really isn't a cookie bug - I can fix HtmlUnit
bugs ;-)
Logged In: YES
user_id=746184
OK, that's what I figured too (about a bug in httpclient).
I think a prudent course now would be for me to get
BaseTestCase and try to get access to the Cookies in
httpclient and check what's happening there. I'm not going to
be in the office for the rest of the week but I'll give it a shot
next week. I'll post here once I have something more to say.
Have a nice (bug-free :) Easter!
Logged In: YES
user_id=746184
The cookies don't have the extra comma. ( I went into the
HttpWebConnection and looked at the Cookies in the
HttpState).
I'm also getting another test failure which I think may be
caused by the same bug:
I have another cookie which I set to a value of either X, Y or
Z (default). The server sets a radio button depending on this
cookie value. (The server looks for X or Y, if they are not
present it uses Z.) Now the cookie is stored correctly as X,
so I would expect the X button to be checked, but what gets
checked is the default, Z.
I now believe the test fails when http-client somehow adds a
comma turning "X" into "X,", resulting in no match and the
server going to the default.
As the cookie values are correct, it looks as if something
happens when the cookies are sent to the server. Anything
else you can think of that I should try before we talk to the
commons-httpclient people?
Logged In: YES
user_id=746184
The cookies don't have the extra comma. ( I went into the
HttpWebConnection and looked at the Cookies in the
HttpState).
I'm also getting another test failure which I think may be
caused by the same bug:
I have another cookie which I set to a value of either X, Y or
Z (default). The server sets a radio button depending on this
cookie value. (The server looks for X or Y, if they are not
present it uses Z.) Now the cookie is stored correctly as X,
so I would expect the X button to be checked, but what gets
checked is the default, Z.
I now believe the test fails when http-client somehow adds a
comma turning "X" into "X,", resulting in no match and the
server going to the default.
As the cookie values are correct, it looks as if something
happens when the cookies are sent to the server. Anything
else you can think of that I should try before we talk to the
commons-httpclient people?
Logged In: YES
user_id=746184
One more thing; I've tested it using the latest (0422)
commons-httpclient.
Logged In: YES
user_id=46756
Nothing else I can think of.
Logged In: YES
user_id=746184
Case closed. The bug isn't in HtmlUnit, it isn't in HttpClient, it
is in the python module Cookie.py, as run on our SGI
machines.
:( Sorry for wasting time.
I did a little more digging before going to the HttpClient list,
and the output from HttpClient was legal, with only one
comma separating cookies. I've narrowed the error down to
pyhton module that handles cookies, and I think the problem
lies in the python version that we use on our SGI machines
(there are a couple of other bugs in it that are not there when
we run python on other machines). Once I move the code to a
Linux system expect to use HtmlUnit as part of my testing
battery.
Once again, thanks for taking the time to look at this. We
can at least put it to rest.
Logged In: YES
user_id=46756
No problem - I'm just glad it's resolved.