[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.