okay, reading through all of this again I have some thoughts on what watir should be able to do, and how it should let the user do those things.
things watir should be able to do with popups: 1. return a reference to an existing popup. in my fork popups are represented by JsshObjects in firewatir; by WinWindow objects in IE. a new class, say Watir::ModalDialog, could wrap around these (I'm going to ignore for the moment that the name Watir::ModalDialog conflicts with an existing class that represents an html document on a modal dialog, because I believe the name makes more sense for my idea). 2. check if a popup exists. 3. get the text of an existing popup. 4. enter values into a javascript window.prompt() or the like. 5. enter login credentials. 6. click buttons 'ok', 'cancel', whatever others may be there. also 'open' and 'save' on 'file download' popups might be nice. 7. security alerts - I have no idea what is needed here. glancing at http://wiki.openqa.org/display/WTR/Security+Alerts maybe just clicking the 'yes' button (which falls into the same functionality as the previous, clicking buttons) would suffice? 8. return a watir container containing an html document contained in a popup launched using window.showModalDialog(). does anybody actually need this functionality? it exists on ie and firefox both, but I've never seen a site use this ever. I'd be happy to drop support for this as it requires a custom dll and a custom WIN32OLE.so, which seems like too much to be worth maintaining for this. My proposed API: 1. Watir::Browser#modal_dialog(options={:timeout => 8}) returns a Watir::ModalDialog, which is a newly-created class for this API which represents a popup on the browser. this class wraps some underlying object and makes things consistent cross-browser. if there is no modal dialog on the browser, there are a couple of ways this could go. it could: - a) return nil - I think this is simplest, and most preferable. - b) return a ModalDialog that is designed to represent a modal dialog when one comes into existence, raising an error if it is used in a manner that expects a modal dialog to exist when none does. that's how the container methods that return elements behave, which personally I'm not terribly fond of, but this would be consistent. I'm not sure how consistent it needs to be, though, given that modal dialogs are quite different from dom elements. 2. Depending on how 1. is implemented, this would be one of: - a) since Browser#modal_dialog returns nil on nonexistent modal dialog if implemented this way, just checking if the return value of browser.modal_dialog is non-nil would suffice for checking existence. - b) ModalDialog#exists? (browser.modal_dialog.exists?) 3. ModalDialog#text (browser.modal_dialog.text) 4. ModalDialog#set_text_field(value) - this would find the first and presumably only editable text field on the popup and set its text to the given value. 5. ModalDialog#set_login_credentials(username, password) 6. ModalDialog#click_button(button_name) 7. ? - maybe covered by 6. 8. ModalDialog#html_container - would return a Watir::ModalDialogHTML, which is what I'd rename the current confusingly-named Watir::ModalDialog to. there's also the issue of the things that run looping in the background waiting for popups to appear. I'm uncertain about these - part of me wants to say we should drop them and people should use click_no_wait when there will be a popup. but, I suppose the idea of watir is to simulate a user, and a user doesn't just freeze when an unexpected popup is encountered, so maybe that should be supported. I wouldn't be using it in my own application, I expect, but maybe it should exist. -Ethan On Thu, Nov 19, 2009 at 03:03, ! Tony ! <[email protected]> wrote: > Hi Ethan, > > I had been working on popups for quite some time and i found that injecting > javascript and the autoit methods not good enough. > > Injecting javascript - had issues where a popup occurs during page load - > these popups couldnt be avoided, cause javscript injection occurs only after > the page is loaded. (correct me if iam wrong) > > Autoit - i had issues with this where i couldnt actually verify that i > clicked only on the javascript popup that occured from the webapp under > test. > Autoit will click on the ok for any popup .. if there are 2 popups from 2 > different web apps .. u cannot make sure that the particular popup was > clicked. > > For ie , we can handle popups in a more efficient manner. > No need of Autoit or any other external ruby files. > > I have attached the code to the > http://wiki.openqa.org/display/WTR/JavaScript+Pop+Ups?showChildren=true > Please take a look at solution 7. > > This code can be inserted into the ie-class.rb and works by using the ie > browser object. > Example code - > require 'watir' > iewin = Watir::IE.new > iewin.goto(" > http://www.w3schools.com/js/tryit_view.asp?filename=tryjs_alert";) > iewin.button(:value, "Show alert box").click_no_wait > txt = iewin.clickprompt() # waits for popup and click ok > puts txt #prints the popup text > > The advantage of using this is - it will handle any popup from the browser > under test only. You can have popups from any other browser and those will > not be closed. I havent written the code to handle fileuploads and > downloads, but that should be easy. > > To handle popups during page load .. the above code has to be clubbed with > the code at the below url. > http://wiki.openqa.org/display/WTR/Security+Alerts - (Autoclick yes when a > security alert window pops up?) > > Bret had previously rejected the above code stating that it would make the > wait method more complex. > When a popup occurs during a page load .. ie gets stuck in the wait loop, > and you will have to exit the wait loop to handle this popup. > Hence the use of this line - return 0 if !(popwndtitle.include?("Security > Alert") || popwndtitle.include?("Security Information")) > It exits if it encounters any other popup other than the Secuirty Alert and > Security Information.(which would be handled in the wait loop). > > Thanks, > Tony > > _______________________________________________ > 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
