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
