From bret at pettichord.com  Sun Nov  1 22:37:53 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Sun, 1 Nov 2009 21:37:53 -0600
Subject: [Wtr-development] Feature Branches, starting with "element-method"
Message-ID: <ade75c5b0911011937v75d8c105ld32a8ae8296a5585@mail.gmail.com>

These days, my policy on adding new methods to watir is "Start with No"
http://gettingreal.37signals.com/ch05_Start_With_No.php

But there are some methods that I would like to see us add. I've previously
mentioned my reluctance even then to add them for only one browser.

A feature that fits this category is adding browser.element and
browser.elements.
http://jira.openqa.org/browse/WTR-103

Hugh McGowan wrote the code for this in his github fork and I've pulled it
into a separate branch.
http://github.com/bret/watir/tree/element-method

Before pulling this into trunk, i would like to see these methods added to
firewatir as well. By making a separate branch, I'm hoping to encourage some
one to do this work.

I also have plans to create feature branches for the following:
  * Change to zero-based indexing
  * Changing wait parameters to those recently recommended by Tim
  * Adding display_value methods from watircraft
  * Add a new match (===) operator for watir elements (based on
display_value)
  * Reworking table classes
  * Reworking radio class
  * Using jeweller to create gems (removing hoe).

I also encourage others who would like to work on these or other features to
work on topic branches.

(This is all in the context of things that we'd add after the 1.6.5
release.)

Bret

-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091101/8394506f/attachment.html>

From notethan at gmail.com  Mon Nov  2 11:01:54 2009
From: notethan at gmail.com (Ethan)
Date: Mon, 2 Nov 2009 11:01:54 -0500
Subject: [Wtr-development] Feature Branches,
	starting with 	"element-method"
In-Reply-To: <ade75c5b0911011937v75d8c105ld32a8ae8296a5585@mail.gmail.com>
References: <ade75c5b0911011937v75d8c105ld32a8ae8296a5585@mail.gmail.com>
Message-ID: <f58506c40911020801k463fab7cq6e36f06b5bb3317b@mail.gmail.com>

Container#element and #elements is supported in my branch.

Zero-based indexing, sounds good. I assume this would apply to subscripting
element collections, (ie, container.divs[0] instead of container.divs[1]);
would it also apply to container.div(:index, 0) rather than
container.div(:index, 1)?

display_value, what's this? can you link to documentation or source? I'm not
seeing this with a quick search.

What would change with table and radio?

-Ethan

I also have plans to create feature branches for the following:
  * Change to zero-based indexing
  * Changing wait parameters to those recently recommended by Tim
  * Adding display_value methods from watircraft
  * Add a new match (===) operator for watir elements (based on
display_value)
  * Reworking table classes
  * Reworking radio class
  * Using jeweller to create gems (removing hoe).


On Sun, Nov 1, 2009 at 22:37, Bret Pettichord <bret at pettichord.com> wrote:

> These days, my policy on adding new methods to watir is "Start with No"
> http://gettingreal.37signals.com/ch05_Start_With_No.php
>
> But there are some methods that I would like to see us add. I've previously
> mentioned my reluctance even then to add them for only one browser.
>
> A feature that fits this category is adding browser.element and
> browser.elements.
> http://jira.openqa.org/browse/WTR-103
>
> Hugh McGowan wrote the code for this in his github fork and I've pulled it
> into a separate branch.
> http://github.com/bret/watir/tree/element-method
>
> Before pulling this into trunk, i would like to see these methods added to
> firewatir as well. By making a separate branch, I'm hoping to encourage some
> one to do this work.
>
> I also have plans to create feature branches for the following:
>   * Change to zero-based indexing
>   * Changing wait parameters to those recently recommended by Tim
>   * Adding display_value methods from watircraft
>   * Add a new match (===) operator for watir elements (based on
> display_value)
>   * Reworking table classes
>   * Reworking radio class
>   * Using jeweller to create gems (removing hoe).
>
> I also encourage others who would like to work on these or other features
> to work on topic branches.
>
> (This is all in the context of things that we'd add after the 1.6.5
> release.)
>
> Bret
>
> --
> 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
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091102/c2cffa3c/attachment-0001.html>

From jari.bakken at gmail.com  Mon Nov  2 11:15:42 2009
From: jari.bakken at gmail.com (Jari Bakken)
Date: Mon, 2 Nov 2009 17:15:42 +0100
Subject: [Wtr-development] Feature Branches,
	starting with 	"element-method"
In-Reply-To: <ade75c5b0911011937v75d8c105ld32a8ae8296a5585@mail.gmail.com>
References: <ade75c5b0911011937v75d8c105ld32a8ae8296a5585@mail.gmail.com>
Message-ID: <eae5f6f90911020815u32a87d12v803995522728d6a5@mail.gmail.com>

On Mon, Nov 2, 2009 at 4:37 AM, Bret Pettichord <bret at pettichord.com> wrote:
>
> I also have plans to create feature branches for the following:
>

Bret,

How do you see the the work being done on 1.6 in light of the decision
to base 2.0 on WebDriver?

Jari

From zeljko.filipin at wa-research.ch  Mon Nov  2 11:21:30 2009
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Mon, 2 Nov 2009 17:21:30 +0100
Subject: [Wtr-development] Feature Branches,
	starting with 	"element-method"
In-Reply-To: <eae5f6f90911020815u32a87d12v803995522728d6a5@mail.gmail.com>
References: <ade75c5b0911011937v75d8c105ld32a8ae8296a5585@mail.gmail.com> 
	<eae5f6f90911020815u32a87d12v803995522728d6a5@mail.gmail.com>
Message-ID: <f81b1250911020821u283d302ft3868660b8ca9d4dc@mail.gmail.com>

On Mon, Nov 2, 2009 at 5:15 PM, Jari Bakken <jari.bakken at gmail.com> wrote:
> How do you see the the work being done on 1.6 in light of the decision
> to base 2.0 on WebDriver?

Exactly the question I wanted to ask. If we are going to throw away all
browser specific code in a few months (if I understood it correctly), would
it be better to help Jari on webdriver-rb?

Jari, http://github.com/jarib/webdriver-rb/ says "That page doesn't exist!"

?eljko
--
watir.com - community manager
watirpodcast.com - host
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091102/926fd8fc/attachment.html>

From jari.bakken at gmail.com  Mon Nov  2 11:26:03 2009
From: jari.bakken at gmail.com (Jari Bakken)
Date: Mon, 2 Nov 2009 17:26:03 +0100
Subject: [Wtr-development] Feature Branches,
	starting with 	"element-method"
In-Reply-To: <f81b1250911020821u283d302ft3868660b8ca9d4dc@mail.gmail.com>
References: <ade75c5b0911011937v75d8c105ld32a8ae8296a5585@mail.gmail.com>
	<eae5f6f90911020815u32a87d12v803995522728d6a5@mail.gmail.com>
	<f81b1250911020821u283d302ft3868660b8ca9d4dc@mail.gmail.com>
Message-ID: <eae5f6f90911020826p7fb9ca9eo126129c1fabe0d11@mail.gmail.com>

On Mon, Nov 2, 2009 at 5:21 PM, ?eljko Filipin
<zeljko.filipin at wa-research.ch> wrote:
>
> Jari, http://github.com/jarib/webdriver-rb/ says "That page doesn't exist!"
>


Yes, the code is now in WebDriver trunk as of this commit :)

  http://code.google.com/p/selenium/source/detail?r=7508

From zeljko.filipin at wa-research.ch  Mon Nov  2 11:27:26 2009
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Mon, 2 Nov 2009 17:27:26 +0100
Subject: [Wtr-development] Feature Branches,
	starting with 	"element-method"
In-Reply-To: <eae5f6f90911020826p7fb9ca9eo126129c1fabe0d11@mail.gmail.com>
References: <ade75c5b0911011937v75d8c105ld32a8ae8296a5585@mail.gmail.com> 
	<eae5f6f90911020815u32a87d12v803995522728d6a5@mail.gmail.com> 
	<f81b1250911020821u283d302ft3868660b8ca9d4dc@mail.gmail.com> 
	<eae5f6f90911020826p7fb9ca9eo126129c1fabe0d11@mail.gmail.com>
Message-ID: <f81b1250911020827i1d312fb5l4707202428a08fea@mail.gmail.com>

On Mon, Nov 2, 2009 at 5:26 PM, Jari Bakken <jari.bakken at gmail.com> wrote:
> Yes, the code is now in WebDriver trunk as of this commit :)

Does that mean that we can start working on Watir 2.0 right now?

?eljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091102/83012775/attachment.html>

From jari.bakken at gmail.com  Mon Nov  2 11:36:26 2009
From: jari.bakken at gmail.com (Jari Bakken)
Date: Mon, 2 Nov 2009 17:36:26 +0100
Subject: [Wtr-development] Feature Branches,
	starting with 	"element-method"
In-Reply-To: <f81b1250911020827i1d312fb5l4707202428a08fea@mail.gmail.com>
References: <ade75c5b0911011937v75d8c105ld32a8ae8296a5585@mail.gmail.com>
	<eae5f6f90911020815u32a87d12v803995522728d6a5@mail.gmail.com>
	<f81b1250911020821u283d302ft3868660b8ca9d4dc@mail.gmail.com>
	<eae5f6f90911020826p7fb9ca9eo126129c1fabe0d11@mail.gmail.com>
	<f81b1250911020827i1d312fb5l4707202428a08fea@mail.gmail.com>
Message-ID: <eae5f6f90911020836y146f2f52nfc4a9df584409bd2@mail.gmail.com>

On Mon, Nov 2, 2009 at 5:27 PM, ?eljko Filipin
<zeljko.filipin at wa-research.ch> wrote:
> On Mon, Nov 2, 2009 at 5:26 PM, Jari Bakken <jari.bakken at gmail.com> wrote:
>> Yes, the code is now in WebDriver trunk as of this commit :)
>
> Does that mean that we can start working on Watir 2.0 right now?
>

Yep. The WebDriver bindings probably need more work, and there's no
gem release yet. But I guess there's no better way to find bugs in the
bindings by building a tool on top of them :)

As mentioned in another thread on this list, I'm experimenting with
generating code for Watir's "DOM" implementation from the HTML specs.
I'll push some of that work to a new repo on GitHub soon, probably
named "watir2", "watir2-spike" or something like that.

From zeljko.filipin at wa-research.ch  Mon Nov  2 11:53:05 2009
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Mon, 2 Nov 2009 17:53:05 +0100
Subject: [Wtr-development] Feature Branches,
	starting with 	"element-method"
In-Reply-To: <eae5f6f90911020836y146f2f52nfc4a9df584409bd2@mail.gmail.com>
References: <ade75c5b0911011937v75d8c105ld32a8ae8296a5585@mail.gmail.com> 
	<eae5f6f90911020815u32a87d12v803995522728d6a5@mail.gmail.com> 
	<f81b1250911020821u283d302ft3868660b8ca9d4dc@mail.gmail.com> 
	<eae5f6f90911020826p7fb9ca9eo126129c1fabe0d11@mail.gmail.com> 
	<f81b1250911020827i1d312fb5l4707202428a08fea@mail.gmail.com> 
	<eae5f6f90911020836y146f2f52nfc4a9df584409bd2@mail.gmail.com>
Message-ID: <f81b1250911020853x3ae14ba5g201419454e09d17f@mail.gmail.com>

On Mon, Nov 2, 2009 at 5:36 PM, Jari Bakken <jari.bakken at gmail.com> wrote:
> But I guess there's no better way to find bugs in the
> bindings by building a tool on top of them :)

I agree.

> I'll push some of that work to a new repo on GitHub soon, probably
> named "watir2", "watir2-spike" or something like that.

Please do. I like watir2 as a name, but it is your choice. I would really
like to work on Watir code, but since you have announced your plan for Watir
2.0, I feel like working on existing code is wasted time, since we will
throw it all away soon.

I have limited time and knowledge, but my company has agreed for me to spend
a few hours weekly on Watir, and I would really like to help. Can you point
me to some documentation that would help me better understand your work on
Watir 2.0, or should I just read the code and try to figure it out myself?
Do you need help on anything specific?

?eljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091102/a24f3a74/attachment.html>

From jari.bakken at gmail.com  Mon Nov  2 12:07:58 2009
From: jari.bakken at gmail.com (Jari Bakken)
Date: Mon, 2 Nov 2009 18:07:58 +0100
Subject: [Wtr-development] Feature Branches,
	starting with 	"element-method"
In-Reply-To: <f81b1250911020853x3ae14ba5g201419454e09d17f@mail.gmail.com>
References: <ade75c5b0911011937v75d8c105ld32a8ae8296a5585@mail.gmail.com>
	<eae5f6f90911020815u32a87d12v803995522728d6a5@mail.gmail.com>
	<f81b1250911020821u283d302ft3868660b8ca9d4dc@mail.gmail.com>
	<eae5f6f90911020826p7fb9ca9eo126129c1fabe0d11@mail.gmail.com>
	<f81b1250911020827i1d312fb5l4707202428a08fea@mail.gmail.com>
	<eae5f6f90911020836y146f2f52nfc4a9df584409bd2@mail.gmail.com>
	<f81b1250911020853x3ae14ba5g201419454e09d17f@mail.gmail.com>
Message-ID: <eae5f6f90911020907m3f65c1b0qff5c3507aead7f4a@mail.gmail.com>

On Mon, Nov 2, 2009 at 5:53 PM, ?eljko Filipin
<zeljko.filipin at wa-research.ch> wrote:
>
> I have limited time and knowledge, but my company has agreed for me to spend
> a few hours weekly on Watir, and I would really like to help. Can you point
> me to some documentation that would help me better understand your work on
> Watir 2.0, or should I just read the code and try to figure it out myself?
> Do you need help on anything specific?
>

I don't really have anything specific at the moment, it's still in the
very early stages (I'm not even sure we'll keep any of the code I
currently have - it's just a spike). The best thing to do if you want
to help out is probably try to use the WebDriver bindings and find and
report bugs in those. Feel free to wave me at jari.bakken at
googlewave.com :)

From bret at pettichord.com  Mon Nov  2 23:30:06 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Mon, 2 Nov 2009 22:30:06 -0600
Subject: [Wtr-development] Feature Branches,
	starting with 	"element-method"
In-Reply-To: <f81b1250911020821u283d302ft3868660b8ca9d4dc@mail.gmail.com>
References: <ade75c5b0911011937v75d8c105ld32a8ae8296a5585@mail.gmail.com>
	<eae5f6f90911020815u32a87d12v803995522728d6a5@mail.gmail.com>
	<f81b1250911020821u283d302ft3868660b8ca9d4dc@mail.gmail.com>
Message-ID: <ade75c5b0911022030p4f1ddd28ibef2eedbe7a1bee5@mail.gmail.com>

On Mon, Nov 2, 2009 at 10:21 AM, ?eljko Filipin <
zeljko.filipin at wa-research.ch> wrote:

> On Mon, Nov 2, 2009 at 5:15 PM, Jari Bakken <jari.bakken at gmail.com> wrote:
> > How do you see the the work being done on 1.6 in light of the decision
> > to base 2.0 on WebDriver?
>
> Exactly the question I wanted to ask. If we are going to throw away all
> browser specific code in a few months (if I understood it correctly), would
> it be better to help Jari on webdriver-rb?
>

Architecturally I want to make Watir more pluggable and easier for people to
create port/implementations for it. I think that adding a WebDriver-based
implemenation is one of the more important approaches and therefore I
strongly encourage the work you (Jari) are planning to make with this.
Charley and I have talked about this being the right way to move for a
couple of years now, so I'm really happy to see your enthusiasm for it.

At the same time, i think it will be a big project and will take time and I
don't have plans to drop everything else. I've seen how much time it has
taken for FireWatir to go from concept to initial release and it still has
some things we can work on for it. I've also seen the time that Celerity
took. I expect that the WebDriver project will similarly take some time to
come together.

In my daily work, we still have not been able to port many of our tests to
use FireWatir because we make signficant use of the 10% of Watir::IE that
has not yet been ported to FireWatir. That final 10% or 20% can take years.
I don't see us throwing away any code in a couple of months.

We should probably set up a skype conference call to discuss these issues.

Bret

-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091102/556c78bd/attachment-0001.html>

From bret at pettichord.com  Mon Nov  2 23:43:01 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Mon, 2 Nov 2009 22:43:01 -0600
Subject: [Wtr-development] Feature Branches,
	starting with 	"element-method"
In-Reply-To: <f58506c40911020801k463fab7cq6e36f06b5bb3317b@mail.gmail.com>
References: <ade75c5b0911011937v75d8c105ld32a8ae8296a5585@mail.gmail.com>
	<f58506c40911020801k463fab7cq6e36f06b5bb3317b@mail.gmail.com>
Message-ID: <ade75c5b0911022043w26db297drbf04956f5153da70@mail.gmail.com>

On Mon, Nov 2, 2009 at 10:01 AM, Ethan <notethan at gmail.com> wrote:

> Container#element and #elements is supported in my branch.
>

Right, there is a lot of stuff in your branch. Would it be possible for you
to pull it out into feature branches to facilitate review?


> Zero-based indexing, sounds good. I assume this would apply to subscripting
> element collections, (ie, container.divs[0] instead of container.divs[1]);
> would it also apply to container.div(:index, 0) rather than
> container.div(:index, 1)?
>

http://jira.openqa.org/browse/WTR-61

BTW, one of the things that I've noticed is that many of the discussions
about jira tickets never get recorded there and therefore get repeated a
lot. I'm wondering if in the end this is really a problem with Jira. I
noticed that in my recent use of Lighthouse, this didn't happen nearly as
much. I think that tool made it easier to forward emails to the ticket and
also encouraged people to post questions, etc in the ticket itself, partly
because people could be set up as watching the ticket and thus get emails
when ever someone added a comment.

display_value, what's this? can you link to documentation or source? I'm not
> seeing this with a quick search.
>

Good question. Here is what I'm talking about.
http://github.com/bret/watircraft/blob/master/lib/extensions/watir.rb

What would change with table and radio?
>

My email is really a followup to a number of ideas that I posted in this
thread.
http://rubyforge.org/pipermail/wtr-development/2009-October/001195.html

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091102/27325560/attachment.html>

From notethan at gmail.com  Tue Nov  3 10:24:11 2009
From: notethan at gmail.com (Ethan)
Date: Tue, 3 Nov 2009 10:24:11 -0500
Subject: [Wtr-development] Feature Branches,
	starting with 	"element-method"
In-Reply-To: <ade75c5b0911022043w26db297drbf04956f5153da70@mail.gmail.com>
References: <ade75c5b0911011937v75d8c105ld32a8ae8296a5585@mail.gmail.com> 
	<f58506c40911020801k463fab7cq6e36f06b5bb3317b@mail.gmail.com> 
	<ade75c5b0911022043w26db297drbf04956f5153da70@mail.gmail.com>
Message-ID: <f58506c40911030724l284dde7ewd96b7d0f9b28f22@mail.gmail.com>

On Mon, Nov 2, 2009 at 23:43, Bret Pettichord <bret at pettichord.com> wrote:

>
> On Mon, Nov 2, 2009 at 10:01 AM, Ethan <notethan at gmail.com> wrote:
>
>> Container#element and #elements is supported in my branch.
>>
>
> Right, there is a lot of stuff in your branch. Would it be possible for you
> to pull it out into feature branches to facilitate review?
>

I'm not certain. most of what I have currently is rather tightly-knit, and
separating things out, I don't know if there would be a good way for me to
go about that. I will ponder on it, but I think it would take time that I
need to be spending working on features that my company needs with how we
use watir.


> Zero-based indexing, sounds good. I assume this would apply to subscripting
>> element collections, (ie, container.divs[0] instead of container.divs[1]);
>> would it also apply to container.div(:index, 0) rather than
>> container.div(:index, 1)?
>>
>
> http://jira.openqa.org/browse/WTR-61
>

Sounds like 0-based everywhere. sounds good to me.


> BTW, one of the things that I've noticed is that many of the discussions
> about jira tickets never get recorded there and therefore get repeated a
> lot. I'm wondering if in the end this is really a problem with Jira. I
> noticed that in my recent use of Lighthouse, this didn't happen nearly as
> much. I think that tool made it easier to forward emails to the ticket and
> also encouraged people to post questions, etc in the ticket itself, partly
> because people could be set up as watching the ticket and thus get emails
> when ever someone added a comment.
>
> display_value, what's this? can you link to documentation or source? I'm
>> not seeing this with a quick search.
>>
>
> Good question. Here is what I'm talking about.
> http://github.com/bret/watircraft/blob/master/lib/extensions/watir.rb
>

ah, interesting. with the ===, this would end up with
true === #<Watir::Checkbox checked=true>
which seems potentially a bit broad for a checkbox to be matching. where
would this be useful? It is an interesting idea, I'm not sure I see the full
use of it though.

case element
when true
  puts "the element seems to be true, whatever it is"
when false
  puts "element is false"
when /foo/
  puts "element contains text foo"
end

What would change with table and radio?
>>
>
> My email is really a followup to a number of ideas that I posted in this
> thread.
> http://rubyforge.org/pipermail/wtr-development/2009-October/001195.html
>

I recall that discussion, reading back through it, but I'm not seeing what
in particular you have in mind to change. With tables, I think maybe you
mean that it counts nested tables in row_count, for one thing, and doesn't
really consistently deal with whether it's using rows from itself or from
nested tables (this is also fixed in my branch). If not that, I'm not sure
what you mean.
For radios, I still don't know what should be different - I see you mention
it in that discussion, but not what in particular is wrong.

-Ethan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091103/a8e1bffe/attachment.html>

