Hi Ethan, Charley
my take on what i see ....
The proposed api sounds good .. though i have my own list of changes.
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.
6. ModalDialog#click_button(button_name)
Popups are of 3 types, alert, confirm and a prompt(which takes text as
input).
Instead of having 2 functions enter text and click the button on the
prompt, Just have one.
ModalDialog#click_button(button_name,text_field_value=nil)
5. ModalDialog#set_login_credentials(username, password)
This is for handling Basic authentication. In IE just drumming up and
calling this function will not handle it, cause you would have to handle
this in the wait logic. Not sure about firefox though.
Instead a more cross browser and easier solution would be, add a new goto
function.
Browser.goto_authurl(url,myusername, mypassword) { do a goto with "
http://myusername:myuserpassw...@url/<http://myusername:[email protected]/%22,>"
}
That should get you through to the auth page without adding any new
complexity to the wait logic.
6. security alerts - Yes Please keep Security popup handling separate, they
all need to be handled in the wait logic. Its not just clicking a button on
another popup.
we need to have a broader discussion, and it seems like your ideas are fully
> baked right now?
I am posting this here for discussion. This is just a proposal of what I
think might be a good way to do things. Nothing is fully-baked, I have no
code for this, it's just what I came up with off the top of my head
yesterday and am proposing. Discussing things like this are precisely why
I'm on the mailing list.
-will take 15 mins to come up with the code for IE(code is already out
there, just have to change the function names )
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.
-yeah file downloads, uploads, same here i never used them, maybe i will
take a look at it, i had read somebody had already done work on this.
Thanks,
Tony
On Sat, Nov 28, 2009 at 6:40 AM, Ethan <[email protected]> wrote:
> Regarding window.showModalDialog html popups: it is interesting to hear
> that they are used extensively in some contexts - it didn't really seem
> likely the current implementation would exist if that were not the case, of
> course, but having never come across these in the wild myself I had to
> wonder. So, they should certainly be a part of any API.
>
> For security alerts - I'm mostly thinking about an API for modal popups,
> which security alerts are in IE6 but not later. I think maybe a different
> interface is needed for dealing with security alerts in a cross-browser
> cross-version manner, and this discussion should focus just on what are
> always modal popups (javascript alert() and prompt()s, and that sort of
> thing).
>
> we need to have a broader discussion, and it seems like your ideas are
>> fully baked right now?
>
> I am posting this here for discussion. This is just a proposal of what I
> think might be a good way to do things. Nothing is fully-baked, I have no
> code for this, it's just what I came up with off the top of my head
> yesterday and am proposing. Discussing things like this are precisely why
> I'm on the mailing list.
>
> API changes need to have some discussion, and while I like your enthusiam,
>> I feel like you're heavily pushing for your own agenda.
>
> I'm not sure what you mean by this. I have no "agenda" - I have opinions on
> the best way of doing things, as does everybody, but I'm not trying to push
> these on anyone who disagrees. I have changed a lot of code in my fork, but
> tried to keep the existing API exactly the same. There are a couple of
> exceptions in cases where it just seemed wrong to me - and others have
> agreed, I think, for example SelectList#options returning an array of
> strings rather than Option elements. The one major change I thought would be
> an improvement (container methods returning nil rather than a nonexistent
> element), there was a good bit of discussion around, and since nobody seemed
> to agree with my opinion, I have changed that back.
>
> I want to contribute code that will improve the state of Watir overall,
> that is my only agenda. I believe my changes for the most part do that,
> except the few things that remain broken, primary among which are popups -
> that's why I'd be happy to have a well-defined API resolved.
>
> I'm probably missing the year you did with watir
>
>
> heh, I hadn't actually even heard of watir a year ago.
>
> -Ethan
>
> On Fri, Nov 27, 2009 at 17:50, Charley Baker <[email protected]>wrote:
>
>> 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::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
>>>
>>
>>
>> _______________________________________________
>> 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
