Comments inline: On Fri, Nov 27, 2009 at 1:45 PM, Ethan <[email protected]> wrote:
> 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). > The terminology around popups is slightly confusing at the very least. Something we need to work on with future versions of Watir and has caused endless confusion on the mailing list. This definitely needs some work, though we need to talk about it a bit to figure out what the right approach is given the various implementations and approaches. I'm marking this as a definite discussion point and should be vetted between the various implementations to come to a common solution. 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. > Same holds true of the above point. The apis might break down to simple (pseudocode) click ok, click cancel, click "whatever". Grabbing text also similar and needs to be wrapped based on the dialog type. > 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? > These tend to fall into a slightly different category, I've not dealt with a couple of variations it entails setting it up before page load for simple apache style secure alerts, then dealing with a popup/tab dependent on browser version for SSL certs, this is a bit challenging, with possibilities for manipulating the browser config or runtime - differs between safari, firefox and various versions of IE. > 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. > I've used this extensively and contributed to the ongoing development. I've been using it for IE until a recent project where I just found out that it's also implemented on Firefox to my chagrin. The current solution is clunky, I have yet to implement it on Firewatir, but that will happen soon. This is not common practice but certainly there are some sites, public or web driven 3rd party applications where this is still acceptable practice. I haven't pored through your proposed changes and fork aside from an initial look, but hoping to get some time to work through it a bit. API changes need to have some discussion, and while I like your enthusiam, I feel like you're heavily pushing for your own agenda. don't take that wrong, :), but I do feel like we need more discussion about this. I know this is not going through on email, but it's great to have you in the general discussion and I welcome your ideas, but we need to have a broader discussion, and it seems like your ideas are fully baked right now? I'm probably missing the year you did with watir and changes and working collectively with us. :) I do deal with things you're dismissing, as do we all. File downloads? Sounds great, but I don't have them, so I'm less motivated to work on them in my spare time. Localization is kinda of on my front burner to take a look at, though I have yet to do that. Anyhow I'll punt on the apis for and we can collectively work with them together. -Charley > > > > 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::ModalDialogto. > > > 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 >
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