From bret at pettichord.com  Tue Nov  3 20:01:38 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 3 Nov 2009 19:01:38 -0600
Subject: [Wtr-development] Watir 2.0 / WebDriver
In-Reply-To: <eae5f6f90910301113u18928962u8494b83bd6a54449@mail.gmail.com>
References: <eae5f6f90910261211ld9fdb31racfb264acde1dc66@mail.gmail.com>
	<f81b1250910271629r6b463e35t5254daf14273726b@mail.gmail.com>
	<eae5f6f90910271644yf61c3a2w7a0eedb192083b90@mail.gmail.com>
	<eae5f6f90910301113u18928962u8494b83bd6a54449@mail.gmail.com>
Message-ID: <ade75c5b0911031701n4f4c81f4xda803ecf65d44322@mail.gmail.com>

I think you should give it a shot and see how it works out.

On Fri, Oct 30, 2009 at 12:13 PM, Jari Bakken <jari.bakken at gmail.com> wrote:

> As the WebDriver bindings are maturing (the initial commit to the
> WebDriver tree will happen very soon), I would like to do a spike on
> the Watir code built on WebDriver as the next step. I'm thinking I
> will do a new repo on GitHub named "watir2-spike" or similar.
>
> While thinking about how to structure the code, I wrote this example
> which is  pretty close to the API that was discussed in another thread
> with Ethan. So for element definitions:
>
>  http://gist.github.com/222592
>
> While looking at that I realized it's pretty declarative, which gave
> me the idea that this code (or some representation of that data) could
> possibly be generated from the XHTML or HTML5 specifications. So with
> a small core of metaprogramming that builds all the Watir element
> classes based on some declarative definition, the actual Watir code
> base would become pretty small and easy to maintain. I'm not sure if
> it's really feasible, but I'd like to give this a try for my spike.
>
> WDYT?
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>



-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091103/c0833ae1/attachment.html>

From tim.koops at gmail.com  Wed Nov  4 00:21:14 2009
From: tim.koops at gmail.com (Tim Koopmans)
Date: Wed, 4 Nov 2009 16:21:14 +1100
Subject: [Wtr-development] Watir across the grid
Message-ID: <93ee69e90911032121p758fd110x96db0f0eb1fe8a6@mail.gmail.com>

Hi guys,

I've recently been tinkering with distributed testing across a grid
network with Watir. This work is currently hosted on GitHub at
http://github.com/90kts/watirgrid

I based my initial design off DWatir[1] which uses Rinda to implement
a tuple space: a repository of tuples that can be accessed
concurrently. I've tried unsuccessfully to contact the original author
Dane Avilla, which looks like development stopped in 2007.

Since starting the GitHub project I've noticed a similar solution, not
using Rinda (UDP broadcast over druby protocol) but WebBrick (http
protocol) instead. It's also called WatirGrid[2] (oops!) and the
author looks to be Peter Houghton.

My end state is to facilitate some form of load testing with watir,
using many browsers concurrently. I plan to release it as a separate
gem. My preference so far is to continue with the druby protocol.

Questions to you are do you have any preference on choice of protocol
(druby vs. http) and does anyone know the original authors so that I
might get in contact with them?

[1] http://dwatir.rubyforge.org/
[2] http://www.ohloh.net/p/watirgrid

Regards,
Tim Koopmans

From jari.bakken at finn.no  Wed Nov  4 04:51:07 2009
From: jari.bakken at finn.no (Bakken, Jari)
Date: Wed, 4 Nov 2009 10:51:07 +0100
Subject: [Wtr-development] Feature Branches,
 starting with 	"element-method"
In-Reply-To: <ade75c5b0911022030p4f1ddd28ibef2eedbe7a1bee5@mail.gmail.com>
References: <ade75c5b0911011937v75d8c105ld32a8ae8296a5585@mail.gmail.com>
	<eae5f6f90911020815u32a87d12v803995522728d6a5@mail.gmail.com>
	<f81b1250911020821u283d302ft3868660b8ca9d4dc@mail.gmail.com>
	<ade75c5b0911022030p4f1ddd28ibef2eedbe7a1bee5@mail.gmail.com>
Message-ID: <2B952D76-FAB5-493C-82EB-038BB7DF875E@finn.no>


On 3. nov. 2009, at 05.30, Bret Pettichord wrote:

> Architecturally I want to make Watir more pluggable and easier for  
> people to create port/implementations for it. I think that adding a  
> WebDriver-based implemenation is one of the more important  
> approaches and therefore I strongly encourage the work you (Jari)  
> are planning to make with this. Charley and I have talked about this  
> being the right way to move for a couple of years now, so I'm really  
> happy to see your enthusiasm for it.
>
> At the same time, i think it will be a big project and will take  
> time and I don't have plans to drop everything else.

Sounds fine to me. I'll concentrate 100% of my Watir work on a  
WebDriver-based implementation and likely won't do any more work on  
the 1.6 code base. I've also created a watir2 branch of watirspec,  
which should be changed to describe the wanted behaviour of 2.0 - like  
changing the specs to use zero-based indices.

Before writing the WD ruby bindings, I went through most of the  
watirspec failures on IE (current HEAD), adding guards to the specs  
and creating issues in Jira. A lot of those will probably be resolved  
by Ethan's refactorings, but the list is a good starting point for  
making future 1.X better and more consistent. Specs failures that  
needs to be discussed are prefixed with "watirspec-pending". See http://jira.openqa.org/browse/WTR-336 
.

>
> We should probably set up a skype conference call to discuss these  
> issues.
>

Sounds like a good idea.

> Bret
>
> -- 
> Bret Pettichord
> Lead Developer, Watir, www.watir.com
>
> Blog, www.io.com/~wazmo/blog
> Twitter, www.twitter.com/bpettichord
>
> <ATT00001..txt>


From jari.bakken at gmail.com  Wed Nov  4 05:30:04 2009
From: jari.bakken at gmail.com (Jari Bakken)
Date: Wed, 4 Nov 2009 11:30:04 +0100
Subject: [Wtr-development] Feature Branches,
	starting with 	"element-method"
In-Reply-To: <2B952D76-FAB5-493C-82EB-038BB7DF875E@finn.no>
References: <ade75c5b0911011937v75d8c105ld32a8ae8296a5585@mail.gmail.com>
	<eae5f6f90911020815u32a87d12v803995522728d6a5@mail.gmail.com>
	<f81b1250911020821u283d302ft3868660b8ca9d4dc@mail.gmail.com>
	<ade75c5b0911022030p4f1ddd28ibef2eedbe7a1bee5@mail.gmail.com>
	<2B952D76-FAB5-493C-82EB-038BB7DF875E@finn.no>
Message-ID: <eae5f6f90911040230i1e90f709o765e951f4daa4933@mail.gmail.com>

Here's also my notes from the work on making Watir::IE "spec-compliant" :)

http://gist.github.com/207724

My idea was to go through each failure one by one, create issues and
add spec guards, eventually making the whole suite pass. The resulting
issue list describes very specific problems and should be easy to
attack, removing the spec guards as you go.

From zeljko.filipin at wa-research.ch  Fri Nov  6 05:47:27 2009
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Fri, 6 Nov 2009 11:47:27 +0100
Subject: [Wtr-development] Resolved tickets in Jira
Message-ID: <f81b1250911060247j714f879x67d75a9af581e6d6@mail.gmail.com>

Why do we have 58 tickets marked as resolved in Jira, but not closed?

http://jira.openqa.org/secure/IssueNavigator.jspa?reset=true&pid=10080&status=5

?eljko
--
watir.com - community manager
watirpodcast.com - host
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091106/097702f6/attachment.html>

From zeljko.filipin at wa-research.ch  Fri Nov  6 06:39:00 2009
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Fri, 6 Nov 2009 12:39:00 +0100
Subject: [Wtr-development] Wtr-core
Message-ID: <f81b1250911060339l7e653cf6h50bf6dfc31c1483e@mail.gmail.com>

Should we make Wtr-core read only?

http://rubyforge.org/pipermail/wtr-core/

Nobody used it in more than a year.

?eljko
--
watir.com - community manager
watirpodcast.com - host
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091106/84ba7224/attachment.html>

From bret at pettichord.com  Fri Nov  6 10:04:56 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Fri, 6 Nov 2009 09:04:56 -0600
Subject: [Wtr-development] Wtr-core
In-Reply-To: <f81b1250911060339l7e653cf6h50bf6dfc31c1483e@mail.gmail.com>
References: <f81b1250911060339l7e653cf6h50bf6dfc31c1483e@mail.gmail.com>
Message-ID: <ade75c5b0911060704p49d082b7ge0ad5a1af071249d@mail.gmail.com>

Sure. It is a private list that I don't use any more.

Bret

On Fri, Nov 6, 2009 at 5:39 AM, ?eljko Filipin <
zeljko.filipin at wa-research.ch> wrote:

> Should we make Wtr-core read only?
>
> http://rubyforge.org/pipermail/wtr-core/
>
> Nobody used it in more than a year.
>
> ?eljko
> --
> watir.com - community manager
> watirpodcast.com - host
>
>
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>



-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091106/69bd5ee4/attachment.html>

From zeljko.filipin at wa-research.ch  Fri Nov  6 10:30:54 2009
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Fri, 6 Nov 2009 16:30:54 +0100
Subject: [Wtr-development] Wtr-core
In-Reply-To: <ade75c5b0911060704p49d082b7ge0ad5a1af071249d@mail.gmail.com>
References: <f81b1250911060339l7e653cf6h50bf6dfc31c1483e@mail.gmail.com> 
	<ade75c5b0911060704p49d082b7ge0ad5a1af071249d@mail.gmail.com>
Message-ID: <f81b1250911060730j72e0dc7csce430d762876e7bd@mail.gmail.com>

On Fri, Nov 6, 2009 at 4:04 PM, Bret Pettichord <bret at pettichord.com> wrote:
> Sure. It is a private list that I don't use any more.

Moved it to archive page:

http://wiki.openqa.org/display/WTR/Archive

It had the same password as wtr-general, so I was able to set it to read
only.

?eljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091106/064e1602/attachment.html>

From notethan at gmail.com  Sat Nov  7 19:53:08 2009
From: notethan at gmail.com (Ethan)
Date: Sat, 7 Nov 2009 19:53:08 -0500
Subject: [Wtr-development] container methods returning nil; bang-methods
In-Reply-To: <ade75c5b0910102206l4fc4061buaad8eaf325d4a51a@mail.gmail.com>
References: <ade75c5b0910101350lb2a2caenba792d76e8b3f740@mail.gmail.com> 
	<0016367b6cb4d2d62004759b8d49@google.com>
	<ade75c5b0910102206l4fc4061buaad8eaf325d4a51a@mail.gmail.com>
Message-ID: <f58506c40911071653k149c3b84y18474927cbeeebe0@mail.gmail.com>

Well, it seems like this is all the feedback there is likely to be, and the
majority wants things the way they are. My current git fork is changed to
reflect this. Mostly.
I left the bang-method in - this is useful to me to replace the rather
frequent case I run into where I do

div=ie.div(:text, some_text)
unless div.exists?
  raise "the specified div doesn't exist"
end

