[Webtest] Enabling disabled fields

Lisa Crispin webtest@lists.canoo.com
Fri, 05 Aug 2005 15:34:23 +0000


In case anyone else has this issue, I wanted to post how I got this to work.

In the email below, I describe my problem and Paul gave me a solution.  We tried this awhile back and couldn't get it to work.  I was desperate to get it working so I tried again today and bingo! 

The html has:
<INPUT id="annualDiscount" tabindex="1" value="$0.00" maxLength="14" type="text" size="10" name="annualDiscount" style="text-align:right;" disabled></TD></TR> 

The webtest script has:

	<emulateSetElementAttribute description="enable the est discount"
	        name="establishmentDiscount" attributeName="disabled" attributeValue=""/>

This enables the field so that the value I set in it is accepted, and the submit works.

Thanks SO much, Paul!
-- Lisa

-------------- Forwarded Message: --------------
From: Paul King <paulk@asert.com.au>
To: webtest@gate2.canoo.com
Subject: Re: [Webtest] javascript that disables/enables fields
Date: Fri, 25 Mar 2005 00:36:26 +0000


Lisa Crispin wrote:
> This is another one of those questions where I'm not sure if I know
> enough to ask an intelligent question!
>
> We have a page (in our old system, unfortunately) which has a ton of
> javascript on it that disables a bunch of fields to start with, then
> depending on what items the user selects on the page, re-enables them.
> The re-enabling of the fields in the DOM is not happening when I run the
> WebTest script. It works fine when I actually use the page through a
> browser. It seems like the javascript that would re-enable is not being
> run. Any idea s?
>
> We don't have any unit tests for this page because our old system is too
> horrible to write unit tests for, so WebTest is our only hope (and it's
> a brittle page that breaks easily, so it needs tests!).
> thanks,
> Lisa

I have added two experimental steps to build 760 which might help.
They are a bit lower level than I would like and should be used with
caution but seem to be needed. If people can try them out and let
me know if they are suitable then I will add tests and documentation.
They assist getting around tricky JavaScript problems but should be
considered non-preferred compared with fixing/improving HtmlUnit's
JavaScript support. There is no documentation yet. I didn't want
people to rush into using these steps as they will be subject to
change based on feedback.

The first step is storeElementAttribute. It is a modified and
extended version of the verifyhtmlelement enabled step which
Vikram Shitole sent to the list a couple of weeks ago. It currently
only works with Input elements in html. Here are some examples:

elementName="c1" attributeName="checked"/>

elementName="c1" attributeName="disabled"/>

elementName="c2" elementValue="check2" attributeName="checked"/>


If the attribute doesn't exist, "false" is returned;
if the attribute exists but is empty, "true" is returned;
otherwise, the value of the attribute is returned.

I imagine this will mainly be used with the disabled attribute but
it should work with other attributes such as "checked", "readonly",
"size" , "maxlength", "alt" etc. Though you should probably consider
using storeXPath most of the time. This might be useful for non-input
elements as well. Let me know if anyone can see a use case for this
potential extension.

The other step is emulateSetElementAttribute. Again this is just for
input elements at the moment. Here is an example (third step):

elementName="c1" attributeName="disabled"/>

attributeName="disabled" attributeValue="true"/>
elementName="c1" attributeName="disabled"/>


This would be used where JavaScript would normally change the
attribute but where that is currently not working. (Again this
should be treated as a temporary workaround and getting JS to
work should be attempted in parallel).


Cheers, Paul.