I think those clickJSDIalog_therad etc were there for very old brower
versions ( I think watir was started on ie 5 or 5.5) and havent been kept up
to date
There were also lots of differences between browser versions and OS and
especially languages.
I always though that something like this would be a nice way of dealing with
js dialogs ( the ones from alert )
ie.button(Lid, 'I_open_a_pop_up').click_and_expect_pop_up{ |pop_up| puts
pop_up.text; pop_up.clikc_ok }
But, as Ive always encouraged people to not use pop ups, Ive never had to
implement it.
Paul
On Wed, Nov 18, 2009 at 11:34 AM, Ethan <[email protected]> wrote:
> Do you mean 'internalize' as opposed to relying on AutoIt? or something
> different?
> I'm all for dropping as much dependency on AutoIt as we can. But, I don't
> think that injecting javascript is a very good solution. Firewatir replaces
> the window.alert and window.prompt methods to catch those, but that seems
> like a kluge to me, and in my fork I drop that and interact with popups as
> they open.
> I have been working with IE watir's popups code the past couple of days,
> working on fixing tests that I had broken. It is somewhat confusing. For one
> thing, there's terminology.
> 'Popup' seems to be used to mean a javascript alert or prompt.
> 'Modal dialog' seems to be used to mean a modal with an html document as
> its content (launched via window.showModalDialog) - even though the term
> 'modal dialog' is in the real world pretty much synonymous with 'popup'.
>
> in WinClicker, there are is clickJavaScriptDialog. there's
> clickJSDialog_Thread, which seems to do nothing with any threading - not
> that threading would be any use because a blocked #click blocks all threads.
> there's clickJSDialog_NewProcess which calls to clickJavaScriptDialog in a
> new process (but this does not seem to be referenced anywhere).
> clickJSDialog_Thread is used by startClicker, but then there's a completely
> different startClicker implemented in the popups_test which uses a new
> process - but doesn't use clickJSDialog_NewProcess; it rolls its own.
> There's a #dialog method on the Watir module itself. This is used in
> dialog_test, and as far as I can find isn't documented anywhere. It
> basically lets you send the 'enter' key to a button with AutoIt, or call
> WinClose on it.
>
> Very confusing overall.
>
> So, what do we actually need in terms of functionality? Seems to me users
> need to click_no_wait (or fire_event_no_wait) when a popup is going to come
> up, and then get rid of the the popup by interacting with it. I guess the
> Watir.dialog method is there for that. But that just sends the enter key
> with autoit; it doesn't seem to click any particular button (though it does
> check that the specified button exists, sort of).
> What I implemented for my fork of firewatir was:
>
> Firefox#modal_dialog - this returns a JsshObject that is the browser's
> representation of the modal dialog window (which may be from a window.prompt
> or window.alert or window.showModalDialog).
> Firefox#click_modal_button(button_text) - gets the modal using the above
> #modal_dialog method; finds a button on it matching the given button text
> (or regexp) and clicks on it.
> Firefox#modal_text - gets the text content of the modal dialog's document.
> (this was called #get_popup_text before, and is aliased).
> I deprecated Firefox#startClicker, as interacting with the real modals is
> preferable. My application relies on screenshots of things to some extent,
> so Firefox#startClicker's practice of replacing window.alert and
> window.prompt so they never appeared wasn't acceptable.
>
> The same thing could be implemented for IE. A while back I got sufficiently
> annoyed with WinClicker that I wrote a much more general library for
> interacting with windows in Windows, called WinWindow. You can see that at
> http://github.com/ethan-medidata/watir/blob/master/commonwatir/lib/watir/win_window.rb
> I believe it is powerful enough to replace anything AutoIt does currently,
> so we can potentially not need that DLL. It uses the same underlying win32
> methods as WinClicker, but its methods are much more general and powerful
> than WinClicker's.
> I already have mostly implemented the same things as I did for Firewatir,
> mentioned above, for IE as well (not all on github yet).
>
> Do we need a startClicker sort of thing? I think that users can use
> _no_wait methods; having a background process waiting for a button to click
> to appear seems unnecessary to me. I see us basically needing useful tools
> to interact with existing popups - getting the text, clicking the specified
> button, entering text into a prompt.
>
> -Ethan
>
>
> On Wed, Nov 18, 2009 at 12:17, Bret Pettichord <[email protected]>wrote:
>
>> I assume you are talking about javascript alert/confirm popups.
>>
>> I would like to standardise the interface for dealing with these popups.
>> And i would be nice if we could provide users with a choice of mechanism for
>> how these would be handled.
>>
>> One issue I see is that injecting javascript to handle the popups would
>> have to be done before clicking the button that invokes the popup. So that
>> undermines the idea of having a standard interface.
>>
>> I am working hard to have the same interface for all implementations of
>> Watir, including, e.g. Celerity.
>>
>> Can you make a proposal for the API you'd like to implement?
>>
>> Bret
>>
>>
>> On Wed, Nov 18, 2009 at 10:56 AM, aidy lewis
>> <[email protected]>wrote:
>>
>>> Hi,
>>>
>>> I think we need to internalise dealing with pop-ups within Watir.
>>>
>>> I suggest we send JavaScript to override the pop-ups?
>>>
>>> WDYT?
>>>
>>> Aidy
>>> _______________________________________________
>>> Wtr-development mailing list
>>> [email protected]
>>> http://rubyforge.org/mailman/listinfo/wtr-development
>>>
>>
>>
>>
>> --
>> Bret Pettichord
>> Lead Developer, Watir, www.watir.com
>>
>> Blog, www.io.com/~wazmo/blog <http://www.io.com/%7Ewazmo/blog>
>> Twitter, www.twitter.com/bpettichord
>>
>>
>> _______________________________________________
>> Wtr-development mailing list
>> [email protected]
>> http://rubyforge.org/mailman/listinfo/wtr-development
>>
>
>
> _______________________________________________
> Wtr-development mailing list
> [email protected]
> http://rubyforge.org/mailman/listinfo/wtr-development
>
_______________________________________________
Wtr-development mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/wtr-development