I check immediately, because raising the error later on when I try to use
the div (the standard method for watir's unit tests), at some other point in
my code, would make debugging a nightmare - having to trace back through to
where the div was instantiated, which is sometimes very far-removed from
where it is used. I want things to fail immediately, so I use the
bang-method.
(on reflection I guess I should just be doing div.assert_exists - though
that's private, so div.send(:assert_exists) - ah well, I inherited the code
I work on, and that is among many things that I'd have done differently.
same idea in any case.)

I added another method to perform the behavior that I had container methods
such as Container#div doing - returning an Div when the element exists;
returning nil on nonexistence - to happen in new method, Container#div?
This is a bit of a break from ruby convention where question methods return
true/false (though even ruby core doesn't strictly adhere to that), but I
think it is appropriate, as the point is to use it in conditionals where I
would otherwise have to separate retrieving the div and checking its
existence.

So, to summarize:
? container.div(how, what) => Div, always, whether exists or not
? container.div!(how, what) => Div or raise UnknownObjectException
? container.div?(how, what) => Div or nil

It seems like perhaps an excessive number of methods for basically the same
operation. But, the first one has basically no place in my code, as I always
want to immediately error or check existence, never just pass a nonexistent
element along to be used. But, that is what this community is used to and
wants, so it stays. and the latter two are too useful for me to remove from
my fork - and hopefully the community will find them useful as well?

-Ethan


On Sun, Oct 11, 2009 at 00:06, Bret Pettichord <bret at pettichord.com> wrote:

> That sounds right.
>
>
> On Sat, Oct 10, 2009 at 4:41 PM, <tim.koops at gmail.com> wrote:
>
>> Initially as a user I just expected it to work this way...
>>
>> unless browser.div(:id, 'body').button(:id, 'save') ...
>>
>> But it didn't take long through the examples to learn about the exists?
>> method. I primarily rely on Waiter to do my syncing between pages, often
>> just looking for text rather than page elements
>>
>> Watir::Waiter.wait_until{ browser.html.include?("domloaded") }
>>
>> My understanding is that I could change that block to be
>>
>> Watir::Waiter.wait_until{ browser.div(:id, 'body').button(:id,
>> 'save').exists? }
>>
>> and would achieve the same goal no?
>>
>>
>>
>> On 11/10/2009 7:50am, Bret Pettichord <bret at pettichord.com> wrote:
>> > Ethan,
>> >
>> > Thanks for your thoughtful comments.
>> >
>> > Originally, I wanted exists? to work this way:
>> >
>> >    browser.div(:id, 'body').button(:id, 'save').exists?
>> >
>> > would return false if either the div or the button didn't exist. We've
>> never implemented it to work this way, but I think it would still be a good
>> idea and more in line with the expectations and needs of our typical users.
>> I would welcome a patch that made Watir work this way. Your proposal would
>> not make this possible.
>> >
>> >
>> > As you note, the current implementation does provide better error
>> reporting that what we'd get with your proposal. Very early versions of
>> Watir, in fact, worked as you suggest -- it is the "natural" and easiest way
>> of implementing it. But we added support for the current, less-natural
>> behavior because it allowed us to give more helpful error messages to our
>> users.
>> >
>> >
>> > Bret
>> >
>> > On Sat, Oct 10, 2009 at 3:12 PM, Ethan notethan at gmail.com> wrote:
>> >
>> > I'm breaking this off into a separate thread as it is the most major
>> change I made, and the most subject to discussion. (Same Ethan here, but at
>> home instead of at work.)
>> >
>> >
>> >
>> >
>> > On Sat, Oct 10, 2009 at 3:22 AM, Ethan wrote:
>> >
>> >
>> >
>> >
>> >
>> > The most major user-facing change is that I have made Container methods
>> named after elements (such as #text_field, #div) return nil if the specified
>> element does not exist. The previous practice of returning an element that
>> did not exist, and then calling exists? to check if it exists, seemed
>> unproductive to me; returning nil rather than a non-existent (and therefore
>> pretty useless) object seems more natural.
>> >
>> >
>> >
>> >
>> > I have also added corresponding bang-methods (#text_field!, #div!) that
>> error with Watir::Exception::UnknownObjectException if the specified element
>> does not exist. These are useful when you expect that an element will be
>> where you are looking, and it not being there is, well, exceptional. This
>> seems more logical than raising UnknownObjectException when trying to use
>> any method on a nonexistent object - error when instantiating an element, if
>> it is expected to exist, rather than when using it later on.
>> >
>> >
>> >
>> >
>> >
>> > Jari Bakken wrote:
>> > This is a mistake in my opinion. The returned object is not useless - it
>> contains information about how to locate the element on the page. I don't
>> see any real benefits to changing this, AND it breaks
>> backwards compatibility. There are some benefits to the way it's
>> currently working though, especially when writing abstractions around
>> Watir objects. Consider this example:
>> >
>> >
>> >
>> >
>> > http://gist.github.com/206839
>> >
>> >
>> >
>> >
>> > One of the benefits of Watir over Selenium++ IMO have always been
>> that it's more object-oriented - and the 'lazy locate' is definitely part of
>> what makes the above example easy to write.
>> >
>> >
>> >
>> >
>> > Ethan wrote:
>> >
>> >
>> >
>> >
>> >
>> > I have also added corresponding bang-methods (#text_field!, #div!) that
>> error with Watir::Exception::UnknownObjectException if the specified element
>> does not exist. These are useful when you expect that an element will be
>> where you are looking, and it not being there is, well, exceptional. This
>> seems more logical than raising UnknownObjectException when trying to use
>> any method on a nonexistent object - error when instantiating an element, if
>> it is expected to exist, rather than when using it later on.
>> >
>> >
>> >
>> >
>> >
>> > Jari Bakken wrote:
>> >
>> >
>> > This goes against API design princible of making "common things easy and
>> rare things possible" - in most cases you want the exception raised, so that
>> should be the default syntax. I would have to add exclamation marks all over
>> my code. Also this is tied to the previous point - i.e. these methods are
>> only needed if the nil change is accepted (which I'm against).
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > For me at least - for my usage of Watir - it is not the case that it
>> goes against the principle of making common things easiest. In my case I am
>> testing a page and not certain of whether an element is on the page where I
>> am looking, and I always have to check .exists? before I continue. just
>> checking the return value of the container method would be more
>> straightforward.
>> >
>> >
>> >
>> > This is in contrast with how the Watir unit tests tend to operate, where
>> they interact with static pages, and it is expected that elements are where
>> they are. My own usage and the unit tests are the only two usages of Watir I
>> am particularly aware of; I would be interested to know if other people's
>> usage is more similar to one or the other of those.
>> >
>> >
>> >
>> >
>> >
>> > The change to returning nil is only any different when an object doesn't
>> exist. In that case, it's still returning a value that does not correspond
>> to any element on the page: my way, it's nil; the current way, it's an
>> element that can't be located and will raise exception if used.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > the returned object is not useless - it contains information about how
>> to locate the element on the page.
>> >
>> >
>> >
>> >
>> > What use is this information? The element is not on the page, so knowing
>> how to locate it doesn't really do much good.
>> >
>> >
>> >
>> > The exception to that (the only one I can think of) is where AJAX loads
>> elements onto a page - this is a discussion that I had with a coworker
>> regarding this change. The example was elements appearing in the dom due to
>> ajax calls, so say we do:
>> >
>> >
>> >
>> >
>> >
>> > javascript_button=browser.button(:id, 'foo') # say this button causes a
>> table to pop into existence when clickedjavascript_button.click
>>
>> >
>> >
>> > table=browser.table :id, 'newly_existing_table'
>> >
>> >
>> >
>> >
>> > that will fail if the #click calls to something that returns before
>> 'newly_existing_table' pops into existence, as with an ajax call or a
>> setTimeout.
>> >
>> >
>> > to make it work the old way, it would be something like:
>> >
>> >
>> >
>> >
>> >
>> >
>> > table=browser.table :id, 'newly_existing_table'until table.exists?
>> >
>> >
>> >   sleep 1end
>> >
>> >
>> >
>> >
>> > my way, it would be something like:
>> >
>> >
>> >
>> >
>> >
>> > until table=browser.table :id, 'newly_existing_table'  sleep 1
>> >
>> >
>> > end
>> >
>> >
>> > Still, the latter seems more natural to me.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > it breaks backwards compatibility
>> >
>> >
>> >
>> > That is a major sticking point, it does break compatibility when
>> elements are not found.
>> > One possibility is defining nil.exists? => false. My project does this
>> (though I would prefer to remove reliance on it), and perhaps Watir
>> including this would improve transitioning (hypothetically, if this ends up
>> being the way things are done).
>> >
>> >
>> >
>> > But the exception raised on usage is different. Calling, say,
>> browser.text_field(:id, 'nonexistent').click raises "NoMethodError:
>> undefined method `click' for nil:NilClass"; the current way it
>> raises UnknownObjectException.
>> >
>> >
>> >
>> >
>> >
>> > It is indeed a major API change that would break things, but I think it
>> ends up being more natural and is worth the transition.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Consider this example:
>> >
>> >
>> >
>> > http://gist.github.com/206839
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > I think that my way actually improves this example. You don't need the
>> loading? method at all; it is implicit in the return value of loading_div.
>> #save can simply use  while !loading_div.
>> >
>> >
>> >
>> > You'd probably want to change browser.button(:id, 'save')
>> to browser.button!(:id, 'save'), since you expect it to exist (since it gets
>> clicked without checking .exists?). That runs into the issue you mention of
>> adding !s all over the code.
>> >
>> >
>> >
>> >
>> >
>> > I think of the ! as your code asserting that it expects a thing to
>> exist, and expects the error if it doesn't. Before, it was implied that code
>> always expected an element to exist, and had to go out of its way calling
>> .exists? if it wasn't sure. That just wasn't consistent with how I used
>> Watir. But maybe my usage is not the norm.
>> >
>> >
>> >
>> >
>> >
>> > Ethan
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> >
>> > Wtr-development mailing list
>> >
>> > Wtr-development at rubyforge.org
>> >
>> > 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
>> Wtr-development at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wtr-development
>>
>
>
>
> --
> Bret Pettichord
> Lead Developer, Watir, www.watir.com
>
> Blog, www.io.com/~wazmo/blog
> Twitter, www.twitter.com/bpettichord
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091107/ba1339b8/attachment-0001.html>

From bret at pettichord.com  Sun Nov  8 14:03:00 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Sun, 8 Nov 2009 13:03:00 -0600
Subject: [Wtr-development] container methods returning nil; bang-methods
In-Reply-To: <f58506c40911071653k149c3b84y18474927cbeeebe0@mail.gmail.com>
References: <ade75c5b0910101350lb2a2caenba792d76e8b3f740@mail.gmail.com>
	<0016367b6cb4d2d62004759b8d49@google.com>
	<ade75c5b0910102206l4fc4061buaad8eaf325d4a51a@mail.gmail.com>
	<f58506c40911071653k149c3b84y18474927cbeeebe0@mail.gmail.com>
Message-ID: <ade75c5b0911081103w48d731d8y31bb772e37c7b0fb@mail.gmail.com>

On Sat, Nov 7, 2009 at 6:53 PM, Ethan <notethan at gmail.com> wrote:

> Well, it seems like this is all the feedback there is likely to be, and the
> majority wants things the way they are. My current git fork is changed to
> reflect this. Mostly.
> I left the bang-method in - this is useful to me to replace the rather
> frequent case I run into where I do
>
> div=ie.div(:text, some_text)
> unless div.exists?
>   raise "the specified div doesn't exist"
> end
>

another way to do this is so:

div=ie.div(:text, some_text)
div.assert_exists
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091108/50fd0792/attachment.html>

From angrez at gmail.com  Tue Nov 10 01:40:53 2009
From: angrez at gmail.com (Angrez Singh)
Date: Tue, 10 Nov 2009 12:10:53 +0530
Subject: [Wtr-development] Cookies in FireWatir
Message-ID: <e26bda3e0911092240l52481b91l7fc8c5dc713e2ad1@mail.gmail.com>

Hi,

We are getting a lot of requests for deleting the cookies in FireWatir. I
know how to do that with JSSh. All i need to know is what method does Watir
exposes for cookies so that methods in Firewatir should be compatible.

Thanks,
Angrez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091110/e31253d3/attachment.html>

From bret at pettichord.com  Wed Nov 11 12:29:21 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 11 Nov 2009 11:29:21 -0600
Subject: [Wtr-development] Resolved tickets in Jira
In-Reply-To: <f81b1250911060247j714f879x67d75a9af581e6d6@mail.gmail.com>
References: <f81b1250911060247j714f879x67d75a9af581e6d6@mail.gmail.com>
Message-ID: <ade75c5b0911110929oedfb92ci16adced36db3c7e4@mail.gmail.com>

I dunno. Go ahead and close them if you want. In theory the person who
opened the ticket should close it, but I really get the sense that people
don't want to use Jira.

Right now I'm wondering about all the new tickets that were recently moved
in. Is any one looking at them? Any one want to give them a pass and close
tickets that are duplications or not-reproducible?

Bret

On Fri, Nov 6, 2009 at 4:47 AM, ?eljko Filipin <
zeljko.filipin at wa-research.ch> wrote:

> Why do we have 58 tickets marked as resolved in Jira, but not closed?
>
>
> http://jira.openqa.org/secure/IssueNavigator.jspa?reset=true&pid=10080&status=5
>
> ?eljko
> --
> watir.com - community manager
> watirpodcast.com - host
>
>
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>



-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091111/8e2c0271/attachment.html>

From angrez at gmail.com  Thu Nov 12 08:13:06 2009
From: angrez at gmail.com (Angrez Singh)
Date: Thu, 12 Nov 2009 18:43:06 +0530
Subject: [Wtr-development] Error while pulling changes from master
Message-ID: <e26bda3e0911120513j6cc724d5oeefbe122ea8ee58e@mail.gmail.com>

Hi,

I got following error message when I issue the command "git pull origin
master" from GIT command prompt.

$ git pull origin master
>From git at github.com:bret/watir
 * branch            master     -> FETCH_HEAD
error: Entry 'watir/bin/watir-console' not uptodate. Cannot merge.
fatal: merging of trees ef69d47d9f48a37ab5202e2701ad43e14f89e381 and
292e55fcd72
4ef7ea51946bebcc3f9bc862ee37d failed

Any thoughts?

- Angrez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091112/3c6ae28a/attachment.html>

From jari.bakken at gmail.com  Thu Nov 12 09:27:34 2009
From: jari.bakken at gmail.com (Jari Bakken)
Date: Thu, 12 Nov 2009 15:27:34 +0100
Subject: [Wtr-development] Error while pulling changes from master
In-Reply-To: <e26bda3e0911120513j6cc724d5oeefbe122ea8ee58e@mail.gmail.com>
References: <e26bda3e0911120513j6cc724d5oeefbe122ea8ee58e@mail.gmail.com>
Message-ID: <eae5f6f90911120627g65c6d43cwc466224c4b05a85a@mail.gmail.com>

On Thu, Nov 12, 2009 at 2:13 PM, Angrez Singh <angrez at gmail.com> wrote:
> Hi,
>
> I got following error message when I issue the command "git pull origin
> master" from GIT command prompt.
>
> $ git pull origin master
> From git at github.com:bret/watir
> ?* branch??????????? master???? -> FETCH_HEAD
> error: Entry 'watir/bin/watir-console' not uptodate. Cannot merge.
> fatal: merging of trees ef69d47d9f48a37ab5202e2701ad43e14f89e381 and
> 292e55fcd72
> 4ef7ea51946bebcc3f9bc862ee37d failed
>

You have local, uncommitted changes to watir/bin/watir-console. Either
commit the changes first or do `git stash && git pull && git stash
apply`.

From abaird at bairdsnet.net  Thu Nov 12 13:12:58 2009
From: abaird at bairdsnet.net (Alan Baird)
Date: Thu, 12 Nov 2009 12:12:58 -0600
Subject: [Wtr-development] Update to 1.6.5 rel. Notes?
Message-ID: <2a379a300911121012r11859bd1p3b500dc66edcee6e@mail.gmail.com>

Bret/Charley -

The fix for WTR-324 changed the way that table.each works when ran on nested
tables - specifically it ignores them.  I didn't see a mention of this in
the release notes and thought it might be waranted since it's a behavior
change.

Not trying to promote my own bugfix (you did that already) but I thought I
should mention it.

Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091112/af040f31/attachment.html>

From charley.baker at gmail.com  Thu Nov 12 13:42:16 2009
From: charley.baker at gmail.com (Charley Baker)
Date: Thu, 12 Nov 2009 11:42:16 -0700
Subject: [Wtr-development] Update to 1.6.5 rel. Notes?
In-Reply-To: <2a379a300911121012r11859bd1p3b500dc66edcee6e@mail.gmail.com>
References: <2a379a300911121012r11859bd1p3b500dc66edcee6e@mail.gmail.com>
Message-ID: <f96821860911121042r431a8e74vafb5e65d40eda3b9@mail.gmail.com>

Sounds like a good thing to mention. Can you update the release notes and
submit a pull request? Also, feel free to send a mail to the watir-general
list about the fix with specific examples.


- Charley

On Thu, Nov 12, 2009 at 11:12 AM, Alan Baird <abaird at bairdsnet.net> wrote:

> Bret/Charley -
>
> The fix for WTR-324 changed the way that table.each works when ran on
> nested tables - specifically it ignores them.  I didn't see a mention of
> this in the release notes and thought it might be waranted since it's a
> behavior change.
>
> Not trying to promote my own bugfix (you did that already) but I thought I
> should mention it.
>
> Alan
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091112/f0432912/attachment.html>

From notethan at gmail.com  Thu Nov 12 17:47:06 2009
From: notethan at gmail.com (Ethan)
Date: Thu, 12 Nov 2009 17:47:06 -0500
Subject: [Wtr-development] Watir changes
In-Reply-To: <f58506c40910220809r3d667e92p5da5dd1832e11a86@mail.gmail.com>
References: <7438EC0DB461E04182017BCB8DCC53AA052C403E@SECEXC004V.ad.mdsol.com>
	<eae5f6f90910100808o28f1e6c9w4406f04271cd42c3@mail.gmail.com> 
	<f58506c40910101420p4f6c0808u416e3677d1e59615@mail.gmail.com> 
	<ade75c5b0910101535q7684098j10c9c30dfed2eea1@mail.gmail.com> 
	<f58506c40910101658ia72838ao8f823dfadf5ae67f@mail.gmail.com> 
	<ade75c5b0910212118m75b1e10fjb57e23e41a900e3f@mail.gmail.com> 
	<f58506c40910220809r3d667e92p5da5dd1832e11a86@mail.gmail.com>
Message-ID: <f58506c40911121447p5815636eh310e8be005183213@mail.gmail.com>

As I move more and more code to commonwatir, I am ending up with numerous
browser-specific stub classes that look like
module Watir
  class FFTable < FFElement
    include Watir::Table
  end
end
(and the same with IE)
I'm thinking of restructuring to eliminate browser-specific classes, and
replace them with browser-specific modules where necessary. The new
structure I am thinking goes something like this:

class Watir::Element (common)
class Watir::FileField < Watir::Element (common)
module Watir::Firefox::Element
module Watir::Firefox::FileField - this exists only if there is actually
code that is browser-specific for this class. which is true for FileField,
but there would not exist any Watir::Firefox::Table.

And then, the browser-specific stuff would get dynamically added on
initialization, along the lines of:

class Watir::FileField
  def initialize
    if browser_class == Watir::Firefox
      extend Watir::Firefox::Element
    end
    # or, more generally, just `extend browser_class::Element`

    if browser_class.const_defined?('FileField')
      extend browser_class::FileField
    end
  end
end

browser_class, there, would come from the container in some manner.
I think this would help clean things up a bit, and this way elements all get
instantiated with the same class regardless of browser (and the name of the
class would be the same as Watir has used in the past, in IE).
I'm a bit of a ways off from actually implementing this, but I thought I
would see what thoughts people have on it.

-Ethan

On Thu, Oct 22, 2009 at 10:09, Ethan <notethan at gmail.com> wrote:

>
>
> On Thu, Oct 22, 2009 at 00:18, Bret Pettichord <bret at pettichord.com>wrote:
>
>> On Sat, Oct 10, 2009 at 6:58 PM, Ethan <notethan at gmail.com> wrote:
>>
>>> On Sat, Oct 10, 2009 at 18:35, Bret Pettichord <bret at pettichord.com>wrote:
>>>
>>>>
>>>> On Sat, Oct 10, 2009 at 4:20 PM, Ethan <notethan at gmail.com> wrote:
>>>>
>>>>>
>>>>>  I considered putting them in their own namespaces but I decided that
>>>>> would be too confusing. Say you have
>>>>>
>>>>>    - Watir::TextField for common
>>>>>    - Watir::IE::TextField
>>>>>    - Watir::Firefox::TextField
>>>>>
>>>>> I think it would get confusing when you are in, say, the Watir::Firefox
>>>>> namespace, whether an unprefixed TextField is meant to refer to the common
>>>>> one or the firefox one.
>>>>>
>>>>
>> I'm not too worried about this. We can always use this syntax for
>> references to avoid any possible misunderstanding:
>>
>> ::Watir::Textfield
>> ::Watir::IE::Textfield
>>
>> and just agree not to have unprefixed TextField in our source.
>>
>>
>>
>>>  Maybe
>>>>>
>>>>>    - Watir::Common::TextField
>>>>>    - Watir::IE::TextField
>>>>>    - Watir::Firefox::Textfield
>>>>>
>>>>> I like this.
>>>>
>>>> BTW, this is a big change and really needs to be discussed in the
>>>> context of how we want to structure Watir 2.0.
>>>>
>>>>
>>>>> so that in any namespace you have to prefix the other's namespace. But
>>>>> that would break everything that checks stuff like
>>>>> foo.is_a?(Watir::TextField) - I named the common one after the existing IE
>>>>> one so that that would still work. (it still breaks backwards compatibility
>>>>> if code uses foo.class==Watir::TextField, but is_a? is generally
>>>>> recommended, so I figured this would be acceptable.)
>>>>>
>>>>
>> This is a good argument for using Watir::TextField instead of
>> Watir::Common::TextField
>>
>>
>>>
>>>>> Another possibility is
>>>>>
>>>>>    - Watir::TextField for common
>>>>>    - IEWatir::TextField
>>>>>    - FireWatir::TextField
>>>>>
>>>>> But I figured having separate browser-specific class names in one
>>>>> namespace was preferable to having identical class names in browser-specific
>>>>> namespaces.
>>>>>
>>>>
>> I agree with this point
>>
>>
>>>  I don't know which one of those I prefer, they all have their pros and
>>> cons. I am inclined toward one of the first two, as breaking existing
>>> foo.is_a?(Watir::TextField) seems like a bigger negative than having
>>> different names (FFTextField and TextField) or ambiguity in some namespace.
>>>
>>
>> I think i agree that not breaking x.is_a? is a good idea. (Not sure at
>> this point whether I'm agreeing with myself or not.)
>>
>>
>>>  ? Watir::TextField
>>> ? Watir::IETextField
>>> ? Watir::FFTextField
>>> all in the same top namespace, no ambiguity referring to TextField, but
>>> prefixes mean class-specific ones aren't consistently named TextField.
>>>
>>>
>>> ? Watir::TextField
>>> ? Watir::IE::TextField
>>> ? Watir::Firefox::TextField
>>> all in the same top namespace, all consistently named TextField, but
>>> ambiguous in browser namespace.
>>>
>>
>> So now i am leaning towards this one.
>>
>>
>>>  ? Watir::Common::TextField
>>> ? Watir::IE::TextField
>>> ? Watir::Firefox::Textfield
>>> all in the same top namespace, consistent names, no ambiguity, but breaks
>>> existing code checking for Watir::TextField.
>>> Bret Pettichord says: I like this.
>>>
>>>
>>> ? Watir::TextField for common
>>> ? IEWatir::TextField
>>> ? FireWatir::TextField
>>> different top-level namespace, so no ambiguity, all consistently named
>>> TextField.
>>>
>>>
>> I think i would like get this restructuring in for 1.7.0, along with some
>> restructuring of how things are broken into gems. (Actually, i think i would
>> like to start using git submodules: can someone recommend a place for me to
>> learn how to use them?)
>>
>> Bret
>>
>>
>
> Okay, sounds good to me - I'm on board with
>
> ? Watir::TextField
> ? Watir::IE::TextField
> ? Watir::Firefox::TextField
>
> Ethan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091112/1f31019c/attachment-0001.html>

From abaird at bairdsnet.net  Thu Nov 12 21:17:35 2009
From: abaird at bairdsnet.net (Alan Baird)
Date: Thu, 12 Nov 2009 20:17:35 -0600
Subject: [Wtr-development] Update to 1.6.5 rel. Notes?
In-Reply-To: <f96821860911121042r431a8e74vafb5e65d40eda3b9@mail.gmail.com>
References: <2a379a300911121012r11859bd1p3b500dc66edcee6e@mail.gmail.com>
	<f96821860911121042r431a8e74vafb5e65d40eda3b9@mail.gmail.com>
Message-ID: <2a379a300911121817hc2f75adv792ab646484b0df8@mail.gmail.com>

Sure...I can do that this weekend.

Alan

On Thu, Nov 12, 2009 at 12:42 PM, Charley Baker <charley.baker at gmail.com>wrote:

> Sounds like a good thing to mention. Can you update the release notes and
> submit a pull request? Also, feel free to send a mail to the watir-general
> list about the fix with specific examples.
>
>
> - Charley
>
> On Thu, Nov 12, 2009 at 11:12 AM, Alan Baird <abaird at bairdsnet.net> wrote:
>
>> Bret/Charley -
>>
>> The fix for WTR-324 changed the way that table.each works when ran on
>> nested tables - specifically it ignores them.  I didn't see a mention of
>> this in the release notes and thought it might be waranted since it's a
>> behavior change.
>>
>> Not trying to promote my own bugfix (you did that already) but I thought I
>> should mention it.
>>
>> Alan
>>
>> _______________________________________________
>> Wtr-development mailing list
>> Wtr-development at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wtr-development
>>
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091112/8148c1b6/attachment.html>

From angrez at gmail.com  Fri Nov 13 06:55:36 2009
From: angrez at gmail.com (Angrez Singh)
Date: Fri, 13 Nov 2009 17:25:36 +0530
Subject: [Wtr-development] Release 1.6.5rc2?
In-Reply-To: <ade75c5b0910142120s7c07d6bpda67bcba584bbacf@mail.gmail.com>
References: <f96821860910131029i3eace760y601801c7e2f524c2@mail.gmail.com> 
	<e26bda3e0910141016i2b20f35cj9fddc7861e381244@mail.gmail.com> 
	<f96821860910141202g45aa0a07j616d505af248e17b@mail.gmail.com> 
	<ade75c5b0910141804k501ec724o510fc94e5533c670@mail.gmail.com> 
	<e26bda3e0910142011m426fc5d3t885b3495b5239d2@mail.gmail.com> 
	<ade75c5b0910142031qf4a25d8uadae142a328cf6a0@mail.gmail.com> 
	<e26bda3e0910142106v49a408c3n3861deccec1cde80@mail.gmail.com> 
	<ade75c5b0910142113o9cfc3cdhc074c9fabbb57429@mail.gmail.com> 
	<f58506c40910142115h30cf17c8oc7538affcc9434bd@mail.gmail.com> 
	<ade75c5b0910142120s7c07d6bpda67bcba584bbacf@mail.gmail.com>
Message-ID: <e26bda3e0911130355l6a4962bej7d43f62f739a9e79@mail.gmail.com>

Bret,

Did any of these changes made to 1.6.5 release?

- Angrez

On Thu, Oct 15, 2009 at 9:50 AM, Bret Pettichord <bret at pettichord.com>wrote:

>
> http://github.com/angrez/watir/commit/f4cb4c22a5c7cc2ee4fa1ba81d6e972cb7d34de0
>
>
> On Wed, Oct 14, 2009 at 11:15 PM, Ethan <notethan at gmail.com> wrote:
>
>> Can you link to the github fork in question?
>>
>> On Thu, Oct 15, 2009 at 00:13, Bret Pettichord <bret at pettichord.com>wrote:
>>
>>>
>>>
>>> On Wed, Oct 14, 2009 at 11:06 PM, Angrez Singh <angrez at gmail.com> wrote:
>>>
>>>> 2. In the future, it makes it easier if each change is in a separate
>>>>> commit.
>>>>>
>>>> Will do that from next time onwards.
>>>>
>>>>> 3. I think i'm fine with close_all and click_no_wait, although i only
>>>>> looked at the code briefly. Do we have tests for these?
>>>>> 4. I'd like to hold off on logon and click_js_popup_button. These
>>>>> appear to be new methods, not in Watir::IE and I'd like to review the method
>>>>> names and signatures, and consider these for 1.7.0.
>>>>>
>>>>> We need click_js_popup_button method to click the buttons on javascript
>>>> alerts. Thats why I added click_no_wait method. Earlier pop up handling was
>>>> different. So I think we should either add all or just close_all method. Yes
>>>> there are unit test cases of each new function.
>>>>
>>>
>>> I think the method for doing this is different in Watir::IE. I'm
>>> wondering if we want to introduce an inconsistency here.
>>>
>>> Bret
>>>
>>> --
>>> 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
>>> Wtr-development at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/wtr-development
>>>
>>
>>
>> _______________________________________________
>> Wtr-development mailing list
>> Wtr-development at rubyforge.org
>> 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
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091113/2b1fd094/attachment.html>

From bret at pettichord.com  Fri Nov 13 14:32:07 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Fri, 13 Nov 2009 13:32:07 -0600
Subject: [Wtr-development] Release 1.6.5rc2?
In-Reply-To: <e26bda3e0911130355l6a4962bej7d43f62f739a9e79@mail.gmail.com>
References: <f96821860910131029i3eace760y601801c7e2f524c2@mail.gmail.com>
	<f96821860910141202g45aa0a07j616d505af248e17b@mail.gmail.com>
	<ade75c5b0910141804k501ec724o510fc94e5533c670@mail.gmail.com>
	<e26bda3e0910142011m426fc5d3t885b3495b5239d2@mail.gmail.com>
	<ade75c5b0910142031qf4a25d8uadae142a328cf6a0@mail.gmail.com>
	<e26bda3e0910142106v49a408c3n3861deccec1cde80@mail.gmail.com>
	<ade75c5b0910142113o9cfc3cdhc074c9fabbb57429@mail.gmail.com>
	<f58506c40910142115h30cf17c8oc7538affcc9434bd@mail.gmail.com>
	<ade75c5b0910142120s7c07d6bpda67bcba584bbacf@mail.gmail.com>
	<e26bda3e0911130355l6a4962bej7d43f62f739a9e79@mail.gmail.com>
Message-ID: <ade75c5b0911131132x3bd2bd68n7147c77b19d232df@mail.gmail.com>

No they didn't. It looks like you just pushed the close_all method to
master.

Bret

On Fri, Nov 13, 2009 at 5:55 AM, Angrez Singh <angrez at gmail.com> wrote:

> Bret,
>
> Did any of these changes made to 1.6.5 release?
>
> - Angrez
>
>
> On Thu, Oct 15, 2009 at 9:50 AM, Bret Pettichord <bret at pettichord.com>wrote:
>
>>
>> http://github.com/angrez/watir/commit/f4cb4c22a5c7cc2ee4fa1ba81d6e972cb7d34de0
>>
>>
>> On Wed, Oct 14, 2009 at 11:15 PM, Ethan <notethan at gmail.com> wrote:
>>
>>> Can you link to the github fork in question?
>>>
>>> On Thu, Oct 15, 2009 at 00:13, Bret Pettichord <bret at pettichord.com>wrote:
>>>
>>>>
>>>>
>>>> On Wed, Oct 14, 2009 at 11:06 PM, Angrez Singh <angrez at gmail.com>wrote:
>>>>
>>>>> 2. In the future, it makes it easier if each change is in a separate
>>>>>> commit.
>>>>>>
>>>>> Will do that from next time onwards.
>>>>>
>>>>>> 3. I think i'm fine with close_all and click_no_wait, although i only
>>>>>> looked at the code briefly. Do we have tests for these?
>>>>>> 4. I'd like to hold off on logon and click_js_popup_button. These
>>>>>> appear to be new methods, not in Watir::IE and I'd like to review the method
>>>>>> names and signatures, and consider these for 1.7.0.
>>>>>>
>>>>>> We need click_js_popup_button method to click the buttons on
>>>>> javascript alerts. Thats why I added click_no_wait method. Earlier pop up
>>>>> handling was different. So I think we should either add all or just
>>>>> close_all method. Yes there are unit test cases of each new function.
>>>>>
>>>>
>>>> I think the method for doing this is different in Watir::IE. I'm
>>>> wondering if we want to introduce an inconsistency here.
>>>>
>>>> Bret
>>>>
>>>> --
>>>> 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
>>>> Wtr-development at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/wtr-development
>>>>
>>>
>>>
>>> _______________________________________________
>>> Wtr-development mailing list
>>> Wtr-development at rubyforge.org
>>> 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
>> Wtr-development at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wtr-development
>>
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>



-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091113/610bea96/attachment.html>

From zeljko.filipin at wa-research.ch  Sun Nov 15 16:35:57 2009
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Sun, 15 Nov 2009 22:35:57 +0100
Subject: [Wtr-development] Resolved tickets in Jira
In-Reply-To: <ade75c5b0911110929oedfb92ci16adced36db3c7e4@mail.gmail.com>
References: <f81b1250911060247j714f879x67d75a9af581e6d6@mail.gmail.com> 
	<ade75c5b0911110929oedfb92ci16adced36db3c7e4@mail.gmail.com>
Message-ID: <f81b1250911151335v277705ddvb3354945a95370b3@mail.gmail.com>

On Wed, Nov 11, 2009 at 6:29 PM, Bret Pettichord <bret at pettichord.com>
wrote:
> Go ahead and close them if you want. In theory the person who opened the
ticket should close it, but I really get the sense that people don't want to
use Jira.

When I get some time I will contact the reporters and ask them to close the
tickets. If that fails, I will try to verify and close them myself. If I see
I do not have the time for that, I will just close tickets that are resolved
more than a year ago. Some resolved (and not closed) tickets are from 2006.

?eljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091115/28c1b0dd/attachment-0001.html>

From bret at pettichord.com  Sun Nov 15 18:10:09 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Sun, 15 Nov 2009 17:10:09 -0600
Subject: [Wtr-development] Resolved tickets in Jira
In-Reply-To: <f81b1250911151335v277705ddvb3354945a95370b3@mail.gmail.com>
References: <f81b1250911060247j714f879x67d75a9af581e6d6@mail.gmail.com>
	<ade75c5b0911110929oedfb92ci16adced36db3c7e4@mail.gmail.com>
	<f81b1250911151335v277705ddvb3354945a95370b3@mail.gmail.com>
Message-ID: <ade75c5b0911151510i436b2eb5w65833cced91a44cd@mail.gmail.com>

That sounds fine.

On Sun, Nov 15, 2009 at 3:35 PM, ?eljko Filipin <
zeljko.filipin at wa-research.ch> wrote:

> On Wed, Nov 11, 2009 at 6:29 PM, Bret Pettichord <bret at pettichord.com>
> wrote:
> > Go ahead and close them if you want. In theory the person who opened the
> ticket should close it, but I really get the sense that people don't want to
> use Jira.
>
> When I get some time I will contact the reporters and ask them to close the
> tickets. If that fails, I will try to verify and close them myself. If I see
> I do not have the time for that, I will just close tickets that are resolved
> more than a year ago. Some resolved (and not closed) tickets are from 2006.
>
> ?eljko
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>



-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091115/df82ff81/attachment.html>

From tim.koops at gmail.com  Mon Nov 16 03:39:09 2009
From: tim.koops at gmail.com (Tim Koopmans)
Date: Mon, 16 Nov 2009 19:39:09 +1100
Subject: [Wtr-development] Watir across the grid
In-Reply-To: <93ee69e90911032121p758fd110x96db0f0eb1fe8a6@mail.gmail.com>
References: <93ee69e90911032121p758fd110x96db0f0eb1fe8a6@mail.gmail.com>
Message-ID: <93ee69e90911160039t34ac2d19nabed6809ab1a23d9@mail.gmail.com>

Hi guys,

In view of my last email about this I've decided to push on with druby
instead of http as I think the concepts surrounding distributed
computing are a good fit. This work has progressed since my last, you
can view the source here: http://github.com/90kts/watirgrid

I haven't been able to contact any of the original authors of dwatir
or watirgrid so ploughing ahead under my own direction. I've only been
testing on a local machine with a windows VM, so the next steps are to
test this approach in anger.

If you'd like to have a look at the source, or play with the gem feel
free (gemcutter is the primary source)
  gem install gemcutter
  gem tumble
  gem install watirgrid

I've also included some instructions and detailed examples in the
source as RDoc.

I'm heading for a railscamp this weekend so planning on tinkering with
watirgrid some more. As you can probably tell from my source, I'm a
tester-wannabe-developer so any general advice you have on
refactoring/structure/approach etc would be appreciated. I'll try and
round up some advice from railscamp.


Regards,
Tim Koopmans



On Wed, Nov 4, 2009 at 4:21 PM, Tim Koopmans <tim.koops at gmail.com> wrote:
> Hi guys,
>
> I've recently been tinkering with distributed testing across a grid
> network with Watir. This work is currently hosted on GitHub at
> http://github.com/90kts/watirgrid
>
> I based my initial design off DWatir[1] which uses Rinda to implement
> a tuple space: a repository of tuples that can be accessed
> concurrently. I've tried unsuccessfully to contact the original author
> Dane Avilla, which looks like development stopped in 2007.
>
> Since starting the GitHub project I've noticed a similar solution, not
> using Rinda (UDP broadcast over druby protocol) but WebBrick (http
> protocol) instead. It's also called WatirGrid[2] (oops!) and the
> author looks to be Peter Houghton.
>
> My end state is to facilitate some form of load testing with watir,
> using many browsers concurrently. I plan to release it as a separate
> gem. My preference so far is to continue with the druby protocol.
>
> Questions to you are do you have any preference on choice of protocol
> (druby vs. http) and does anyone know the original authors so that I
> might get in contact with them?
>
> [1] http://dwatir.rubyforge.org/
> [2] http://www.ohloh.net/p/watirgrid
>
> Regards,
> Tim Koopmans
>

From angrez at gmail.com  Mon Nov 16 04:49:38 2009
From: angrez at gmail.com (Angrez Singh)
Date: Mon, 16 Nov 2009 15:19:38 +0530
Subject: [Wtr-development] Release 1.6.5rc2?
In-Reply-To: <ade75c5b0911131132x3bd2bd68n7147c77b19d232df@mail.gmail.com>
References: <f96821860910131029i3eace760y601801c7e2f524c2@mail.gmail.com> 
	<ade75c5b0910141804k501ec724o510fc94e5533c670@mail.gmail.com> 
	<e26bda3e0910142011m426fc5d3t885b3495b5239d2@mail.gmail.com> 
	<ade75c5b0910142031qf4a25d8uadae142a328cf6a0@mail.gmail.com> 
	<e26bda3e0910142106v49a408c3n3861deccec1cde80@mail.gmail.com> 
	<ade75c5b0910142113o9cfc3cdhc074c9fabbb57429@mail.gmail.com> 
	<f58506c40910142115h30cf17c8oc7538affcc9434bd@mail.gmail.com> 
	<ade75c5b0910142120s7c07d6bpda67bcba584bbacf@mail.gmail.com> 
	<e26bda3e0911130355l6a4962bej7d43f62f739a9e79@mail.gmail.com> 
	<ade75c5b0911131132x3bd2bd68n7147c77b19d232df@mail.gmail.com>
Message-ID: <e26bda3e0911160149w6dc7de17id85f49eef04be432@mail.gmail.com>

Yeah I pushed it to master. Let me know if that is correct way to do. I am
having hard time here working with GIT.

- Angrez

On Sat, Nov 14, 2009 at 1:02 AM, Bret Pettichord <bret at pettichord.com>wrote:

> No they didn't. It looks like you just pushed the close_all method to
> master.
>
> Bret
>
>
> On Fri, Nov 13, 2009 at 5:55 AM, Angrez Singh <angrez at gmail.com> wrote:
>
>> Bret,
>>
>> Did any of these changes made to 1.6.5 release?
>>
>> - Angrez
>>
>>
>> On Thu, Oct 15, 2009 at 9:50 AM, Bret Pettichord <bret at pettichord.com>wrote:
>>
>>>
>>> http://github.com/angrez/watir/commit/f4cb4c22a5c7cc2ee4fa1ba81d6e972cb7d34de0
>>>
>>>
>>> On Wed, Oct 14, 2009 at 11:15 PM, Ethan <notethan at gmail.com> wrote:
>>>
>>>> Can you link to the github fork in question?
>>>>
>>>> On Thu, Oct 15, 2009 at 00:13, Bret Pettichord <bret at pettichord.com>wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Oct 14, 2009 at 11:06 PM, Angrez Singh <angrez at gmail.com>wrote:
>>>>>
>>>>>> 2. In the future, it makes it easier if each change is in a separate
>>>>>>> commit.
>>>>>>>
>>>>>> Will do that from next time onwards.
>>>>>>
>>>>>>> 3. I think i'm fine with close_all and click_no_wait, although i only
>>>>>>> looked at the code briefly. Do we have tests for these?
>>>>>>> 4. I'd like to hold off on logon and click_js_popup_button. These
>>>>>>> appear to be new methods, not in Watir::IE and I'd like to review the method
>>>>>>> names and signatures, and consider these for 1.7.0.
>>>>>>>
>>>>>>> We need click_js_popup_button method to click the buttons on
>>>>>> javascript alerts. Thats why I added click_no_wait method. Earlier pop up
>>>>>> handling was different. So I think we should either add all or just
>>>>>> close_all method. Yes there are unit test cases of each new function.
>>>>>>
>>>>>
>>>>> I think the method for doing this is different in Watir::IE. I'm
>>>>> wondering if we want to introduce an inconsistency here.
>>>>>
>>>>> Bret
>>>>>
>>>>> --
>>>>> 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
>>>>> Wtr-development at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/wtr-development
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Wtr-development mailing list
>>>> Wtr-development at rubyforge.org
>>>> 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
>>> Wtr-development at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/wtr-development
>>>
>>
>>
>> _______________________________________________
>> Wtr-development mailing list
>> Wtr-development at rubyforge.org
>> 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
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091116/4732b526/attachment.html>

From bret at pettichord.com  Mon Nov 16 17:24:24 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Mon, 16 Nov 2009 16:24:24 -0600
Subject: [Wtr-development] Release 1.6.5rc2?
In-Reply-To: <e26bda3e0911160149w6dc7de17id85f49eef04be432@mail.gmail.com>
References: <f96821860910131029i3eace760y601801c7e2f524c2@mail.gmail.com>
	<e26bda3e0910142011m426fc5d3t885b3495b5239d2@mail.gmail.com>
	<ade75c5b0910142031qf4a25d8uadae142a328cf6a0@mail.gmail.com>
	<e26bda3e0910142106v49a408c3n3861deccec1cde80@mail.gmail.com>
	<ade75c5b0910142113o9cfc3cdhc074c9fabbb57429@mail.gmail.com>
	<f58506c40910142115h30cf17c8oc7538affcc9434bd@mail.gmail.com>
	<ade75c5b0910142120s7c07d6bpda67bcba584bbacf@mail.gmail.com>
	<e26bda3e0911130355l6a4962bej7d43f62f739a9e79@mail.gmail.com>
	<ade75c5b0911131132x3bd2bd68n7147c77b19d232df@mail.gmail.com>
	<e26bda3e0911160149w6dc7de17id85f49eef04be432@mail.gmail.com>
Message-ID: <ade75c5b0911161424ic3064f8i3713f1ca2837f0f@mail.gmail.com>

It looks fine. Thanks!

On Mon, Nov 16, 2009 at 3:49 AM, Angrez Singh <angrez at gmail.com> wrote:

> Yeah I pushed it to master. Let me know if that is correct way to do. I am
> having hard time here working with GIT.
>
> - Angrez
>
>
> On Sat, Nov 14, 2009 at 1:02 AM, Bret Pettichord <bret at pettichord.com>wrote:
>
>> No they didn't. It looks like you just pushed the close_all method to
>> master.
>>
>> Bret
>>
>>
>> On Fri, Nov 13, 2009 at 5:55 AM, Angrez Singh <angrez at gmail.com> wrote:
>>
>>> Bret,
>>>
>>> Did any of these changes made to 1.6.5 release?
>>>
>>> - Angrez
>>>
>>>
>>> On Thu, Oct 15, 2009 at 9:50 AM, Bret Pettichord <bret at pettichord.com>wrote:
>>>
>>>>
>>>> http://github.com/angrez/watir/commit/f4cb4c22a5c7cc2ee4fa1ba81d6e972cb7d34de0
>>>>
>>>>
>>>> On Wed, Oct 14, 2009 at 11:15 PM, Ethan <notethan at gmail.com> wrote:
>>>>
>>>>> Can you link to the github fork in question?
>>>>>
>>>>> On Thu, Oct 15, 2009 at 00:13, Bret Pettichord <bret at pettichord.com>wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Oct 14, 2009 at 11:06 PM, Angrez Singh <angrez at gmail.com>wrote:
>>>>>>
>>>>>>> 2. In the future, it makes it easier if each change is in a separate
>>>>>>>> commit.
>>>>>>>>
>>>>>>> Will do that from next time onwards.
>>>>>>>
>>>>>>>> 3. I think i'm fine with close_all and click_no_wait, although i
>>>>>>>> only looked at the code briefly. Do we have tests for these?
>>>>>>>> 4. I'd like to hold off on logon and click_js_popup_button. These
>>>>>>>> appear to be new methods, not in Watir::IE and I'd like to review the method
>>>>>>>> names and signatures, and consider these for 1.7.0.
>>>>>>>>
>>>>>>>> We need click_js_popup_button method to click the buttons on
>>>>>>> javascript alerts. Thats why I added click_no_wait method. Earlier pop up
>>>>>>> handling was different. So I think we should either add all or just
>>>>>>> close_all method. Yes there are unit test cases of each new function.
>>>>>>>
>>>>>>
>>>>>> I think the method for doing this is different in Watir::IE. I'm
>>>>>> wondering if we want to introduce an inconsistency here.
>>>>>>
>>>>>> Bret
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>> Wtr-development at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/wtr-development
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Wtr-development mailing list
>>>>> Wtr-development at rubyforge.org
>>>>> 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
>>>> Wtr-development at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/wtr-development
>>>>
>>>
>>>
>>> _______________________________________________
>>> Wtr-development mailing list
>>> Wtr-development at rubyforge.org
>>> 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
>> Wtr-development at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wtr-development
>>
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>



-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091116/ad69a6ff/attachment-0001.html>

From notethan at gmail.com  Tue Nov 17 13:17:22 2009
From: notethan at gmail.com (Ethan)
Date: Tue, 17 Nov 2009 13:17:22 -0500
Subject: [Wtr-development] Watir::Simple
Message-ID: <f58506c40911171017n108daaabyf29161d7a9c02624@mail.gmail.com>

Is Watir::Simple supported anymore, or even used by anybody anymore?
I see no tests for it or anything, and mentions I have seen of it on the
mailing list seem to indicate that it is not really supported.
I think I'm going to drop it from my fork.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091117/8216c0a9/attachment.html>

From aidy.lewis at googlemail.com  Tue Nov 17 13:50:22 2009
From: aidy.lewis at googlemail.com (aidy lewis)
Date: Tue, 17 Nov 2009 18:50:22 +0000
Subject: [Wtr-development] Watir::Simple
In-Reply-To: <f58506c40911171017n108daaabyf29161d7a9c02624@mail.gmail.com>
References: <f58506c40911171017n108daaabyf29161d7a9c02624@mail.gmail.com>
Message-ID: <7ac2300c0911171050k5b36d9bey8241893988af8bf@mail.gmail.com>

Ethan,

Watir simple is old and not maintained. I think Bret left it in to
give people ideas about wrappers\frameworks.

Aidy

2009/11/17 Ethan <notethan at gmail.com>:
> Is Watir::Simple supported anymore, or even used by anybody anymore?
> I see no tests for it or anything, and mentions I have seen of it on the
> mailing list seem to indicate that it is not really supported.
> I think I'm going to drop it from my fork.
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>

From aidy.lewis at googlemail.com  Wed Nov 18 11:56:23 2009
From: aidy.lewis at googlemail.com (aidy lewis)
Date: Wed, 18 Nov 2009 16:56:23 +0000
Subject: [Wtr-development] js pop-ups internal within watir?
Message-ID: <7ac2300c0911180856n7e373fabm1e277c4effcab97f@mail.gmail.com>

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

From bret at pettichord.com  Wed Nov 18 12:17:38 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 18 Nov 2009 11:17:38 -0600
Subject: [Wtr-development] js pop-ups internal within watir?
In-Reply-To: <7ac2300c0911180856n7e373fabm1e277c4effcab97f@mail.gmail.com>
References: <7ac2300c0911180856n7e373fabm1e277c4effcab97f@mail.gmail.com>
Message-ID: <ade75c5b0911180917p419d0d22ya0b440533326f2c0@mail.gmail.com>

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 <aidy.lewis at googlemail.com>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
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>



-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091118/09f70781/attachment.html>

From notethan at gmail.com  Wed Nov 18 13:34:22 2009
From: notethan at gmail.com (Ethan)
Date: Wed, 18 Nov 2009 13:34:22 -0500
Subject: [Wtr-development] js pop-ups internal within watir?
In-Reply-To: <ade75c5b0911180917p419d0d22ya0b440533326f2c0@mail.gmail.com>
References: <7ac2300c0911180856n7e373fabm1e277c4effcab97f@mail.gmail.com> 
	<ade75c5b0911180917p419d0d22ya0b440533326f2c0@mail.gmail.com>
Message-ID: <f58506c40911181034h48392488y2983498a0c836bad@mail.gmail.com>

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 <bret at pettichord.com> 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 <aidy.lewis at googlemail.com>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
>> Wtr-development at rubyforge.org
>> 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
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091118/2396e1e6/attachment.html>

From paul.rogers at shaw.ca  Wed Nov 18 13:49:28 2009
From: paul.rogers at shaw.ca (Paul Rogers)
Date: Wed, 18 Nov 2009 11:49:28 -0700
Subject: [Wtr-development] js pop-ups internal within watir?
In-Reply-To: <f58506c40911181034h48392488y2983498a0c836bad@mail.gmail.com>
References: <7ac2300c0911180856n7e373fabm1e277c4effcab97f@mail.gmail.com>
	<ade75c5b0911180917p419d0d22ya0b440533326f2c0@mail.gmail.com>
	<f58506c40911181034h48392488y2983498a0c836bad@mail.gmail.com>
Message-ID: <e7eaafaa0911181049w75bcabb4k1946f3993f004bd1@mail.gmail.com>

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 <notethan at gmail.com> 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 <bret at pettichord.com>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 <aidy.lewis at googlemail.com>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
>>> Wtr-development at rubyforge.org
>>> 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
>> Wtr-development at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wtr-development
>>
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091118/3331a753/attachment-0001.html>

From abaird at bairdsnet.net  Thu Nov 19 00:00:28 2009
From: abaird at bairdsnet.net (Alan Baird)
Date: Wed, 18 Nov 2009 23:00:28 -0600
Subject: [Wtr-development] js pop-ups internal within watir?
In-Reply-To: <f58506c40911181034h48392488y2983498a0c836bad@mail.gmail.com>
References: <7ac2300c0911180856n7e373fabm1e277c4effcab97f@mail.gmail.com>
	<ade75c5b0911180917p419d0d22ya0b440533326f2c0@mail.gmail.com>
	<f58506c40911181034h48392488y2983498a0c836bad@mail.gmail.com>
Message-ID: <2a379a300911182100n680bcc18w7a38c70ecc09024b@mail.gmail.com>

Ethan -

Would your library support entering username and password credentials in a
basic authentication dialog box that pops up before you login to some
websites that are password protected?

Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091118/7828e87e/attachment.html>

From notethan at gmail.com  Thu Nov 19 00:22:02 2009
From: notethan at gmail.com (Ethan)
Date: Thu, 19 Nov 2009 00:22:02 -0500
Subject: [Wtr-development] js pop-ups internal within watir?
In-Reply-To: <2a379a300911182100n680bcc18w7a38c70ecc09024b@mail.gmail.com>
References: <7ac2300c0911180856n7e373fabm1e277c4effcab97f@mail.gmail.com> 
	<ade75c5b0911180917p419d0d22ya0b440533326f2c0@mail.gmail.com> 
	<f58506c40911181034h48392488y2983498a0c836bad@mail.gmail.com> 
	<2a379a300911182100n680bcc18w7a38c70ecc09024b@mail.gmail.com>
Message-ID: <f58506c40911182122j7541d7c8h3fd2105102a3a688@mail.gmail.com>

Mine doesn't currently, but it could - I don't think it would be very
difficult to add that functionality. I don't know what the API for that
should look like. something like,
Firefox#enter_authentication_dialog(username, password, button='OK')
perhaps.


On Thu, Nov 19, 2009 at 00:00, Alan Baird <abaird at bairdsnet.net> wrote:

> Ethan -
>
> Would your library support entering username and password credentials in a
> basic authentication dialog box that pops up before you login to some
> websites that are password protected?
>
> Alan
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091119/02684e9b/attachment.html>

From angrez at gmail.com  Thu Nov 19 02:22:33 2009
From: angrez at gmail.com (Angrez Singh)
Date: Thu, 19 Nov 2009 12:52:33 +0530
Subject: [Wtr-development] js pop-ups internal within watir?
In-Reply-To: <f58506c40911182122j7541d7c8h3fd2105102a3a688@mail.gmail.com>
References: <7ac2300c0911180856n7e373fabm1e277c4effcab97f@mail.gmail.com> 
	<ade75c5b0911180917p419d0d22ya0b440533326f2c0@mail.gmail.com> 
	<f58506c40911181034h48392488y2983498a0c836bad@mail.gmail.com> 
	<2a379a300911182100n680bcc18w7a38c70ecc09024b@mail.gmail.com> 
	<f58506c40911182122j7541d7c8h3fd2105102a3a688@mail.gmail.com>
Message-ID: <e26bda3e0911182322i6bd13693m81f543612d229c7b@mail.gmail.com>

I have changed the way Firewatir handles javascript pop ups. The changes are
there in my fork:
http://github.com/angrez/watir/commit/f4cb4c22a5c7cc2ee4fa1ba81d6e972cb7d34de0

Also there is method for entering username, password in the authentication
pop up as well.
Let me know if it makes some sense, then we can add it to master repository
as well.

- Angrez

On Thu, Nov 19, 2009 at 10:52 AM, Ethan <notethan at gmail.com> wrote:

> Mine doesn't currently, but it could - I don't think it would be very
> difficult to add that functionality. I don't know what the API for that
> should look like. something like,
> Firefox#enter_authentication_dialog(username, password, button='OK')
> perhaps.
>
>
> On Thu, Nov 19, 2009 at 00:00, Alan Baird <abaird at bairdsnet.net> wrote:
>
>> Ethan -
>>
>> Would your library support entering username and password credentials in a
>> basic authentication dialog box that pops up before you login to some
>> websites that are password protected?
>>
>> Alan
>>
>>
>> _______________________________________________
>> Wtr-development mailing list
>> Wtr-development at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wtr-development
>>
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091119/c073d5ec/attachment.html>

From ynot408 at gmail.com  Thu Nov 19 03:03:51 2009
From: ynot408 at gmail.com (! Tony !)
Date: Thu, 19 Nov 2009 13:33:51 +0530
Subject: [Wtr-development] js pop-ups internal within watir?
In-Reply-To: <f58506c40911182122j7541d7c8h3fd2105102a3a688@mail.gmail.com>
References: <7ac2300c0911180856n7e373fabm1e277c4effcab97f@mail.gmail.com>
	<ade75c5b0911180917p419d0d22ya0b440533326f2c0@mail.gmail.com>
	<f58506c40911181034h48392488y2983498a0c836bad@mail.gmail.com>
	<2a379a300911182100n680bcc18w7a38c70ecc09024b@mail.gmail.com>
	<f58506c40911182122j7541d7c8h3fd2105102a3a688@mail.gmail.com>
Message-ID: <8ac3ceb30911190003s74c6613aw6ac2926368915f52@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091119/0a904021/attachment.html>

From aidy.lewis at googlemail.com  Thu Nov 19 13:13:27 2009
From: aidy.lewis at googlemail.com (aidy lewis)
Date: Thu, 19 Nov 2009 18:13:27 +0000
Subject: [Wtr-development] Cookie Manipulation
Message-ID: <7ac2300c0911191013p7256b212q37d4fe07eecb6e63@mail.gmail.com>

>From Angrez sometime this week:

> Bret proposed the following syntax or method names via Google Wave, so we should stick to this:
> Browser#cookies (get cookies as ruby array of hashes)

> Browser#add_cookie(opts) where opts is a hash of :name, :value, :path, :secure and :name/:value will raise ArgumentError if not supplied

> Browser#remove_cookie(opts) where opts is a hash of :domain and :name

> Browser#remove_all_cookies or Browser#remove_cookie(:all)?


1. OK, but what about getting the cookies from a specific domain?
2. What are we to do with Celerity and Jarib's implementation?
3. Tony has already done a load of stuff here;
http://jira.openqa.org/browse/WTR-264 (Tony shall we work on this
together?)

Aidy

From ynot408 at gmail.com  Fri Nov 20 04:08:39 2009
From: ynot408 at gmail.com (! Tony !)
Date: Fri, 20 Nov 2009 14:38:39 +0530
Subject: [Wtr-development] Cookie Manipulation
In-Reply-To: <7ac2300c0911191013p7256b212q37d4fe07eecb6e63@mail.gmail.com>
References: <7ac2300c0911191013p7256b212q37d4fe07eecb6e63@mail.gmail.com>
Message-ID: <8ac3ceb30911200108h6b60101ci5839273b1f8421e9@mail.gmail.com>

Hi Aidy,

Sure, would love to work on this.

Thanks,
Tony

On Thu, Nov 19, 2009 at 11:43 PM, aidy lewis <aidy.lewis at googlemail.com>wrote:

> >From Angrez sometime this week:
>
> > Bret proposed the following syntax or method names via Google Wave, so we
> should stick to this:
> > Browser#cookies (get cookies as ruby array of hashes)
>
> > Browser#add_cookie(opts) where opts is a hash of :name, :value, :path,
> :secure and :name/:value will raise ArgumentError if not supplied
>
> > Browser#remove_cookie(opts) where opts is a hash of :domain and :name
>
> > Browser#remove_all_cookies or Browser#remove_cookie(:all)?
>
>
> 1. OK, but what about getting the cookies from a specific domain?
> 2. What are we to do with Celerity and Jarib's implementation?
> 3. Tony has already done a load of stuff here;
> http://jira.openqa.org/browse/WTR-264 (Tony shall we work on this
> together?)
>
> Aidy
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091120/c92ecb12/attachment-0001.html>

From angrez at gmail.com  Fri Nov 20 04:59:29 2009
From: angrez at gmail.com (Angrez Singh)
Date: Fri, 20 Nov 2009 15:29:29 +0530
Subject: [Wtr-development] Cookie Manipulation
In-Reply-To: <8ac3ceb30911200108h6b60101ci5839273b1f8421e9@mail.gmail.com>
References: <7ac2300c0911191013p7256b212q37d4fe07eecb6e63@mail.gmail.com> 
	<8ac3ceb30911200108h6b60101ci5839273b1f8421e9@mail.gmail.com>
Message-ID: <e26bda3e0911200159o49057b2ap3abe71cba617708c@mail.gmail.com>

Aidy,

Celerity currently has:

   - Browser#cookies (get cookies as ruby array of hashes)
   - Browser#add_cookie(domain, name, value, opts = {}) where opts can be
   :path, :expires, :secure
   - Browser#remove_cookie(domain, name)


So for getting cookie for a domain we can have something like cookies(domain
name), so if domain name is supplied it will get cookies only for that
domain else all the cookies. Let me know if that is fine.

Thanks,
Angrez


On Fri, Nov 20, 2009 at 2:38 PM, ! Tony ! <ynot408 at gmail.com> wrote:

> Hi Aidy,
>
> Sure, would love to work on this.
>
> Thanks,
> Tony
>
>
> On Thu, Nov 19, 2009 at 11:43 PM, aidy lewis <aidy.lewis at googlemail.com>wrote:
>
>> >From Angrez sometime this week:
>>
>> > Bret proposed the following syntax or method names via Google Wave, so
>> we should stick to this:
>> > Browser#cookies (get cookies as ruby array of hashes)
>>
>> > Browser#add_cookie(opts) where opts is a hash of :name, :value, :path,
>> :secure and :name/:value will raise ArgumentError if not supplied
>>
>> > Browser#remove_cookie(opts) where opts is a hash of :domain and :name
>>
>> > Browser#remove_all_cookies or Browser#remove_cookie(:all)?
>>
>>
>> 1. OK, but what about getting the cookies from a specific domain?
>> 2. What are we to do with Celerity and Jarib's implementation?
>> 3. Tony has already done a load of stuff here;
>> http://jira.openqa.org/browse/WTR-264 (Tony shall we work on this
>> together?)
>>
>> Aidy
>> _______________________________________________
>> Wtr-development mailing list
>> Wtr-development at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wtr-development
>>
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091120/8b8693b0/attachment.html>

From jari.bakken at gmail.com  Fri Nov 20 05:28:43 2009
From: jari.bakken at gmail.com (Jari Bakken)
Date: Fri, 20 Nov 2009 11:28:43 +0100
Subject: [Wtr-development] Cookie Manipulation
In-Reply-To: <e26bda3e0911200159o49057b2ap3abe71cba617708c@mail.gmail.com>
References: <7ac2300c0911191013p7256b212q37d4fe07eecb6e63@mail.gmail.com>
	<8ac3ceb30911200108h6b60101ci5839273b1f8421e9@mail.gmail.com>
	<e26bda3e0911200159o49057b2ap3abe71cba617708c@mail.gmail.com>
Message-ID: <eae5f6f90911200228w12ee7598xe83d6ed55357ad9b@mail.gmail.com>

On Fri, Nov 20, 2009 at 10:59 AM, Angrez Singh <angrez at gmail.com> wrote:
> Aidy,
>
> So for getting cookie for a domain we can have something like cookies(domain
> name), so if domain name is supplied it will get cookies only for that
> domain else all the cookies. Let me know if that is fine.
>

I'm not convinced that getting cookies for one domain needs to be part
of the API.  It's not a super-common use case and pretty simple to do
yourself with ruby

  browser.cookies.select { |c| c[:domain] == ".example.com" }

From aidy.lewis at googlemail.com  Fri Nov 20 08:12:08 2009
From: aidy.lewis at googlemail.com (aidy lewis)
Date: Fri, 20 Nov 2009 13:12:08 +0000
Subject: [Wtr-development] Cookie Manipulation
In-Reply-To: <8ac3ceb30911200108h6b60101ci5839273b1f8421e9@mail.gmail.com>
References: <7ac2300c0911191013p7256b212q37d4fe07eecb6e63@mail.gmail.com>
	<8ac3ceb30911200108h6b60101ci5839273b1f8421e9@mail.gmail.com>
Message-ID: <7ac2300c0911200512i650fe1ebv1cb50a1478e725cf@mail.gmail.com>

Hi Tony

2009/11/20 ! Tony ! <ynot408 at gmail.com>:
> Hi Aidy,
>
> Sure, would love to work on this.
>
> Thanks,
> Tony
>

I am then going to take this off-line.

Will be in touch

I am planning to do some work at weekend.

Aidy

From aidy.lewis at googlemail.com  Fri Nov 20 08:14:43 2009
From: aidy.lewis at googlemail.com (aidy lewis)
Date: Fri, 20 Nov 2009 13:14:43 +0000
Subject: [Wtr-development] Cookie Manipulation
In-Reply-To: <eae5f6f90911200228w12ee7598xe83d6ed55357ad9b@mail.gmail.com>
References: <7ac2300c0911191013p7256b212q37d4fe07eecb6e63@mail.gmail.com>
	<8ac3ceb30911200108h6b60101ci5839273b1f8421e9@mail.gmail.com>
	<e26bda3e0911200159o49057b2ap3abe71cba617708c@mail.gmail.com>
	<eae5f6f90911200228w12ee7598xe83d6ed55357ad9b@mail.gmail.com>
Message-ID: <7ac2300c0911200514lac575d3xd52d7f0940f153f2@mail.gmail.com>

Angrez, Jari,

I think Jari's got a good point on this one, but we will need to
provide this example in the RDoc.

I will show you what I have in a few days.

Aidy

2009/11/20 Jari Bakken <jari.bakken at gmail.com>:
> On Fri, Nov 20, 2009 at 10:59 AM, Angrez Singh <angrez at gmail.com> wrote:
>> Aidy,
>>
>> So for getting cookie for a domain we can have something like cookies(domain
>> name), so if domain name is supplied it will get cookies only for that
>> domain else all the cookies. Let me know if that is fine.
>>
>
> I'm not convinced that getting cookies for one domain needs to be part
> of the API. ?It's not a super-common use case and pretty simple to do
> yourself with ruby
>
> ?browser.cookies.select { |c| c[:domain] == ".example.com" }
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>

From simon.m.stewart at gmail.com  Mon Nov 23 11:20:32 2009
From: simon.m.stewart at gmail.com (Simon Stewart)
Date: Mon, 23 Nov 2009 16:20:32 +0000
Subject: [Wtr-development] Cookie Manipulation
In-Reply-To: <eae5f6f90911200228w12ee7598xe83d6ed55357ad9b@mail.gmail.com>
References: <7ac2300c0911191013p7256b212q37d4fe07eecb6e63@mail.gmail.com>
	<8ac3ceb30911200108h6b60101ci5839273b1f8421e9@mail.gmail.com>
	<e26bda3e0911200159o49057b2ap3abe71cba617708c@mail.gmail.com>
	<eae5f6f90911200228w12ee7598xe83d6ed55357ad9b@mail.gmail.com>
Message-ID: <77aa50680911230820o55d66308gbabb7a39fb3411f2@mail.gmail.com>

On Fri, Nov 20, 2009 at 10:28 AM, Jari Bakken <jari.bakken at gmail.com> wrote:
> On Fri, Nov 20, 2009 at 10:59 AM, Angrez Singh <angrez at gmail.com> wrote:
>> Aidy,
>>
>> So for getting cookie for a domain we can have something like cookies(domain
>> name), so if domain name is supplied it will get cookies only for that
>> domain else all the cookies. Let me know if that is fine.
>>
>
> I'm not convinced that getting cookies for one domain needs to be part
> of the API. ?It's not a super-common use case and pretty simple to do
> yourself with ruby
>
> ?browser.cookies.select { |c| c[:domain] == ".example.com" }

It's also extremely difficult to get any cookies which aren't already
visible to the browser on some browsers (Safari springs to mind).
That's why Selenium limits you to manipulating only the visible
cookies.

Simon

From bret at pettichord.com  Mon Nov 23 12:36:33 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Mon, 23 Nov 2009 11:36:33 -0600
Subject: [Wtr-development] Fwd: [GitHub] bendyworks sent you a message
In-Reply-To: <4b0ac138a2fd8_74383fe6b04ef2ec3ce@fe4.rs.github.com.tmail>
References: <4b0ac138a2fd8_74383fe6b04ef2ec3ce@fe4.rs.github.com.tmail>
Message-ID: <ade75c5b0911230936w3bac0046t86a78d7ce506dc6c@mail.gmail.com>

Any comments on this?

---------- Forwarded message ----------
From: GitHub <noreply at github.com>
Date: Mon, Nov 23, 2009 at 11:07 AM
Subject: [GitHub] bendyworks sent you a message
To: bret at pettichord.com




bendyworks wants you to pull from bendyworks/watir at master

Body: We added right_click and middle_click to element.rb in firewatir.
 Testing this proved quite problematic without pulling in a framework like
jQuery.  We are seeing the code work just fine in a customer project
however.

Since I'm assuming adding a dependence on jQuery is a no-no, this change is
without a test.  Any suggestions?

Thanks!
-Steve-

View repository: http://github.com/bendyworks/watir/tree/master



-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091123/8b5a522f/attachment.html>

From paul.rogers at shaw.ca  Mon Nov 23 13:16:29 2009
From: paul.rogers at shaw.ca (Paul Rogers)
Date: Mon, 23 Nov 2009 11:16:29 -0700
Subject: [Wtr-development] Fwd: [GitHub] bendyworks sent you a message
In-Reply-To: <ade75c5b0911230936w3bac0046t86a78d7ce506dc6c@mail.gmail.com>
References: <4b0ac138a2fd8_74383fe6b04ef2ec3ce@fe4.rs.github.com.tmail>
	<ade75c5b0911230936w3bac0046t86a78d7ce506dc6c@mail.gmail.com>
Message-ID: <e7eaafaa0911231016s4cedf54fs83e7ab80702ece27@mail.gmail.com>

looks like its Firefox only
http://github.com/bendyworks/watir/commit/bc024d859a270eeead9929a85c25f9e2328c96b5


Id like to see,

browser.link(:id, 'foo').click( :right_button )
or
browser.link(:id, 'foo').right_click

so then the unit test just needs a method on the html that responds to a
right click( I cant remember how to do that off hand otherwise I would have
given an example)
A right click method also brings up all sorrts of context menu questions (
ie does a right click bring the console menu up, or do some html specific
thing, and how is the context menu handled cross browser)

The event code I keep trying to do something with , probably handles the
right click, but ot the context menu stuff

Paul


On Mon, Nov 23, 2009 at 10:36 AM, Bret Pettichord <bret at pettichord.com>wrote:

> Any comments on this?
>
> ---------- Forwarded message ----------
> From: GitHub <noreply at github.com>
> Date: Mon, Nov 23, 2009 at 11:07 AM
> Subject: [GitHub] bendyworks sent you a message
> To: bret at pettichord.com
>
>
>
>
> bendyworks wants you to pull from bendyworks/watir at master
>
> Body: We added right_click and middle_click to element.rb in firewatir.
>  Testing this proved quite problematic without pulling in a framework like
> jQuery.  We are seeing the code work just fine in a customer project
> however.
>
> Since I'm assuming adding a dependence on jQuery is a no-no, this change is
> without a test.  Any suggestions?
>
> Thanks!
> -Steve-
>
> View repository: http://github.com/bendyworks/watir/tree/master
>
>
>
> --
> 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
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091123/186939fa/attachment-0001.html>

From notethan at gmail.com  Mon Nov 23 13:20:43 2009
From: notethan at gmail.com (Ethan)
Date: Mon, 23 Nov 2009 13:20:43 -0500
Subject: [Wtr-development] Fwd: [GitHub] bendyworks sent you a message
In-Reply-To: <ade75c5b0911230936w3bac0046t86a78d7ce506dc6c@mail.gmail.com>
References: <4b0ac138a2fd8_74383fe6b04ef2ec3ce@fe4.rs.github.com.tmail> 
	<ade75c5b0911230936w3bac0046t86a78d7ce506dc6c@mail.gmail.com>
Message-ID: <f58506c40911231020ue70f240sdaa00e9d260eb942@mail.gmail.com>

I don't like the function signature,
Element#click(button=0)
It isn't cross-browser (which number corresponds to which button varies from
browser to browser), and it's not at all readable.
Currently in my fork Element#click method implements an options hash with
default options of {:highlight => true, :wait => true} - by default it
highlights when it clicks, and waits after clicking.
I would like to see :button as an option hash key, with default of :left, so
a right-click would look like
element.click(:button => :right)

-Ethan

On Mon, Nov 23, 2009 at 12:36, Bret Pettichord <bret at pettichord.com> wrote:

> Any comments on this?
>
> ---------- Forwarded message ----------
> From: GitHub <noreply at github.com>
> Date: Mon, Nov 23, 2009 at 11:07 AM
> Subject: [GitHub] bendyworks sent you a message
> To: bret at pettichord.com
>
>
>
>
> bendyworks wants you to pull from bendyworks/watir at master
>
> Body: We added right_click and middle_click to element.rb in firewatir.
>  Testing this proved quite problematic without pulling in a framework like
> jQuery.  We are seeing the code work just fine in a customer project
> however.
>
> Since I'm assuming adding a dependence on jQuery is a no-no, this change is
> without a test.  Any suggestions?
>
> Thanks!
> -Steve-
>
> View repository: http://github.com/bendyworks/watir/tree/master
>
>
>
> --
> 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
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091123/7555a629/attachment.html>

From paul.rogers at shaw.ca  Mon Nov 23 13:30:51 2009
From: paul.rogers at shaw.ca (Paul Rogers)
Date: Mon, 23 Nov 2009 11:30:51 -0700
Subject: [Wtr-development] Fwd: [GitHub] bendyworks sent you a message
In-Reply-To: <e7eaafaa0911231016s4cedf54fs83e7ab80702ece27@mail.gmail.com>
References: <4b0ac138a2fd8_74383fe6b04ef2ec3ce@fe4.rs.github.com.tmail>
	<ade75c5b0911230936w3bac0046t86a78d7ce506dc6c@mail.gmail.com>
	<e7eaafaa0911231016s4cedf54fs83e7ab80702ece27@mail.gmail.com>
Message-ID: <e7eaafaa0911231030s38f5c43fvc76f7afb50a8b6f8@mail.gmail.com>

oh, and the units tests for the drag and drop stuff already include both
prototype and jquery ( as they were the commonest ways of doing drag and
drop in a browser when I did it)

Paul

On Mon, Nov 23, 2009 at 11:16 AM, Paul Rogers <paul.rogers at shaw.ca> wrote:

> looks like its Firefox only
>
> http://github.com/bendyworks/watir/commit/bc024d859a270eeead9929a85c25f9e2328c96b5
>
>
> Id like to see,
>
> browser.link(:id, 'foo').click( :right_button )
> or
> browser.link(:id, 'foo').right_click
>
> so then the unit test just needs a method on the html that responds to a
> right click( I cant remember how to do that off hand otherwise I would have
> given an example)
> A right click method also brings up all sorrts of context menu questions (
> ie does a right click bring the console menu up, or do some html specific
> thing, and how is the context menu handled cross browser)
>
> The event code I keep trying to do something with , probably handles the
> right click, but ot the context menu stuff
>
> Paul
>
>
> On Mon, Nov 23, 2009 at 10:36 AM, Bret Pettichord <bret at pettichord.com>wrote:
>
>> Any comments on this?
>>
>> ---------- Forwarded message ----------
>> From: GitHub <noreply at github.com>
>> Date: Mon, Nov 23, 2009 at 11:07 AM
>> Subject: [GitHub] bendyworks sent you a message
>> To: bret at pettichord.com
>>
>>
>>
>>
>> bendyworks wants you to pull from bendyworks/watir at master
>>
>> Body: We added right_click and middle_click to element.rb in firewatir.
>>  Testing this proved quite problematic without pulling in a framework like
>> jQuery.  We are seeing the code work just fine in a customer project
>> however.
>>
>> Since I'm assuming adding a dependence on jQuery is a no-no, this change
>> is without a test.  Any suggestions?
>>
>> Thanks!
>> -Steve-
>>
>> View repository: http://github.com/bendyworks/watir/tree/master
>>
>>
>>
>> --
>> 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
>> Wtr-development at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wtr-development
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091123/c89e4269/attachment.html>

From bret at pettichord.com  Mon Nov 23 13:34:21 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Mon, 23 Nov 2009 12:34:21 -0600
Subject: [Wtr-development] Fwd: [GitHub] bendyworks sent you a message
In-Reply-To: <e7eaafaa0911231030s38f5c43fvc76f7afb50a8b6f8@mail.gmail.com>
References: <4b0ac138a2fd8_74383fe6b04ef2ec3ce@fe4.rs.github.com.tmail>
	<ade75c5b0911230936w3bac0046t86a78d7ce506dc6c@mail.gmail.com>
	<e7eaafaa0911231016s4cedf54fs83e7ab80702ece27@mail.gmail.com>
	<e7eaafaa0911231030s38f5c43fvc76f7afb50a8b6f8@mail.gmail.com>
Message-ID: <ade75c5b0911231034s678f5feds3dcc7db8485b20eb@mail.gmail.com>

Can you point us to these?

On Mon, Nov 23, 2009 at 12:30 PM, Paul Rogers <paul.rogers at shaw.ca> wrote:

> oh, and the units tests for the drag and drop stuff already include both
> prototype and jquery ( as they were the commonest ways of doing drag and
> drop in a browser when I did it)
>
> Paul
>
>
> On Mon, Nov 23, 2009 at 11:16 AM, Paul Rogers <paul.rogers at shaw.ca> wrote:
>
>> looks like its Firefox only
>>
>> http://github.com/bendyworks/watir/commit/bc024d859a270eeead9929a85c25f9e2328c96b5
>>
>>
>> Id like to see,
>>
>> browser.link(:id, 'foo').click( :right_button )
>> or
>> browser.link(:id, 'foo').right_click
>>
>> so then the unit test just needs a method on the html that responds to a
>> right click( I cant remember how to do that off hand otherwise I would have
>> given an example)
>> A right click method also brings up all sorrts of context menu questions (
>> ie does a right click bring the console menu up, or do some html specific
>> thing, and how is the context menu handled cross browser)
>>
>> The event code I keep trying to do something with , probably handles the
>> right click, but ot the context menu stuff
>>
>> Paul
>>
>>
>> On Mon, Nov 23, 2009 at 10:36 AM, Bret Pettichord <bret at pettichord.com>wrote:
>>
>>> Any comments on this?
>>>
>>> ---------- Forwarded message ----------
>>> From: GitHub <noreply at github.com>
>>> Date: Mon, Nov 23, 2009 at 11:07 AM
>>> Subject: [GitHub] bendyworks sent you a message
>>> To: bret at pettichord.com
>>>
>>>
>>>
>>>
>>> bendyworks wants you to pull from bendyworks/watir at master
>>>
>>> Body: We added right_click and middle_click to element.rb in firewatir.
>>>  Testing this proved quite problematic without pulling in a framework like
>>> jQuery.  We are seeing the code work just fine in a customer project
>>> however.
>>>
>>> Since I'm assuming adding a dependence on jQuery is a no-no, this change
>>> is without a test.  Any suggestions?
>>>
>>> Thanks!
>>> -Steve-
>>>
>>> View repository: http://github.com/bendyworks/watir/tree/master
>>>
>>>
>>>
>>> --
>>> 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
>>> Wtr-development at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/wtr-development
>>>
>>
>>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>



-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091123/cc598e31/attachment.html>

From paul.rogers at shaw.ca  Mon Nov 23 13:43:24 2009
From: paul.rogers at shaw.ca (Paul Rogers)
Date: Mon, 23 Nov 2009 11:43:24 -0700
Subject: [Wtr-development] Fwd: [GitHub] bendyworks sent you a message
In-Reply-To: <ade75c5b0911231034s678f5feds3dcc7db8485b20eb@mail.gmail.com>
References: <4b0ac138a2fd8_74383fe6b04ef2ec3ce@fe4.rs.github.com.tmail>
	<ade75c5b0911230936w3bac0046t86a78d7ce506dc6c@mail.gmail.com>
	<e7eaafaa0911231016s4cedf54fs83e7ab80702ece27@mail.gmail.com>
	<e7eaafaa0911231030s38f5c43fvc76f7afb50a8b6f8@mail.gmail.com>
	<ade75c5b0911231034s678f5feds3dcc7db8485b20eb@mail.gmail.com>
Message-ID: <e7eaafaa0911231043y291685a9o93c18009579db303@mail.gmail.com>

ive been trying to get them up on github for ages. Just no time. Maybe this
week, but it will be based on very old watir/firewatir code

Paul

On Mon, Nov 23, 2009 at 11:34 AM, Bret Pettichord <bret at pettichord.com>wrote:

> Can you point us to these?
>
>
> On Mon, Nov 23, 2009 at 12:30 PM, Paul Rogers <paul.rogers at shaw.ca> wrote:
>
>> oh, and the units tests for the drag and drop stuff already include both
>> prototype and jquery ( as they were the commonest ways of doing drag and
>> drop in a browser when I did it)
>>
>> Paul
>>
>>
>> On Mon, Nov 23, 2009 at 11:16 AM, Paul Rogers <paul.rogers at shaw.ca>wrote:
>>
>>> looks like its Firefox only
>>>
>>> http://github.com/bendyworks/watir/commit/bc024d859a270eeead9929a85c25f9e2328c96b5
>>>
>>>
>>> Id like to see,
>>>
>>> browser.link(:id, 'foo').click( :right_button )
>>> or
>>> browser.link(:id, 'foo').right_click
>>>
>>> so then the unit test just needs a method on the html that responds to a
>>> right click( I cant remember how to do that off hand otherwise I would have
>>> given an example)
>>> A right click method also brings up all sorrts of context menu questions
>>> ( ie does a right click bring the console menu up, or do some html specific
>>> thing, and how is the context menu handled cross browser)
>>>
>>> The event code I keep trying to do something with , probably handles the
>>> right click, but ot the context menu stuff
>>>
>>> Paul
>>>
>>>
>>> On Mon, Nov 23, 2009 at 10:36 AM, Bret Pettichord <bret at pettichord.com>wrote:
>>>
>>>> Any comments on this?
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: GitHub <noreply at github.com>
>>>> Date: Mon, Nov 23, 2009 at 11:07 AM
>>>> Subject: [GitHub] bendyworks sent you a message
>>>> To: bret at pettichord.com
>>>>
>>>>
>>>>
>>>>
>>>> bendyworks wants you to pull from bendyworks/watir at master
>>>>
>>>> Body: We added right_click and middle_click to element.rb in firewatir.
>>>>  Testing this proved quite problematic without pulling in a framework like
>>>> jQuery.  We are seeing the code work just fine in a customer project
>>>> however.
>>>>
>>>> Since I'm assuming adding a dependence on jQuery is a no-no, this change
>>>> is without a test.  Any suggestions?
>>>>
>>>> Thanks!
>>>> -Steve-
>>>>
>>>> View repository: http://github.com/bendyworks/watir/tree/master
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>> Wtr-development at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/wtr-development
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Wtr-development mailing list
>> Wtr-development at rubyforge.org
>> 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
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091123/d467b074/attachment-0001.html>

From zeljko.filipin at wa-research.ch  Mon Nov 23 15:53:26 2009
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Mon, 23 Nov 2009 21:53:26 +0100
Subject: [Wtr-development] Fwd: [RubyForge] Gem index has been shut down
In-Reply-To: <20091122033334.B33281D78868@rubyforge.org>
References: <20091122033334.B33281D78868@rubyforge.org>
Message-ID: <f81b1250911231253l5866588dhd567346bc769011@mail.gmail.com>

Are we going to publish gems only on gemcutter in the future?

?eljko
--
watir.com - community manager
watirpodcast.com - host



---------- Forwarded message ----------
From: <noreply at rubyforge.org>
Date: Sun, Nov 22, 2009 at 4:33 AM
Subject: [RubyForge] Gem index has been shut down
To: zeljko.filipin at gmail.com


Hello -

You're receiving this email because you're a RubyForge project admin and a
recent change probably affects you.   A few days ago we repointed
gems.rubyforge.org to the gemcutter.org box.  This means that Nick
Quaranto's excellent gemcutter app is now indexing and serving all the gems
- so rather than having two gem indexes, we now have one.  As a consequence
of this, when you release files to RubyForge you will probably also want to
do a "gem push" to get them onto gemcutter and into the main gem index.

Note that you can continue to release gems (and other files) at RubyForge;
it's just that gems won't automatically make it into the main gem index.

Yours,

The RubyForge support team
http://rubyforge.org/projects/support/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091123/1fa8ce0e/attachment.html>

From bret at pettichord.com  Mon Nov 23 17:01:19 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Mon, 23 Nov 2009 16:01:19 -0600
Subject: [Wtr-development] Fwd: [RubyForge] Gem index has been shut down
In-Reply-To: <f81b1250911231253l5866588dhd567346bc769011@mail.gmail.com>
References: <20091122033334.B33281D78868@rubyforge.org>
	<f81b1250911231253l5866588dhd567346bc769011@mail.gmail.com>
Message-ID: <ade75c5b0911231401g6ad22804y5e7cb4b4a5d47ea2@mail.gmail.com>

We will be publishing new gems to gemcutter.

Bret

On Mon, Nov 23, 2009 at 2:53 PM, ?eljko Filipin <
zeljko.filipin at wa-research.ch> wrote:

> Are we going to publish gems only on gemcutter in the future?
>
> ?eljko
> --
> watir.com - community manager
> watirpodcast.com - host
>
>
>
> ---------- Forwarded message ----------
> From: <noreply at rubyforge.org>
> Date: Sun, Nov 22, 2009 at 4:33 AM
> Subject: [RubyForge] Gem index has been shut down
> To: zeljko.filipin at gmail.com
>
>
> Hello -
>
> You're receiving this email because you're a RubyForge project admin and a
> recent change probably affects you.   A few days ago we repointed
> gems.rubyforge.org to the gemcutter.org box.  This means that Nick
> Quaranto's excellent gemcutter app is now indexing and serving all the gems
> - so rather than having two gem indexes, we now have one.  As a consequence
> of this, when you release files to RubyForge you will probably also want to
> do a "gem push" to get them onto gemcutter and into the main gem index.
>
> Note that you can continue to release gems (and other files) at RubyForge;
> it's just that gems won't automatically make it into the main gem index.
>
> Yours,
>
> The RubyForge support team
> http://rubyforge.org/projects/support/
>
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>



-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091123/cde8637f/attachment.html>

From zeljko.filipin at wa-research.ch  Tue Nov 24 07:03:13 2009
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Tue, 24 Nov 2009 13:03:13 +0100
Subject: [Wtr-development] Development Builds
Message-ID: <f81b1250911240403v5d778485wd87950b495ecc1fe@mail.gmail.com>

I have deleted 1.6.5.rc2 gems and all text from Development Builds page,
since 1.6.5 is released.

http://wiki.openqa.org/display/WTR/Development+Builds

?eljko
--
watir.com - community manager
watirpodcast.com - host
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091124/828dcaba/attachment.html>

From bret at pettichord.com  Tue Nov 24 16:57:22 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 24 Nov 2009 15:57:22 -0600
Subject: [Wtr-development] Jira vs. Lighthouse
Message-ID: <ade75c5b0911241357q1456565dx83ada08a7b464f40@mail.gmail.com>

I'm becoming less and less fond of Jira. Just seems somewhat heavyweight.
The biggest problem I have with it actually is that it is not designed to
have conversations take place within it. I recently used Lighthouse for
another project, and the nice thing about it was that any one interested in
the issue would get emailed whenever someone made a comment on the issue.
This encouraged a conversation between all the people who cared.

This makes me wonder whether we should use lighthouse for Watir. Thoughts?

Bret

-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091124/7dde63bc/attachment.html>

From charley.baker at gmail.com  Tue Nov 24 17:24:02 2009
From: charley.baker at gmail.com (Charley Baker)
Date: Tue, 24 Nov 2009 14:24:02 -0800
Subject: [Wtr-development] Jira vs. Lighthouse
In-Reply-To: <ade75c5b0911241357q1456565dx83ada08a7b464f40@mail.gmail.com>
References: <ade75c5b0911241357q1456565dx83ada08a7b464f40@mail.gmail.com>
Message-ID: <f96821860911241424k1db342e1sdfd3ad3f5bb5708a@mail.gmail.com>

+1 on lighthouse. I used to like jira, but our dependence on the version on
openqa with limitations and it's heavyweight nature tends not to suit a lot
of needs I've had. Lighthouse is much easier to use and should encourage
discussion on tickets.

-c

On Tue, Nov 24, 2009 at 1:57 PM, Bret Pettichord <bret at pettichord.com>wrote:

> I'm becoming less and less fond of Jira. Just seems somewhat heavyweight.
> The biggest problem I have with it actually is that it is not designed to
> have conversations take place within it. I recently used Lighthouse for
> another project, and the nice thing about it was that any one interested in
> the issue would get emailed whenever someone made a comment on the issue.
> This encouraged a conversation between all the people who cared.
>
> This makes me wonder whether we should use lighthouse for Watir. Thoughts?
>
> Bret
>
> --
> 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
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091124/65851d7b/attachment.html>

From tim.koops at gmail.com  Tue Nov 24 18:23:35 2009
From: tim.koops at gmail.com (Tim Koopmans)
Date: Wed, 25 Nov 2009 10:23:35 +1100
Subject: [Wtr-development] Jira vs. Lighthouse
In-Reply-To: <f96821860911241424k1db342e1sdfd3ad3f5bb5708a@mail.gmail.com>
References: <ade75c5b0911241357q1456565dx83ada08a7b464f40@mail.gmail.com>
	<f96821860911241424k1db342e1sdfd3ad3f5bb5708a@mail.gmail.com>
Message-ID: <93ee69e90911241523l696e7c36nc6bcb8818a197708@mail.gmail.com>

+1 for lighthouse but curious as to the pricing structure? Jira is
free for open source but not sure on lighthouse?

Regards,
Tim Koopmans



On Wed, Nov 25, 2009 at 9:24 AM, Charley Baker <charley.baker at gmail.com> wrote:
> +1 on lighthouse. I used to like jira, but our dependence on the version on
> openqa with limitations and it's heavyweight nature tends not to suit a lot
> of needs I've had. Lighthouse is much easier to use and should encourage
> discussion on tickets.
>
> -c
>
> On Tue, Nov 24, 2009 at 1:57 PM, Bret Pettichord <bret at pettichord.com>
> wrote:
>>
>> I'm becoming less and less fond of Jira. Just seems somewhat heavyweight.
>> The biggest problem I have with it actually is that it is not designed to
>> have conversations take place within it. I recently used Lighthouse for
>> another project, and the nice thing about it was that any one interested in
>> the issue would get emailed whenever someone made a comment on the issue.
>> This encouraged a conversation between all the people who cared.
>>
>> This makes me wonder whether we should use lighthouse for Watir. Thoughts?
>>
>> Bret
>>
>> --
>> Bret Pettichord
>> Lead Developer, Watir, www.watir.com
>>
>> Blog, www.io.com/~wazmo/blog
>> Twitter, www.twitter.com/bpettichord
>>
>>
>> _______________________________________________
>> Wtr-development mailing list
>> Wtr-development at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wtr-development
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>

From bret at pettichord.com  Tue Nov 24 19:40:16 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 24 Nov 2009 18:40:16 -0600
Subject: [Wtr-development] Jira vs. Lighthouse
In-Reply-To: <93ee69e90911241523l696e7c36nc6bcb8818a197708@mail.gmail.com>
References: <ade75c5b0911241357q1456565dx83ada08a7b464f40@mail.gmail.com>
	<f96821860911241424k1db342e1sdfd3ad3f5bb5708a@mail.gmail.com>
	<93ee69e90911241523l696e7c36nc6bcb8818a197708@mail.gmail.com>
Message-ID: <ade75c5b0911241640g78a55bfo61e50f8f358fe7b9@mail.gmail.com>

*Create as many Open Source Projects as you wish on any plan!* Even the free
plan!
http://lighthouseapp.com/plans

On Tue, Nov 24, 2009 at 5:23 PM, Tim Koopmans <tim.koops at gmail.com> wrote:

> +1 for lighthouse but curious as to the pricing structure? Jira is
> free for open source but not sure on lighthouse?
>
> Regards,
> Tim Koopmans
>
>
>
> On Wed, Nov 25, 2009 at 9:24 AM, Charley Baker <charley.baker at gmail.com>
> wrote:
> > +1 on lighthouse. I used to like jira, but our dependence on the version
> on
> > openqa with limitations and it's heavyweight nature tends not to suit a
> lot
> > of needs I've had. Lighthouse is much easier to use and should encourage
> > discussion on tickets.
> >
> > -c
> >
> > On Tue, Nov 24, 2009 at 1:57 PM, Bret Pettichord <bret at pettichord.com>
> > wrote:
> >>
> >> I'm becoming less and less fond of Jira. Just seems somewhat
> heavyweight.
> >> The biggest problem I have with it actually is that it is not designed
> to
> >> have conversations take place within it. I recently used Lighthouse for
> >> another project, and the nice thing about it was that any one interested
> in
> >> the issue would get emailed whenever someone made a comment on the
> issue.
> >> This encouraged a conversation between all the people who cared.
> >>
> >> This makes me wonder whether we should use lighthouse for Watir.
> Thoughts?
> >>
> >> Bret
> >>
> >> --
> >> 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
> >> Wtr-development at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/wtr-development
> >
> >
> > _______________________________________________
> > Wtr-development mailing list
> > Wtr-development at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/wtr-development
> >
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>



-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091124/e9b6424b/attachment.html>

From alister.scott at gmail.com  Tue Nov 24 23:44:01 2009
From: alister.scott at gmail.com (Alister Scott)
Date: Wed, 25 Nov 2009 14:44:01 +1000
Subject: [Wtr-development] Lighthouse and JIRA
Message-ID: <16bf298e0911242044g56b2acabvbf78c506b2320b3b@mail.gmail.com>

Hi All,


>> I'm becoming less and less fond of Jira. Just seems somewhat heavyweight.
>>The biggest problem I have with it actually is that it is not designed to
>> have conversations take place within it. I recently used Lighthouse for
>> another project, and the nice thing about it was that any one interested
in
>> the issue would get emailed whenever someone made a comment on the issue.
>> This encouraged a conversation between all the people who cared.

>> This makes me wonder whether we should use lighthouse for Watir.
Thoughts?

JIRA has this functionality, you simply 'watch' any issue to be notified of
all changes and comments.

Cheers,


Alister Scott
Brisbane, Australia
Watir Web Master: http://watir.com
Blog: http://watirmelon.com
Google: http://www.google.com/profiles/alister.scott
LinkedIn: http://www.linkedin.com/in/alisterscott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091125/597163f7/attachment.html>

From bret at pettichord.com  Wed Nov 25 00:57:15 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 24 Nov 2009 23:57:15 -0600
Subject: [Wtr-development] Lighthouse and JIRA
In-Reply-To: <16bf298e0911242044g56b2acabvbf78c506b2320b3b@mail.gmail.com>
References: <16bf298e0911242044g56b2acabvbf78c506b2320b3b@mail.gmail.com>
Message-ID: <ade75c5b0911242157i204755bbl3d5e05406583ce9d@mail.gmail.com>

On Tue, Nov 24, 2009 at 10:44 PM, Alister Scott <alister.scott at gmail.com>wrote:

> JIRA has this functionality, you simply 'watch' any issue to be notified of
> all changes and comments.
>

True.

I'm trying to understand why this feature is used by most users with
Lighthouse but few with Jira. I think Lighthouse assumes that you will want
to watch any ticket that you report or comment on, whereas Jira requires you
to click the watch link, which franky I had not noticed until now.

-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091124/88a28b3c/attachment.html>

From bret at pettichord.com  Wed Nov 25 00:57:56 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 24 Nov 2009 23:57:56 -0600
Subject: [Wtr-development] Lighthouse and JIRA
In-Reply-To: <ade75c5b0911242157i204755bbl3d5e05406583ce9d@mail.gmail.com>
References: <16bf298e0911242044g56b2acabvbf78c506b2320b3b@mail.gmail.com>
	<ade75c5b0911242157i204755bbl3d5e05406583ce9d@mail.gmail.com>
Message-ID: <ade75c5b0911242157v75aa72fbv5963b2d2f94078b@mail.gmail.com>

I wonder if there is a way to say that I'd like to watch all Jira tickets
for the watir project?

Bret

On Tue, Nov 24, 2009 at 11:57 PM, Bret Pettichord <bret at pettichord.com>wrote:

> On Tue, Nov 24, 2009 at 10:44 PM, Alister Scott <alister.scott at gmail.com>wrote:
>
>> JIRA has this functionality, you simply 'watch' any issue to be notified
>> of all changes and comments.
>>
>
> True.
>
> I'm trying to understand why this feature is used by most users with
> Lighthouse but few with Jira. I think Lighthouse assumes that you will want
> to watch any ticket that you report or comment on, whereas Jira requires you
> to click the watch link, which franky I had not noticed until now.
>
> --
> 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
>
>


-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091124/8e3d5b70/attachment.html>

From zeljko.filipin at wa-research.ch  Wed Nov 25 03:47:53 2009
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Wed, 25 Nov 2009 09:47:53 +0100
Subject: [Wtr-development] Jira vs. Lighthouse
In-Reply-To: <ade75c5b0911241357q1456565dx83ada08a7b464f40@mail.gmail.com>
References: <ade75c5b0911241357q1456565dx83ada08a7b464f40@mail.gmail.com>
Message-ID: <f81b1250911250047r67b64065p73f6d2860ada459b@mail.gmail.com>

On Tue, Nov 24, 2009 at 10:57 PM, Bret Pettichord <bret at pettichord.com>
wrote:
> This makes me wonder whether we should use lighthouse for Watir.

I rarely use Jira, so I really do not care. :)

If we move to Lighthouse, are we going to move tickets from Jira there?

?eljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091125/2bd1c5a0/attachment.html>

From bret at pettichord.com  Wed Nov 25 09:53:37 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 25 Nov 2009 08:53:37 -0600
Subject: [Wtr-development] Jira vs. Lighthouse
In-Reply-To: <f81b1250911250047r67b64065p73f6d2860ada459b@mail.gmail.com>
References: <ade75c5b0911241357q1456565dx83ada08a7b464f40@mail.gmail.com>
	<f81b1250911250047r67b64065p73f6d2860ada459b@mail.gmail.com>
Message-ID: <ade75c5b0911250653u729ad419he8111783adaa3353@mail.gmail.com>

On Wed, Nov 25, 2009 at 2:47 AM, ?eljko Filipin <
zeljko.filipin at wa-research.ch> wrote:

> On Tue, Nov 24, 2009 at 10:57 PM, Bret Pettichord <bret at pettichord.com>
> wrote:
> > This makes me wonder whether we should use lighthouse for Watir.
>
> I rarely use Jira, so I really do not care. :)
>

I guess that is the source of my concern. One thing I've observed is that
projects that use Lighthouse have a lot more conversations appear in the bug
tracker. I find that that some issues get discussed again and again here,
and am thinking that the problem is that these discussions are happening in
the wrong place.

Maybe another way for me to frame my question is this: how can we get more
discussions to happen in Jira instead of on the mailing lists?


> If we move to Lighthouse, are we going to move tickets from Jira there?
>

Not sure. We would have to figure this out.

Bret



-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091125/3d05f374/attachment-0001.html>

From jeff.fry at gmail.com  Wed Nov 25 10:54:38 2009
From: jeff.fry at gmail.com (Jeff Fry)
Date: Wed, 25 Nov 2009 07:54:38 -0800
Subject: [Wtr-development] Lighthouse and JIRA
In-Reply-To: <ade75c5b0911242157v75aa72fbv5963b2d2f94078b@mail.gmail.com>
References: <16bf298e0911242044g56b2acabvbf78c506b2320b3b@mail.gmail.com>
	<ade75c5b0911242157i204755bbl3d5e05406583ce9d@mail.gmail.com>
	<ade75c5b0911242157v75aa72fbv5963b2d2f94078b@mail.gmail.com>
Message-ID: <970956b0911250754j1bf35878x44000abf36c2b34e@mail.gmail.com>

On Tue, Nov 24, 2009 at 9:57 PM, Bret Pettichord <bret at pettichord.com>wrote:

> I wonder if there is a way to say that I'd like to watch all Jira tickets
> for the watir project?
>

Yes. In Jira, one can set notification rules for members of groups (e.g.
'watir-dev') and then add yourself to that group. Are you a project admin
for openqa install? If so, I believe you can do this...though there's a
slight chance it requires being a system admin, I can't quite recall. I'd be
happy to help someone set this up. I'd just need to work with someone who is
a Jira admin (at least for the watir project) and who knows what the ideal
behavior would be.


>
> Bret
>
>
> On Tue, Nov 24, 2009 at 11:57 PM, Bret Pettichord <bret at pettichord.com>wrote:
>
>> On Tue, Nov 24, 2009 at 10:44 PM, Alister Scott <alister.scott at gmail.com>wrote:
>>
>>> JIRA has this functionality, you simply 'watch' any issue to be notified
>>> of all changes and comments.
>>>
>>
>> True.
>>
>> I'm trying to understand why this feature is used by most users with
>> Lighthouse but few with Jira. I think Lighthouse assumes that you will want
>> to watch any ticket that you report or comment on, whereas Jira requires you
>> to click the watch link, which franky I had not noticed until now.
>>
>> --
>> 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
>>
>>
>
>
> --
> Bret Pettichord
> Lead Developer, Watir, www.watir.com
>
> Blog, www.io.com/~wazmo/blog
> Twitter, www.twitter.com/bpettichord
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>



-- 
Jeff Fry

http://testingjeff.wordpress.com
http://associationforsoftwaretesting.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091125/0c375de1/attachment.html>

From bret at pettichord.com  Wed Nov 25 12:35:43 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 25 Nov 2009 11:35:43 -0600
Subject: [Wtr-development] Lighthouse and JIRA
In-Reply-To: <970956b0911250754j1bf35878x44000abf36c2b34e@mail.gmail.com>
References: <16bf298e0911242044g56b2acabvbf78c506b2320b3b@mail.gmail.com>
	<ade75c5b0911242157i204755bbl3d5e05406583ce9d@mail.gmail.com>
	<ade75c5b0911242157v75aa72fbv5963b2d2f94078b@mail.gmail.com>
	<970956b0911250754j1bf35878x44000abf36c2b34e@mail.gmail.com>
Message-ID: <ade75c5b0911250935x4dc46592md10814eb9a60a58b@mail.gmail.com>

Jeff,

Jira seems to be down right now. I think all the "watir committers" have
admin rights to Jira, which would include both you and me. Last week I was
helping a collegue with a selenium ticket on openqa, and noticed that I saw
a lot fewer options than what I usually saw. (E.g. he could not edit a
ticket he opened, nor could I.) The "watir committers" are the people who
had commit rights to the Watir SVN repository, which is why i think you are
on this list. It's possible that Patrick gave me special admin rights, but
if that is true we should get the same rights to you and Alister so you can
help with the Jira set up.

Let me give you all some background.

I haven't been watching the Jira tickets for several months and I've decided
I need to get back in there and take a look at what we have. This always
feels like a daunting task, and I guess It has me complaining because Jira
may not be the perfectly ideal tool.

It has me thinking. Who else watches the tickets? New tickets? Comments to
old tickets? Is there a way for me to see who is watching a ticket? I used
to watch them via RSS, which of course wouldn't show up in Jira.

Bret

On Wed, Nov 25, 2009 at 9:54 AM, Jeff Fry <jeff.fry at gmail.com> wrote:

>
>
> On Tue, Nov 24, 2009 at 9:57 PM, Bret Pettichord <bret at pettichord.com>wrote:
>
>> I wonder if there is a way to say that I'd like to watch all Jira tickets
>> for the watir project?
>>
>
> Yes. In Jira, one can set notification rules for members of groups (e.g.
> 'watir-dev') and then add yourself to that group. Are you a project admin
> for openqa install? If so, I believe you can do this...though there's a
> slight chance it requires being a system admin, I can't quite recall. I'd be
> happy to help someone set this up. I'd just need to work with someone who is
> a Jira admin (at least for the watir project) and who knows what the ideal
> behavior would be.
>
>
>>
>> Bret
>>
>>
>> On Tue, Nov 24, 2009 at 11:57 PM, Bret Pettichord <bret at pettichord.com>wrote:
>>
>>> On Tue, Nov 24, 2009 at 10:44 PM, Alister Scott <alister.scott at gmail.com
>>> > wrote:
>>>
>>>> JIRA has this functionality, you simply 'watch' any issue to be notified
>>>> of all changes and comments.
>>>>
>>>
>>> True.
>>>
>>> I'm trying to understand why this feature is used by most users with
>>> Lighthouse but few with Jira. I think Lighthouse assumes that you will want
>>> to watch any ticket that you report or comment on, whereas Jira requires you
>>> to click the watch link, which franky I had not noticed until now.
>>>
>>> --
>>> 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
>>>
>>>
>>
>>
>> --
>> 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
>> Wtr-development at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wtr-development
>>
>
>
>
> --
> Jeff Fry
>
> http://testingjeff.wordpress.com
> http://associationforsoftwaretesting.org
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>



-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091125/259ea2cf/attachment.html>

From bret at pettichord.com  Wed Nov 25 17:09:29 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 25 Nov 2009 16:09:29 -0600
Subject: [Wtr-development] Fwd: [GitHub] bendyworks sent you a message
In-Reply-To: <e7eaafaa0911231043y291685a9o93c18009579db303@mail.gmail.com>
References: <4b0ac138a2fd8_74383fe6b04ef2ec3ce@fe4.rs.github.com.tmail>
	<ade75c5b0911230936w3bac0046t86a78d7ce506dc6c@mail.gmail.com>
	<e7eaafaa0911231016s4cedf54fs83e7ab80702ece27@mail.gmail.com>
	<e7eaafaa0911231030s38f5c43fvc76f7afb50a8b6f8@mail.gmail.com>
	<ade75c5b0911231034s678f5feds3dcc7db8485b20eb@mail.gmail.com>
	<e7eaafaa0911231043y291685a9o93c18009579db303@mail.gmail.com>
Message-ID: <ade75c5b0911251409g57c7a016qfbae375b8ad1d87@mail.gmail.com>

sounds good. if you are having trouble with github, you could upload a zip
file with your code to the wiki.

bret

On Mon, Nov 23, 2009 at 12:43 PM, Paul Rogers <paul.rogers at shaw.ca> wrote:

> ive been trying to get them up on github for ages. Just no time. Maybe this
> week, but it will be based on very old watir/firewatir code
>
> Paul
>
>
> On Mon, Nov 23, 2009 at 11:34 AM, Bret Pettichord <bret at pettichord.com>wrote:
>
>> Can you point us to these?
>>
>>
>> On Mon, Nov 23, 2009 at 12:30 PM, Paul Rogers <paul.rogers at shaw.ca>wrote:
>>
>>> oh, and the units tests for the drag and drop stuff already include both
>>> prototype and jquery ( as they were the commonest ways of doing drag and
>>> drop in a browser when I did it)
>>>
>>> Paul
>>>
>>>
>>> On Mon, Nov 23, 2009 at 11:16 AM, Paul Rogers <paul.rogers at shaw.ca>wrote:
>>>
>>>> looks like its Firefox only
>>>>
>>>> http://github.com/bendyworks/watir/commit/bc024d859a270eeead9929a85c25f9e2328c96b5
>>>>
>>>>
>>>> Id like to see,
>>>>
>>>> browser.link(:id, 'foo').click( :right_button )
>>>> or
>>>> browser.link(:id, 'foo').right_click
>>>>
>>>> so then the unit test just needs a method on the html that responds to a
>>>> right click( I cant remember how to do that off hand otherwise I would have
>>>> given an example)
>>>> A right click method also brings up all sorrts of context menu questions
>>>> ( ie does a right click bring the console menu up, or do some html specific
>>>> thing, and how is the context menu handled cross browser)
>>>>
>>>> The event code I keep trying to do something with , probably handles the
>>>> right click, but ot the context menu stuff
>>>>
>>>> Paul
>>>>
>>>>
>>>> On Mon, Nov 23, 2009 at 10:36 AM, Bret Pettichord <bret at pettichord.com>wrote:
>>>>
>>>>> Any comments on this?
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: GitHub <noreply at github.com>
>>>>> Date: Mon, Nov 23, 2009 at 11:07 AM
>>>>> Subject: [GitHub] bendyworks sent you a message
>>>>> To: bret at pettichord.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> bendyworks wants you to pull from bendyworks/watir at master
>>>>>
>>>>> Body: We added right_click and middle_click to element.rb in firewatir.
>>>>>  Testing this proved quite problematic without pulling in a framework like
>>>>> jQuery.  We are seeing the code work just fine in a customer project
>>>>> however.
>>>>>
>>>>> Since I'm assuming adding a dependence on jQuery is a no-no, this
>>>>> change is without a test.  Any suggestions?
>>>>>
>>>>> Thanks!
>>>>> -Steve-
>>>>>
>>>>> View repository: http://github.com/bendyworks/watir/tree/master
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>> Wtr-development at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/wtr-development
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Wtr-development mailing list
>>> Wtr-development at rubyforge.org
>>> 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
>> Wtr-development at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wtr-development
>>
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>



-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091125/fd797c62/attachment-0001.html>

From paul.rogers at shaw.ca  Wed Nov 25 17:58:47 2009
From: paul.rogers at shaw.ca (Paul Rogers)
Date: Wed, 25 Nov 2009 15:58:47 -0700
Subject: [Wtr-development] Fwd: [GitHub] bendyworks sent you a message
In-Reply-To: <ade75c5b0911251409g57c7a016qfbae375b8ad1d87@mail.gmail.com>
References: <4b0ac138a2fd8_74383fe6b04ef2ec3ce@fe4.rs.github.com.tmail>
	<ade75c5b0911230936w3bac0046t86a78d7ce506dc6c@mail.gmail.com>
	<e7eaafaa0911231016s4cedf54fs83e7ab80702ece27@mail.gmail.com>
	<e7eaafaa0911231030s38f5c43fvc76f7afb50a8b6f8@mail.gmail.com>
	<ade75c5b0911231034s678f5feds3dcc7db8485b20eb@mail.gmail.com>
	<e7eaafaa0911231043y291685a9o93c18009579db303@mail.gmail.com>
	<ade75c5b0911251409g57c7a016qfbae375b8ad1d87@mail.gmail.com>
Message-ID: <e7eaafaa0911251458j1f76898blb7040437a217899f@mail.gmail.com>

github isnt the problem, its me ;-)


I'll give it a go tonight

Paul

On Wed, Nov 25, 2009 at 3:09 PM, Bret Pettichord <bret at pettichord.com>wrote:

> sounds good. if you are having trouble with github, you could upload a zip
> file with your code to the wiki.
>
> bret
>
>
> On Mon, Nov 23, 2009 at 12:43 PM, Paul Rogers <paul.rogers at shaw.ca> wrote:
>
>> ive been trying to get them up on github for ages. Just no time. Maybe
>> this week, but it will be based on very old watir/firewatir code
>>
>> Paul
>>
>>
>> On Mon, Nov 23, 2009 at 11:34 AM, Bret Pettichord <bret at pettichord.com>wrote:
>>
>>> Can you point us to these?
>>>
>>>
>>> On Mon, Nov 23, 2009 at 12:30 PM, Paul Rogers <paul.rogers at shaw.ca>wrote:
>>>
>>>> oh, and the units tests for the drag and drop stuff already include both
>>>> prototype and jquery ( as they were the commonest ways of doing drag and
>>>> drop in a browser when I did it)
>>>>
>>>> Paul
>>>>
>>>>
>>>> On Mon, Nov 23, 2009 at 11:16 AM, Paul Rogers <paul.rogers at shaw.ca>wrote:
>>>>
>>>>> looks like its Firefox only
>>>>>
>>>>> http://github.com/bendyworks/watir/commit/bc024d859a270eeead9929a85c25f9e2328c96b5
>>>>>
>>>>>
>>>>> Id like to see,
>>>>>
>>>>> browser.link(:id, 'foo').click( :right_button )
>>>>> or
>>>>> browser.link(:id, 'foo').right_click
>>>>>
>>>>> so then the unit test just needs a method on the html that responds to
>>>>> a right click( I cant remember how to do that off hand otherwise I would
>>>>> have given an example)
>>>>> A right click method also brings up all sorrts of context menu
>>>>> questions ( ie does a right click bring the console menu up, or do some html
>>>>> specific thing, and how is the context menu handled cross browser)
>>>>>
>>>>> The event code I keep trying to do something with , probably handles
>>>>> the right click, but ot the context menu stuff
>>>>>
>>>>> Paul
>>>>>
>>>>>
>>>>> On Mon, Nov 23, 2009 at 10:36 AM, Bret Pettichord <bret at pettichord.com
>>>>> > wrote:
>>>>>
>>>>>> Any comments on this?
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: GitHub <noreply at github.com>
>>>>>> Date: Mon, Nov 23, 2009 at 11:07 AM
>>>>>> Subject: [GitHub] bendyworks sent you a message
>>>>>> To: bret at pettichord.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> bendyworks wants you to pull from bendyworks/watir at master
>>>>>>
>>>>>> Body: We added right_click and middle_click to element.rb in
>>>>>> firewatir.  Testing this proved quite problematic without pulling in a
>>>>>> framework like jQuery.  We are seeing the code work just fine in a customer
>>>>>> project however.
>>>>>>
>>>>>> Since I'm assuming adding a dependence on jQuery is a no-no, this
>>>>>> change is without a test.  Any suggestions?
>>>>>>
>>>>>> Thanks!
>>>>>> -Steve-
>>>>>>
>>>>>> View repository: http://github.com/bendyworks/watir/tree/master
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>> Wtr-development at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/wtr-development
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Wtr-development mailing list
>>>> Wtr-development at rubyforge.org
>>>> 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
>>> Wtr-development at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/wtr-development
>>>
>>
>>
>> _______________________________________________
>> Wtr-development mailing list
>> Wtr-development at rubyforge.org
>> 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
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091125/59b942cb/attachment.html>

From bret at pettichord.com  Wed Nov 25 19:48:33 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 25 Nov 2009 18:48:33 -0600
Subject: [Wtr-development] Watir Jira Projects
Message-ID: <ade75c5b0911251648l6fa7b5d8lf8994802337f7b10@mail.gmail.com>

Hey, I've been working in Jira today, and I'm worried that we'll need to
change things around a bit.

I see that we now have the ChromeWatir and SafariWatir bug reports in the
Watir project. I think these need to be set up as separate projects on
OpenQA.

This is how the Selenium projects are set up.
http://jira.openqa.org/secure/BrowseProjects.jspa

The reason is that in Jira, a project is considered to be a series of
releases based on a common code base. We added the FireWatir tickets to the
project when we merged the Watir and FireWatir codebases.

But SafariWatir and ChromeWatir are still managed as separate code bases
with separate release schedules. I know of no plans to change this.

I noticed this when I was updating the Watir Jira Project to include our
latest releases.
http://jira.openqa.org/secure/project/ManageVersions.jspa?pid=10080

Each release has a release number and date, but clearly these will be
different for these other Watir projects, so they need to be hosted in
separate OpenQA projects.

Does this make sense?

Bret

-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091125/72a37c24/attachment.html>

From charley.baker at gmail.com  Wed Nov 25 20:11:09 2009
From: charley.baker at gmail.com (Charley Baker)
Date: Wed, 25 Nov 2009 18:11:09 -0700
Subject: [Wtr-development] Watir Jira Projects
In-Reply-To: <ade75c5b0911251648l6fa7b5d8lf8994802337f7b10@mail.gmail.com>
References: <ade75c5b0911251648l6fa7b5d8lf8994802337f7b10@mail.gmail.com>
Message-ID: <f96821860911251711m7379bbc2m286796b4b1d15757@mail.gmail.com>

That sounds great, I've gotten involved just barely with SafariWatir, but
it's well behind what I'd consider moving into the core. As we go forward
with various implementations, we should be tracking against watir spec to
certify and pull in until we get to Watir 2.0, where we're also still using
it but in a different sense.

-c


On Wed, Nov 25, 2009 at 5:48 PM, Bret Pettichord <bret at pettichord.com>wrote:

> Hey, I've been working in Jira today, and I'm worried that we'll need to
> change things around a bit.
>
> I see that we now have the ChromeWatir and SafariWatir bug reports in the
> Watir project. I think these need to be set up as separate projects on
> OpenQA.
>
> This is how the Selenium projects are set up.
> http://jira.openqa.org/secure/BrowseProjects.jspa
>
> The reason is that in Jira, a project is considered to be a series of
> releases based on a common code base. We added the FireWatir tickets to the
> project when we merged the Watir and FireWatir codebases.
>
> But SafariWatir and ChromeWatir are still managed as separate code bases
> with separate release schedules. I know of no plans to change this.
>
> I noticed this when I was updating the Watir Jira Project to include our
> latest releases.
> http://jira.openqa.org/secure/project/ManageVersions.jspa?pid=10080
>
> Each release has a release number and date, but clearly these will be
> different for these other Watir projects, so they need to be hosted in
> separate OpenQA projects.
>
> Does this make sense?
>
> Bret
>
> --
> 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
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091125/e0746b41/attachment.html>

From zeljko.filipin at wa-research.ch  Thu Nov 26 04:08:35 2009
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Thu, 26 Nov 2009 10:08:35 +0100
Subject: [Wtr-development] Watir Jira Projects
In-Reply-To: <ade75c5b0911251648l6fa7b5d8lf8994802337f7b10@mail.gmail.com>
References: <ade75c5b0911251648l6fa7b5d8lf8994802337f7b10@mail.gmail.com>
Message-ID: <f81b1250911260108n63a308d1ybf6b282c93b3d907@mail.gmail.com>

On Thu, Nov 26, 2009 at 1:48 AM, Bret Pettichord <bret at pettichord.com>
wrote:
> I see that we now have the ChromeWatir and SafariWatir bug reports in the
Watir project. I think these need to be set up as separate projects on
OpenQA.

I moved them in while trying to merge Watir sites into one. I saw we had
FireWatir there so I thought I would just add ChromeWatir and SafariWatir
too.

The more I think about it, the more I see Watir is not a typical Openqa
project. For example, Jira admins are the people for commit access to svn
repository. That makes no sense for us, since our code is no Github.

Should I ask Patrick to create ChromeWatir and SafariWatir Jira projects?

?eljko
--
watir.com - community manager
watirpodcast.com - host
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091126/d544d37c/attachment-0001.html>

From bret at pettichord.com  Thu Nov 26 12:01:09 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Thu, 26 Nov 2009 11:01:09 -0600
Subject: [Wtr-development] Watir Jira Projects
In-Reply-To: <f81b1250911260108n63a308d1ybf6b282c93b3d907@mail.gmail.com>
References: <ade75c5b0911251648l6fa7b5d8lf8994802337f7b10@mail.gmail.com>
	<f81b1250911260108n63a308d1ybf6b282c93b3d907@mail.gmail.com>
Message-ID: <ade75c5b0911260901l466b87f8r41913d4cd26def57@mail.gmail.com>

On Thu, Nov 26, 2009 at 3:08 AM, ?eljko Filipin <
zeljko.filipin at wa-research.ch> wrote:

> The more I think about it, the more I see Watir is not a typical Openqa
> project. For example, Jira admins are the people for commit access to svn
> repository. That makes no sense for us, since our code is no Github.
>

Open QA is an odd thing. The only "typical" OpenQA project is Selenium.
Everything else is kinda an afterthought.

But I don't think we have any Jira admins. I was talking to Jeff about this
yesterday and he was going to talk to Patrick. I think the Selenium people
have more access to administer and customize Jira than we do, simply by
virtue of the fact that Patrick is part of the Selenium team. But I think
that's something we can work on. For example, someone, presumably Patrick,
recently made "environment" a required field. I assume this was done because
of a decision made by the Selenium team. (This policy makes sense for
tickets, but is annoying because I can't retarget a ticket for a different
release without changing this field.)

Should I ask Patrick to create ChromeWatir and SafariWatir Jira projects?
>

I think that's the right direction, but I think the people who are running
these projects should have a say. Sai? Tom?

One thing that we will be able to do, with all the projects on OpenQA, is
easily forward tickets between projects.

Bret


-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091126/d6b91fe7/attachment.html>

From jeff.fry at gmail.com  Thu Nov 26 13:23:38 2009
From: jeff.fry at gmail.com (Jeff Fry)
Date: Thu, 26 Nov 2009 10:23:38 -0800
Subject: [Wtr-development] Watir Jira Projects
In-Reply-To: <ade75c5b0911260901l466b87f8r41913d4cd26def57@mail.gmail.com>
References: <ade75c5b0911251648l6fa7b5d8lf8994802337f7b10@mail.gmail.com>
	<f81b1250911260108n63a308d1ybf6b282c93b3d907@mail.gmail.com>
	<ade75c5b0911260901l466b87f8r41913d4cd26def57@mail.gmail.com>
Message-ID: <970956b0911261023j2877ee6dm5ed9f808eec948b@mail.gmail.com>

On Thu, Nov 26, 2009 at 9:01 AM, Bret Pettichord <bret at pettichord.com>wrote:

>
>
> But I don't think we have any Jira admins. I was talking to Jeff about this
> yesterday and he was going to talk to Patrick. I think the Selenium people
> have more access to administer and customize Jira than we do, simply by
> virtue of the fact that Patrick is part of the Selenium team. But I think
> that's something we can work on.
>

Yeah, I emailed Patrick yesterday. I'll let y'all know when I hear back, but
hopefully he'll either give me rights to makes some changes for us, or make
some changes on our behalf. If we *can't* make that happen over a reasonable
period of time, it'll be good incentive to consider leaving Jira...but
hopefully we can save ourselves the work.


> Should I ask Patrick to create ChromeWatir and SafariWatir Jira projects?
>>
>
> I think that's the right direction, but I think the people who are running
> these projects should have a say. Sai? Tom?
>

+1 on making them separate projects, assuming their leads agree. The Jira
model is really one project per releasable unit. Anything that will be
released as part of watir 1.x should be in the watir project, anything that
may be released independently should get its own project with its own
release versions and dates.

-- 
Jeff Fry

http://testingjeff.wordpress.com
http://associationforsoftwaretesting.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091126/3366cb23/attachment.html>

From notethan at gmail.com  Fri Nov 27 15:45:36 2009
From: notethan at gmail.com (Ethan)
Date: Fri, 27 Nov 2009 14:45:36 -0600
Subject: [Wtr-development] js pop-ups internal within watir?
In-Reply-To: <8ac3ceb30911190003s74c6613aw6ac2926368915f52@mail.gmail.com>
References: <7ac2300c0911180856n7e373fabm1e277c4effcab97f@mail.gmail.com> 
	<ade75c5b0911180917p419d0d22ya0b440533326f2c0@mail.gmail.com> 
	<f58506c40911181034h48392488y2983498a0c836bad@mail.gmail.com> 
	<2a379a300911182100n680bcc18w7a38c70ecc09024b@mail.gmail.com> 
	<f58506c40911182122j7541d7c8h3fd2105102a3a688@mail.gmail.com> 
	<8ac3ceb30911190003s74c6613aw6ac2926368915f52@mail.gmail.com>
Message-ID: <f58506c40911271245p25f332e5ubeb05f49e871fa20@mail.gmail.com>

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 ! <ynot408 at gmail.com> 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
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091127/2d736781/attachment-0001.html>

From charley.baker at gmail.com  Fri Nov 27 17:50:31 2009
From: charley.baker at gmail.com (Charley Baker)
Date: Fri, 27 Nov 2009 15:50:31 -0700
Subject: [Wtr-development] js pop-ups internal within watir?
In-Reply-To: <f58506c40911271245p25f332e5ubeb05f49e871fa20@mail.gmail.com>
References: <7ac2300c0911180856n7e373fabm1e277c4effcab97f@mail.gmail.com>
	<ade75c5b0911180917p419d0d22ya0b440533326f2c0@mail.gmail.com>
	<f58506c40911181034h48392488y2983498a0c836bad@mail.gmail.com>
	<2a379a300911182100n680bcc18w7a38c70ecc09024b@mail.gmail.com>
	<f58506c40911182122j7541d7c8h3fd2105102a3a688@mail.gmail.com>
	<8ac3ceb30911190003s74c6613aw6ac2926368915f52@mail.gmail.com>
	<f58506c40911271245p25f332e5ubeb05f49e871fa20@mail.gmail.com>
Message-ID: <f96821860911271450o79c235d1h7be858365d624a1a@mail.gmail.com>

Comments inline:

On Fri, Nov 27, 2009 at 1:45 PM, Ethan <notethan at gmail.com> 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 ! <ynot408 at gmail.com> 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
>> Wtr-development at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wtr-development
>>
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091127/8a4e18d1/attachment.html>

From notethan at gmail.com  Fri Nov 27 20:10:51 2009
From: notethan at gmail.com (Ethan)
Date: Fri, 27 Nov 2009 20:10:51 -0500
Subject: [Wtr-development] js pop-ups internal within watir?
In-Reply-To: <f96821860911271450o79c235d1h7be858365d624a1a@mail.gmail.com>
References: <7ac2300c0911180856n7e373fabm1e277c4effcab97f@mail.gmail.com> 
	<ade75c5b0911180917p419d0d22ya0b440533326f2c0@mail.gmail.com> 
	<f58506c40911181034h48392488y2983498a0c836bad@mail.gmail.com> 
	<2a379a300911182100n680bcc18w7a38c70ecc09024b@mail.gmail.com> 
	<f58506c40911182122j7541d7c8h3fd2105102a3a688@mail.gmail.com> 
	<8ac3ceb30911190003s74c6613aw6ac2926368915f52@mail.gmail.com> 
	<f58506c40911271245p25f332e5ubeb05f49e871fa20@mail.gmail.com> 
	<f96821860911271450o79c235d1h7be858365d624a1a@mail.gmail.com>
Message-ID: <f58506c40911271710h466cffe1gcb6d1e752ffa12df@mail.gmail.com>

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 <charley.baker at gmail.com>wrote:

> Comments inline:
>
> On Fri, Nov 27, 2009 at 1:45 PM, Ethan <notethan at gmail.com> 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 ! <ynot408 at gmail.com> 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
>>> Wtr-development at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/wtr-development
>>>
>>
>>
>> _______________________________________________
>> Wtr-development mailing list
>> Wtr-development at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wtr-development
>>
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091127/41a8d8d2/attachment-0001.html>

From ynot408 at gmail.com  Sat Nov 28 01:00:17 2009
From: ynot408 at gmail.com (! Tony !)
Date: Sat, 28 Nov 2009 11:30:17 +0530
Subject: [Wtr-development] js pop-ups internal within watir?
In-Reply-To: <f58506c40911271710h466cffe1gcb6d1e752ffa12df@mail.gmail.com>
References: <7ac2300c0911180856n7e373fabm1e277c4effcab97f@mail.gmail.com> 
	<ade75c5b0911180917p419d0d22ya0b440533326f2c0@mail.gmail.com> 
	<f58506c40911181034h48392488y2983498a0c836bad@mail.gmail.com> 
	<2a379a300911182100n680bcc18w7a38c70ecc09024b@mail.gmail.com> 
	<f58506c40911182122j7541d7c8h3fd2105102a3a688@mail.gmail.com> 
	<8ac3ceb30911190003s74c6613aw6ac2926368915f52@mail.gmail.com> 
	<f58506c40911271245p25f332e5ubeb05f49e871fa20@mail.gmail.com> 
	<f96821860911271450o79c235d1h7be858365d624a1a@mail.gmail.com> 
	<f58506c40911271710h466cffe1gcb6d1e752ffa12df@mail.gmail.com>
Message-ID: <8ac3ceb30911272200t3ced48b2x3cc63256f1fbe820@mail.gmail.com>

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:myuserpassword at url/<http://myusername:myuserpassword at myexample.com/%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 <notethan at gmail.com> 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 <charley.baker at gmail.com>wrote:
>
>> Comments inline:
>>
>> On Fri, Nov 27, 2009 at 1:45 PM, Ethan <notethan at gmail.com> 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 ! <ynot408 at gmail.com> 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
>>>> Wtr-development at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/wtr-development
>>>>
>>>
>>>
>>> _______________________________________________
>>> Wtr-development mailing list
>>> Wtr-development at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/wtr-development
>>>
>>
>>
>> _______________________________________________
>> Wtr-development mailing list
>> Wtr-development at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wtr-development
>>
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091128/9f941e65/attachment-0001.html>

From bret at pettichord.com  Sun Nov 29 13:56:57 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Sun, 29 Nov 2009 12:56:57 -0600
Subject: [Wtr-development] js pop-ups internal within watir?
In-Reply-To: <f58506c40911271245p25f332e5ubeb05f49e871fa20@mail.gmail.com>
References: <7ac2300c0911180856n7e373fabm1e277c4effcab97f@mail.gmail.com>
	<ade75c5b0911180917p419d0d22ya0b440533326f2c0@mail.gmail.com>
	<f58506c40911181034h48392488y2983498a0c836bad@mail.gmail.com>
	<2a379a300911182100n680bcc18w7a38c70ecc09024b@mail.gmail.com>
	<f58506c40911182122j7541d7c8h3fd2105102a3a688@mail.gmail.com>
	<8ac3ceb30911190003s74c6613aw6ac2926368915f52@mail.gmail.com>
	<f58506c40911271245p25f332e5ubeb05f49e871fa20@mail.gmail.com>
Message-ID: <ade75c5b0911291056v7634fcd0p63a5150ba6e87d55@mail.gmail.com>

On Fri, Nov 27, 2009 at 2:45 PM, Ethan <notethan at gmail.com> wrote:

>
> 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.
>

If we are looking for a global name, i would use "dialog" or "popup", but
I'm not so sure we wouldn't be better off using different names for the
different types of dialogs.

3. ModalDialog#text (browser.modal_dialog.text)
>

API is fine. I'm unclear on what text would be returned.


> 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.
>

Prefer browser.dialog.text_field.set(value)
What happens for authentication dialogs that have two text fields?


> 5. ModalDialog#set_login_credentials(username, password)
>

Prefer browser.authenticate(:username => 'username', :password =>
'password')


> 6. ModalDialog#click_button(button_name)
>

Prefer browser.dialog.button(:name = 'button_name').click


-- 
Bret Pettichord
Lead Developer, Watir, www.watir.com

Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091129/c9583819/attachment.html>

From bret at pettichord.com  Sun Nov 29 14:12:23 2009
From: bret at pettichord.com (Bret Pettichord)
Date: Sun, 29 Nov 2009 13:12:23 -0600
Subject: [Wtr-development] js pop-ups internal within watir?
In-Reply-To: <f58506c40911271710h466cffe1gcb6d1e752ffa12df@mail.gmail.com>
References: <7ac2300c0911180856n7e373fabm1e277c4effcab97f@mail.gmail.com>
	<ade75c5b0911180917p419d0d22ya0b440533326f2c0@mail.gmail.com>
	<f58506c40911181034h48392488y2983498a0c836bad@mail.gmail.com>
	<2a379a300911182100n680bcc18w7a38c70ecc09024b@mail.gmail.com>
	<f58506c40911182122j7541d7c8h3fd2105102a3a688@mail.gmail.com>
	<8ac3ceb30911190003s74c6613aw6ac2926368915f52@mail.gmail.com>
	<f58506c40911271245p25f332e5ubeb05f49e871fa20@mail.gmail.com>
	<f96821860911271450o79c235d1h7be858365d624a1a@mail.gmail.com>
	<f58506c40911271710h466cffe1gcb6d1e752ffa12df@mail.gmail.com>
Message-ID: <ade75c5b0911291112u68e8e127med807b770d6b9a0f@mail.gmail.com>

On Fri, Nov 27, 2009 at 7:10 PM, Ethan <notethan at gmail.com> wrote:

> 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.


You've put some pretty basic changes in your code base, including the
changing the names of the classes and reorganizing files that pretty much
make it impossible for us to merge in any of your changes cleanly, since
we're pretty reluctant to make some of the basic changes you've made.

If you would like to contribute code to our project, you'll need to go about
it differently.

Bret
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091129/7c9eed1a/attachment.html>

From tim.koops at gmail.com  Mon Nov 30 16:48:59 2009
From: tim.koops at gmail.com (Tim Koopmans)
Date: Tue, 1 Dec 2009 08:48:59 +1100
Subject: [Wtr-development] Watir across the grid
In-Reply-To: <93ee69e90911160039t34ac2d19nabed6809ab1a23d9@mail.gmail.com>
References: <93ee69e90911032121p758fd110x96db0f0eb1fe8a6@mail.gmail.com>
	<93ee69e90911160039t34ac2d19nabed6809ab1a23d9@mail.gmail.com>
Message-ID: <93ee69e90911301348i63af35d7qd6b8d070a1b677b0@mail.gmail.com>

Hi guys,

Have been reviewing the efficiency of watirgrid's design of late in
terms of performance. One of the issues I see is having to thread in
user land, in order to execute parallel tests.

To give you an idea, this is the code I would have to write at the moment:
require 'rubygems'
require 'watirgrid'

browsers = Watir::Grid.new(:ring_server_port => 12358,
:ring_server_host => '192.168.1.122', :loglevel => Logger::DEBUG)
@browsers = browsers.start(:quantity => 2, :read_all => true)

threads = []
id = 0
@browsers.each do |browser|
  threads << Thread.new do
    b = browser[2].new_browser
    b.goto("http://www.google.com")
    b.text_field(:name, 'q').set("watirgrid")
    b.button(:name, "btnI").click
  end
end
threads.each {|thread| thread.join}

Basically create a new thread for every browser in the tuplespace and
then send it the commands. I don't believe this would be very
efficient with say 1,000 threads (if going for a large load test of
sorts).

So IPC (via DRB etc) sorts out the requirement of having multiple
processes (watirgrid providers) executing Ruby code, what I need is an
efficient way to coordinate all this on a single watirgrid controller.
Presently I'm using threads, but am open to ideas? Erlang? Anyone have
experience in this area?



Regards,
Tim Koopmans



On Mon, Nov 16, 2009 at 7:39 PM, Tim Koopmans <tim.koops at gmail.com> wrote:
> Hi guys,
>
> In view of my last email about this I've decided to push on with druby
> instead of http as I think the concepts surrounding distributed
> computing are a good fit. This work has progressed since my last, you
> can view the source here: http://github.com/90kts/watirgrid
>
> I haven't been able to contact any of the original authors of dwatir
> or watirgrid so ploughing ahead under my own direction. I've only been
> testing on a local machine with a windows VM, so the next steps are to
> test this approach in anger.
>
> If you'd like to have a look at the source, or play with the gem feel
> free (gemcutter is the primary source)
> ?gem install gemcutter
> ?gem tumble
> ?gem install watirgrid
>
> I've also included some instructions and detailed examples in the
> source as RDoc.
>
> I'm heading for a railscamp this weekend so planning on tinkering with
> watirgrid some more. As you can probably tell from my source, I'm a
> tester-wannabe-developer so any general advice you have on
> refactoring/structure/approach etc would be appreciated. I'll try and
> round up some advice from railscamp.
>
>
> Regards,
> Tim Koopmans
>
>
>
> On Wed, Nov 4, 2009 at 4:21 PM, Tim Koopmans <tim.koops at gmail.com> wrote:
>> Hi guys,
>>
>> I've recently been tinkering with distributed testing across a grid
>> network with Watir. This work is currently hosted on GitHub at
>> http://github.com/90kts/watirgrid
>>
>> I based my initial design off DWatir[1] which uses Rinda to implement
>> a tuple space: a repository of tuples that can be accessed
>> concurrently. I've tried unsuccessfully to contact the original author
>> Dane Avilla, which looks like development stopped in 2007.
>>
>> Since starting the GitHub project I've noticed a similar solution, not
>> using Rinda (UDP broadcast over druby protocol) but WebBrick (http
>> protocol) instead. It's also called WatirGrid[2] (oops!) and the
>> author looks to be Peter Houghton.
>>
>> My end state is to facilitate some form of load testing with watir,
>> using many browsers concurrently. I plan to release it as a separate
>> gem. My preference so far is to continue with the druby protocol.
>>
>> Questions to you are do you have any preference on choice of protocol
>> (druby vs. http) and does anyone know the original authors so that I
>> might get in contact with them?
>>
>> [1] http://dwatir.rubyforge.org/
>> [2] http://www.ohloh.net/p/watirgrid
>>
>> Regards,
>> Tim Koopmans
>>
>

From paul.rogers at shaw.ca  Mon Nov 30 17:20:05 2009
From: paul.rogers at shaw.ca (Paul Rogers)
Date: Mon, 30 Nov 2009 15:20:05 -0700
Subject: [Wtr-development] Watir across the grid
In-Reply-To: <93ee69e90911301348i63af35d7qd6b8d070a1b677b0@mail.gmail.com>
References: <93ee69e90911032121p758fd110x96db0f0eb1fe8a6@mail.gmail.com>
	<93ee69e90911160039t34ac2d19nabed6809ab1a23d9@mail.gmail.com>
	<93ee69e90911301348i63af35d7qd6b8d070a1b677b0@mail.gmail.com>
Message-ID: <e7eaafaa0911301420y7c81828cpf16c7dce1e789762@mail.gmail.com>

wouldnt you just be better telling the remote machine to open a browser and
start a certain test?
or failing that, use more like a http  interface where each browser requests
its next command ( http://controller/my-id/next-request-please )

Paul

On Mon, Nov 30, 2009 at 2:48 PM, Tim Koopmans <tim.koops at gmail.com> wrote:

> Hi guys,
>
> Have been reviewing the efficiency of watirgrid's design of late in
> terms of performance. One of the issues I see is having to thread in
> user land, in order to execute parallel tests.
>
> To give you an idea, this is the code I would have to write at the moment:
> require 'rubygems'
> require 'watirgrid'
>
> browsers = Watir::Grid.new(:ring_server_port => 12358,
> :ring_server_host => '192.168.1.122', :loglevel => Logger::DEBUG)
> @browsers = browsers.start(:quantity => 2, :read_all => true)
>
> threads = []
> id = 0
> @browsers.each do |browser|
>  threads << Thread.new do
>    b = browser[2].new_browser
>    b.goto("http://www.google.com")
>    b.text_field(:name, 'q').set("watirgrid")
>    b.button(:name, "btnI").click
>  end
> end
> threads.each {|thread| thread.join}
>
> Basically create a new thread for every browser in the tuplespace and
> then send it the commands. I don't believe this would be very
> efficient with say 1,000 threads (if going for a large load test of
> sorts).
>
> So IPC (via DRB etc) sorts out the requirement of having multiple
> processes (watirgrid providers) executing Ruby code, what I need is an
> efficient way to coordinate all this on a single watirgrid controller.
> Presently I'm using threads, but am open to ideas? Erlang? Anyone have
> experience in this area?
>
>
>
> Regards,
> Tim Koopmans
>
>
>
> On Mon, Nov 16, 2009 at 7:39 PM, Tim Koopmans <tim.koops at gmail.com> wrote:
> > Hi guys,
> >
> > In view of my last email about this I've decided to push on with druby
> > instead of http as I think the concepts surrounding distributed
> > computing are a good fit. This work has progressed since my last, you
> > can view the source here: http://github.com/90kts/watirgrid
> >
> > I haven't been able to contact any of the original authors of dwatir
> > or watirgrid so ploughing ahead under my own direction. I've only been
> > testing on a local machine with a windows VM, so the next steps are to
> > test this approach in anger.
> >
> > If you'd like to have a look at the source, or play with the gem feel
> > free (gemcutter is the primary source)
> >  gem install gemcutter
> >  gem tumble
> >  gem install watirgrid
> >
> > I've also included some instructions and detailed examples in the
> > source as RDoc.
> >
> > I'm heading for a railscamp this weekend so planning on tinkering with
> > watirgrid some more. As you can probably tell from my source, I'm a
> > tester-wannabe-developer so any general advice you have on
> > refactoring/structure/approach etc would be appreciated. I'll try and
> > round up some advice from railscamp.
> >
> >
> > Regards,
> > Tim Koopmans
> >
> >
> >
> > On Wed, Nov 4, 2009 at 4:21 PM, Tim Koopmans <tim.koops at gmail.com>
> wrote:
> >> Hi guys,
> >>
> >> I've recently been tinkering with distributed testing across a grid
> >> network with Watir. This work is currently hosted on GitHub at
> >> http://github.com/90kts/watirgrid
> >>
> >> I based my initial design off DWatir[1] which uses Rinda to implement
> >> a tuple space: a repository of tuples that can be accessed
> >> concurrently. I've tried unsuccessfully to contact the original author
> >> Dane Avilla, which looks like development stopped in 2007.
> >>
> >> Since starting the GitHub project I've noticed a similar solution, not
> >> using Rinda (UDP broadcast over druby protocol) but WebBrick (http
> >> protocol) instead. It's also called WatirGrid[2] (oops!) and the
> >> author looks to be Peter Houghton.
> >>
> >> My end state is to facilitate some form of load testing with watir,
> >> using many browsers concurrently. I plan to release it as a separate
> >> gem. My preference so far is to continue with the druby protocol.
> >>
> >> Questions to you are do you have any preference on choice of protocol
> >> (druby vs. http) and does anyone know the original authors so that I
> >> might get in contact with them?
> >>
> >> [1] http://dwatir.rubyforge.org/
> >> [2] http://www.ohloh.net/p/watirgrid
> >>
> >> Regards,
> >> Tim Koopmans
> >>
> >
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20091130/2f8b6b4b/attachment-0001.html>