Problem while setting value for "<select>" in a form.
Brought to you by:
russgold
Menu
▾
▴
#297 Problem while setting value for "<select>" in a form.
Problem while setting value for "<select>" in a form.
I am getting the following exception
1) testCart(BBYSmokeTestCase)
com.meterware.httpunit.IllegalParameterValueException:
May not set parameter 'DrpState' to 'AL'. Value must be
one of: { }
at
com.meterware.httpunit.SelectionFormControl$Options.r
eportNoMatches(FormControl.java:1184)
at
com.meterware.httpunit.SelectionFormControl$SingleSel
ectOptions.claimUniqueValues(FormControl.java:1358)
at
com.meterware.httpunit.SelectionFormControl$Options.c
laimUniqueValues(FormControl.java:1176)
at
com.meterware.httpunit.SelectionFormControl.claimUniq
ueValue(FormControl.java:1057)
at
com.meterware.httpunit.FormParameter.setValues
(FormParameter.java:90)
at com.meterware.httpunit.WebForm.setParameter
(WebForm.java:612)
at com.meterware.httpunit.WebForm.setParameter
(WebForm.java:601)
at BBYSmokeTestCase.testCart
(BBYSmokeTestCase.java:442)
at sun.reflect.NativeMethodAccessorImpl.invoke0
(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(Unknown Source)
When I try to set the value for a list box (<select
name="DrpState") in the page.
On further analysis I found that if the page's "<html>"
tag contains a xml namespace like below
<html xmlns="http://www.w3.org/1999/xhtml"
lang="EN">
,I am getting the error.
If I remove the "xmlns" and put it as a plain "<html>", I
am not getting the above error.
I have attached the sample html file (3.html).
Since all the pages are in production, it is not possible
to remove the "xmlns"
(Also I am not sure why they have used it.).
Please also let me know if there are any other ways of
setting the value without removing
the xml namespace.
Below is the HttpUnit code I am using.
public void testCart() throws Exception
{
WebConversation webConversation = new
WebConversation();
WebResponse response =
webConversation.getResponse(
"http://localhost/3.html");
WebForm billingAdd =
response.getFormWithName("frmBillAddress");
//EXCEPTION OCCURS IN THIS LINE
billingAdd.setParameter("DrpState","AL");
//response = billingAdd.submit();
}
Html file I used for simulating the above problem
Logged In: YES
user_id=1088017
This is similar to the problem I have, which seems to be
localized to the nekohtml parser. Can you add which parser
you are using so that the bug report is more complete. I
really, really, really need this bug fixed as well.
Logged In: YES
user_id=1284355
I am not sure of the version of the nekohtml.jar.
But this came as a part of the httpunit-1.6.zip.
It says Version 1.0 in the License file and it of size 66 kb.
Logged In: YES
user_id=1088017
I have discovered that the problem is one of
case-sensitivity. When using the nekohtml library, the
parser factory is defaulting to the nekohtml default, which
is to switch the case of all tag names to "upper". This
leads to a problem in the Option class, which executes the
method call:
getElementsByTagName("option");
thus explaining why no options are ever found. Since jtidy
seems to lowercase all tag names and attribute names, it
would make sense to just force the nekohtml parser to do the
same.
The following patch will do the trick:
line 63-66 of NekoDOMParser should be:
else {
configuration.setProperty( TAG_NAME_CASE, "lower" );
configuration.setProperty( ATTRIBUTE_NAME_CASE,
"lower" );
}
This will force tags and attribute to lowercase in the
default configuration of not preserving case.
Unfortunately, jtidy cannot preserve case, but can only
force the case up or down. Since HttpUnit code always
assume lower case, it makes sense to use this as the default.
Logged In: YES
user_id=1284355
I applied the patch and found that it is working fine.
Also when I removed the Nekohtml parser from the classpath
it is taking JTidy and it is working fine.
Thanks
Logged In: YES
user_id=1088017
Excellent! I would love to see this patch applied into CVS
head.
Also, did you know that you can manually adjust which parser
is going to be used by calling the following method:
HTMLParserFactory.useJTidyParser()
HTMLParserFactory.useNekoHTMLParser()
That way you don't have to keep changing your classpath.
That got old after about 10 minutes.
Logged In: YES
user_id=1281953
Sorry if this is a wrong place to continue this discussion.
i manually applied the patch to NekoDOMParser, but it
broke some of my other code. I resorted to adding:
HTMLParserFactory.useJTidyParser()
which seemed to solve my problem so far.
By the way is JTidy the same as Tidy.jar in the
jars dirictory?
Logged In: YES
user_id=1281953
Sorry if this is a wrong place to continue this discussion.
i manually applied the patch to NekoDOMParser, but it
broke some of my other code. I resorted to adding:
HTMLParserFactory.useJTidyParser()
which seemed to solve my problem so far.
By the way is JTidy the same as Tidy.jar in the
jars dirictory?
Logged In: YES
user_id=1220573
Originator: NO
Dear Anand,
we are in the process of changing to a new version of Neko. With a test case we might be able to check the problem in more detail.
Yours
Wolfgang
Logged In: YES
user_id=1220573
Originator: NO
Dear httpunit user!
Thank you for your bug report. We appreciate the time and effort you are putting into this.
Please supply a testcase with the expected result for the bug report that you are asking a solution for and we'll look into implementing it. For a start you might want to get the trunk version from the subversion repository (see https://sourceforge.net/svn/?group_id=6550\)
and have a look at the source code of some of the more than 700 JUnit based testcase in there.
This should give you a clue on what a proper testcase for httpunit looks like.
When you are ready you might want to attach the testcase (and if you already have started implementing a solution for it it also the actual code) to the patch section of the sourceforge.net tracker for patches of the httpunit project at
https://sourceforge.net/tracker/?atid=306550&group_id=6550&func=browse.
The main communication about further details of the development is via the httpunit developer mailinglist. You are most welcome to sign up via
https://lists.sourceforge.net/lists/listinfo/httpunit-develop
Yours
The httpunit developer team
(Russell and Wolfgang as of 2008-03)
Logged In: YES
user_id=1220573
Originator: NO
The "OPTIONS" issue has been fixed a while ago.
Uppercase / Lowercase tag handling is now also available in the upcoming 1.7 release