[Windmill-dev] https; file uploads; extjs and click support

[Adam Christian]

A bit more interesting findings on this issue:

This actually works round trip in Safari and probably IE as those  
browser don't allow you to prevent the propagation of events the same  
way that firefox does. Additionally as the ID's for these elements  
actually change every single time you click on them, you have to use  
xpath which is being recorded OOTB in Safari, even though they have  
ID's.

The most frustrating part about this is that I have discovered that  
the JS library has actually stopped propagation for both click and  
mousedown, which means that I would have to do a bunch of logic  
involving, looking for the mouseup and then check to see if the  
previous action was a mousedown, if not, that means that they stopped  
its propagation and I can create a click or mousedown/mouseup.

Now if the JS library  put a stop propagation on mousedown, mouseup  
and click, without individually  attaching our own listeners on every  
element in the DOM we have no way to catch them.

I guess the biggest question is:

At what point to we put this blame on the JS library and expect our  
users to create these manually as they have been specifically made  
them very difficult to automate?

Adam

On Dec 16, 2007, at 12:18 PM, Adam Christian wrote:

> Hello, thank you for trying out windmill! Comments inline:
>
> On Dec 16, 2007, at 9:10 AM, Gary Poster wrote:
>
>> Hi.  I talked with Mikael on IRC yesterday: thank you again!
>>
>> I mentioned to him that we needed https for our app, and he said  
>> that it was hard, but in progress.  That's great to hear.
>>
>> In exploring Windmill some more today I encountered a couple of  
>> other problems.
>>
>> The first is that I don't see a work-around for file uploads.  For  
>> what it's worth, Sahi, which appears to have a similar basic  
>> approach to Windmill's, does this for the problem: http://sahi.sourceforge.net/apis.html#setFile 
>>  .
>>
>> Any chance you all might have a solution for file uploads coming  
>> soon?
> I'll let Mikeal take this one, I know it's on our list but It will  
> certainly be moved up in priority since we know there are some user  
> waiting for it.
>
>> The second is that Windmill is missing quite a few important clicks  
>> in extjs.  For instance, try recording on this page: ``windmill  
>> firefox http://extjs.com/deploy/dev/examples/grid/edit- 
>> grid.html`` .  If you click the checkboxes on the right, nothing  
>> happens in the recorder; and if you use the calendar widgets, it  
>> won't see the click on a number.  The checkboxes are not real  
>> checkboxes, but I have the "Absolute click sensitivity when  
>> recording:" option turned on.  I don't know about selenium or sahi  
>> on this page.
>>
>> Is this a bug that you all are willing to address?
> Short answer, absolutely.
>
> We recently have had some other user responses with similar issues.  
> When a click happens, we wait for it to bubble up to the window  
> object and then record that it happened, (except in IE where various  
> events require that you walk the DOM and manually attach events). In  
> these cases that we have seen breaking, the JavaScript libraries  
> being used (extjs and YUI) are preventing the event from bubbling/ 
> propagating which keeps them from being recorded.
>
> The second part of this issue is that manually creating a click on  
> those 'checkboxes' (which are actually just DIV's with a transparent  
> background image) will click on the element, unfortunately it won't  
> trigger the event giving you the expected results because it is  
> actually listening for a mousedown and not a click. Strangely in our  
> click method we do simulate mousedown and mouseup, but I am seeing  
> an error persisting preventDefault.
>
> As for a solution, I think this may actually come down to a  
> consensus from the list:
>
> First solution: When JavaScript disables the event propagation for  
> click, do we record mouseup and mousedown instead of the click? As  
> playing this back does seem to work for this particular scenario.
>
> Second solution: When we see a mousedown, we assume they mean click,  
> or we devise some logic to go analyze the element being mousedowned  
> and see if they might have meant click.
>
> Three: We take over the whole app and remove the stop propagates!
>
> Any of these would work, but I think the first would be the least  
> disruptive in terms of testing an app in it's native state.
>
> Adam
>
>
>> Thanks
>>
>> Gary
>> _______________________________________________
>> Windmill-dev mailing list
>> Windmill-dev at osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/windmill-dev
>
> _______________________________________________
> Windmill-dev mailing list
> Windmill-dev at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/windmill-dev