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

[Mikeal Rogers]

On Dec 16, 2007, at December 16, 200712: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.
>>

I spent a good chunk of my weekend giving this another go.

I finally know how Selenium does this. You have to generate a  
certificate for each target site and make the next socket connection  
after an HTTP CONNECT method respond with that certificate.

This means seriously tearing in to the server layer of windmill, which  
to date we don't actually control. We use cherrypy as a WSGI server,  
and the rest of our app works strictly at the WSGI application level.

Supporting SSL is a huge amount of work -- significantly more work  
than anything else we're considering in windmill. We'll either have to  
swap out various cherrypy wsgi server components, write our own  
server, or move to a new server that provides us some way of getting  
at this layer. I do know that there is a working https proxy  
implementation in twisted, so it might be possible to mess with that.


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

Actually, what we want to try and do for this is set it in the browser  
via javascript.

If we try to handle this on the backend (shoving the file stream into  
the multi-post stream) it's a HUGE hack and is extremely far from what  
a normal user would do. This also bypasses anything someone might have  
done with javascript and/or form validation on the browser.

If there is no other way, i'll do it in the Service, but this is worst  
case scenario.

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

I think it's fair to assume mousedown -> mouseup is a click if it  
fires on the same element within 100 milleseconds.

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

Just a mouse down might not be a click. There are certain UI's i've  
used where holding down the mouse button makes another contextual div  
pop up, which you then mouseup on.

Now that i think about it, we should probably expose the mousedown and  
mouseup controller API so that people can test that.

>
>
> Three: We take over the whole app and remove the stop propagates!

I'm pretty sure this would break some more advanced web apps. If you  
kill event propagation you may be causing events to make it through  
the event framework a web app is using.

Maybe this is naive, but if the framework is killing propagation on  
some elements I would hope it's for a good reason.

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