[Wtr-general] Wait issue with file_field.set, solution

[Ethan Jewett]

I think that the addition of the "click" to file_field.set in this
change (see thread below) is causing one of my tests to hang during
the @container.wait in the "click" method.  However, this problem
didn't show up until after the changes to the wait functionality in
mid-February.  Or so my theory goes . . .

The fix, in my case, is to change the "click" to a "click!" in
file_field.set, by-passing the @container.wait in the click method.  I
suppose I could use a time-out technique instead.

I can't provide a test case, unfortunately, because I don't have a
handle on all the javascript eventing and fancy ajax-y reload in
various frames that's going on in a generated SAP business server
pages app.  I think this is a relatively well-known issue with
ajax-like apps.  Please correct me if I'm wrong.

Attached is a patch to the 1.5.1163 revision that illustrates the way
I've modified watir.rb to allow me to specify wait behavior in the
file_field.set method.  The "watir 1.5.1163 - no_wait option in
file_field.set.patch" basically throws any extra arguments on
file_field.set into an args_hash Hash.  The "set" method then checks
for the :no_wait key and either "click"s or "click!"s based on that
key.

So,

file_field.set(path)  results in a "click"
file_field.set(path, :no_wait => false) results in a "click"
file_field.set(path, :no_wait => true) results in a "click!"

The upside here is that this doesn't change existing behavior.  The
downside is that it is kind of a hack as it stands.

I think that implementing this sort of functionality in a more general
(and perhaps better thought-out) way would give a lot of flexibility
to those of us dealing with ajax goodness to manually override wait
functionality when necessary.  It might also be a reasonably standard
way to allow granular control of other functionality on a method-call
by method-call basis.

Is this reasonable?  Has something like this been decided against in
the past?  Is it too big a change for 1.5?  Thoughts on problems?
Improvements?  Maybe using :wait => false instead of :no_wait => true
would be more intuitive?

I don't think this patch is ready to go into the code-base as it
stands, even if people think it is a reasonable approach, but I'll
submit a Jira ticket once I have something that I think will work.

Thanks,
Ethan

On 1/10/07, Bret Pettichord <bret at pettichord.com> wrote:
> John Lolis wrote:
> > I registered AutoItX3.dll using regsvr32 and it got rid of the error message, the problem now is it doesn't fill in the field with any text. I can flash it, so i know I have the right field - I just can't put anything in there.
> >
> > any more ideas?
> >
>
> Today I checked in fixes for both this and the other problem (autoit
> registration). These are NOT in today's dev gem, but will be in the next
> one. You can pull them from trunk if you like.
>
> A workaround for this problem  for earlier versions of 1.5 is this:
>
> 1. Manually register autoit:
>
>      >regsvr32 AutoItX3.dll
>
> 2. Add a call to click:
>
>     ie.file_field(:id, 'DriverFileUpload_DriverFileUpload').set(filename)
>     ie.file_field(:id, 'DriverFileUpload_DriverFileUpload').click
>
> Please let us know if either of these solutions does not fix this
> problem for anyone.
>
> Bret
> _______________________________________________
> Wtr-general mailing list
> Wtr-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-general
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: watir 1.5.1163 - no_wait option in	file_field.set.patch
Type: application/octet-stream
Size: 858 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/wtr-general/attachments/20070307/e8683d5a/attachment.obj