From abaird at bairdsnet.net  Sun May  2 22:26:26 2010
From: abaird at bairdsnet.net (Alan Baird)
Date: Sun, 2 May 2010 21:26:26 -0500
Subject: [Wtr-development] [JIRA] Commented: (WTR-433) IE#text.include?
	method returning true for hidden text also
In-Reply-To: <n2iade75c5b1004300734kd9f3ddefydef2cc8b356447cc@mail.gmail.com>
References: <32383274.900.1271267377629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<8316533.79.1272557610610.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<n2iade75c5b1004300734kd9f3ddefydef2cc8b356447cc@mail.gmail.com>
Message-ID: <i2z2a379a301005021926w42f621a0ne7ceec1b222d9ecb@mail.gmail.com>

> Also, pretty reluctant to add any methods that will be hard to implement in
> different implementations. As it is already, the "text" method is not
> compatible between versions and we should really be encouraging people not
> to use it. I don't think it really is a good practice any way.

Bret -

Can you clarify this a bit?  I'm thinking you are saying it's not good
practice, say, to get the text of a span by doing 'browser.span(:id,
'someid').text'.  However, I'm not sure I can immediately think of a
better way of doing this other than parsing the html.  I'm pretty sure
that's not what you mean.

What is the better way of doing this?

Alan

From bret at pettichord.com  Mon May  3 11:22:36 2010
From: bret at pettichord.com (Bret Pettichord)
Date: Mon, 3 May 2010 10:22:36 -0500
Subject: [Wtr-development] [JIRA] Commented: (WTR-433) IE#text.include?
	method returning true for hidden text also
In-Reply-To: <i2z2a379a301005021926w42f621a0ne7ceec1b222d9ecb@mail.gmail.com>
References: <32383274.900.1271267377629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<8316533.79.1272557610610.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<n2iade75c5b1004300734kd9f3ddefydef2cc8b356447cc@mail.gmail.com>
	<i2z2a379a301005021926w42f621a0ne7ceec1b222d9ecb@mail.gmail.com>
Message-ID: <g2jade75c5b1005030822h52d55e8fu338b93f854c476d@mail.gmail.com>

Good question.

I am talking about (and arguing agains) using the text method on the IE
object itself (IE#text), not using on specific elements on a page.

Bret

On Sun, May 2, 2010 at 9:26 PM, Alan Baird <abaird at bairdsnet.net> wrote:

> > Also, pretty reluctant to add any methods that will be hard to implement
> in
> > different implementations. As it is already, the "text" method is not
> > compatible between versions and we should really be encouraging people
> not
> > to use it. I don't think it really is a good practice any way.
>
> Bret -
>
> Can you clarify this a bit?  I'm thinking you are saying it's not good
> practice, say, to get the text of a span by doing 'browser.span(:id,
> 'someid').text'.  However, I'm not sure I can immediately think of a
> better way of doing this other than parsing the html.  I'm pretty sure
> that's not what you mean.
>
> What is the better way of doing this?
>
> Alan
> _______________________________________________
> 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/20100503/973a75ba/attachment.html>

From jarmo.p at gmail.com  Mon May  3 11:47:51 2010
From: jarmo.p at gmail.com (Jarmo)
Date: Mon, 3 May 2010 18:47:51 +0300
Subject: [Wtr-development] [JIRA] Commented: (WTR-433) IE#text.include?
	method returning true for hidden text also
In-Reply-To: <g2jade75c5b1005030822h52d55e8fu338b93f854c476d@mail.gmail.com>
References: <32383274.900.1271267377629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<8316533.79.1272557610610.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<n2iade75c5b1004300734kd9f3ddefydef2cc8b356447cc@mail.gmail.com> 
	<i2z2a379a301005021926w42f621a0ne7ceec1b222d9ecb@mail.gmail.com> 
	<g2jade75c5b1005030822h52d55e8fu338b93f854c476d@mail.gmail.com>
Message-ID: <g2vb7bf92f01005030847o1c4db377o108610e2b112d796@mail.gmail.com>

Could you be more specific (and bring some concrete example) what's
bad about using IE#text.include?

Jarmo

On Mon, May 3, 2010 at 6:22 PM, Bret Pettichord <bret at pettichord.com> wrote:
> Good question.
>
> I am talking about (and arguing agains) using the text method on the IE
> object itself (IE#text), not using on specific elements on a page.
>
> Bret
>
> On Sun, May 2, 2010 at 9:26 PM, Alan Baird <abaird at bairdsnet.net> wrote:
>>
>> > Also, pretty reluctant to add any methods that will be hard to implement
>> > in
>> > different implementations. As it is already, the "text" method is not
>> > compatible between versions and we should really be encouraging people
>> > not
>> > to use it. I don't think it really is a good practice any way.
>>
>> Bret -
>>
>> Can you clarify this a bit? ?I'm thinking you are saying it's not good
>> practice, say, to get the text of a span by doing 'browser.span(:id,
>> 'someid').text'. ?However, I'm not sure I can immediately think of a
>> better way of doing this other than parsing the html. ?I'm pretty sure
>> that's not what you mean.
>>
>> What is the better way of doing this?
>>
>> Alan
>> _______________________________________________
>> 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
>

From bret at pettichord.com  Mon May  3 13:56:53 2010
From: bret at pettichord.com (Bret Pettichord)
Date: Mon, 3 May 2010 12:56:53 -0500
Subject: [Wtr-development] [JIRA] Commented: (WTR-433) IE#text.include?
	method returning true for hidden text also
In-Reply-To: <g2vb7bf92f01005030847o1c4db377o108610e2b112d796@mail.gmail.com>
References: <32383274.900.1271267377629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<8316533.79.1272557610610.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<n2iade75c5b1004300734kd9f3ddefydef2cc8b356447cc@mail.gmail.com>
	<i2z2a379a301005021926w42f621a0ne7ceec1b222d9ecb@mail.gmail.com>
	<g2jade75c5b1005030822h52d55e8fu338b93f854c476d@mail.gmail.com>
	<g2vb7bf92f01005030847o1c4db377o108610e2b112d796@mail.gmail.com>
Message-ID: <i2uade75c5b1005031056w58a8a308uf9c0a972d46af530@mail.gmail.com>

The problem is that there is no good spec about exactly what the exact text
that should be returned by IE#text. We fixed some of the incompatibilities
between how this worked on IE and Firefox, but I am sure there are more
differences, e.g. encodings and whitespace and the like.

Although I see a lot of value for an Element#visible? method it would be
quite difficult to write IE#visible_text because it would be complex and
frankly any one who was smart enough to do a good job writing it would also
be smart enough to know that they shouldn't use it.

Because, in the end using IE#text means you are checking all the text of the
page, and it is a better testing approach to be more narrow in what you
test.

Bret

On Mon, May 3, 2010 at 10:47 AM, Jarmo <jarmo.p at gmail.com> wrote:

> Could you be more specific (and bring some concrete example) what's
> bad about using IE#text.include?
>
> Jarmo
>
> On Mon, May 3, 2010 at 6:22 PM, Bret Pettichord <bret at pettichord.com>
> wrote:
> > Good question.
> >
> > I am talking about (and arguing agains) using the text method on the IE
> > object itself (IE#text), not using on specific elements on a page.
> >
> > Bret
> >
> > On Sun, May 2, 2010 at 9:26 PM, Alan Baird <abaird at bairdsnet.net> wrote:
> >>
> >> > Also, pretty reluctant to add any methods that will be hard to
> implement
> >> > in
> >> > different implementations. As it is already, the "text" method is not
> >> > compatible between versions and we should really be encouraging people
> >> > not
> >> > to use it. I don't think it really is a good practice any way.
> >>
> >> Bret -
> >>
> >> Can you clarify this a bit?  I'm thinking you are saying it's not good
> >> practice, say, to get the text of a span by doing 'browser.span(:id,
> >> 'someid').text'.  However, I'm not sure I can immediately think of a
> >> better way of doing this other than parsing the html.  I'm pretty sure
> >> that's not what you mean.
> >>
> >> What is the better way of doing this?
> >>
> >> Alan
> >> _______________________________________________
> >> 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/20100503/39905a0f/attachment-0001.html>

From abaird at bairdsnet.net  Tue May  4 22:39:34 2010
From: abaird at bairdsnet.net (Alan Baird)
Date: Tue, 4 May 2010 21:39:34 -0500
Subject: [Wtr-development] [JIRA] Commented: (WTR-433) IE#text.include?
	method returning true for hidden text also
In-Reply-To: <i2uade75c5b1005031056w58a8a308uf9c0a972d46af530@mail.gmail.com>
References: <32383274.900.1271267377629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<8316533.79.1272557610610.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<n2iade75c5b1004300734kd9f3ddefydef2cc8b356447cc@mail.gmail.com>
	<i2z2a379a301005021926w42f621a0ne7ceec1b222d9ecb@mail.gmail.com>
	<g2jade75c5b1005030822h52d55e8fu338b93f854c476d@mail.gmail.com>
	<g2vb7bf92f01005030847o1c4db377o108610e2b112d796@mail.gmail.com>
	<i2uade75c5b1005031056w58a8a308uf9c0a972d46af530@mail.gmail.com>
Message-ID: <g2i2a379a301005041939pccf21db1h9eb0b656398f6ab5@mail.gmail.com>

Thanks for the reply Bret.  I also want to add my .02 that "visible"
is a bit difficult to nail down.  I find the .visible? method to be
pretty good, but not always 100% dependable.  For example, in one of
the apps I test, an element is made not visible by using the zindex
value of -999 to place certain elements behind others, thus making
them not visible to the users, but "visible" in terms of the .visible?
method.  This is a legitimate way of doing things in HTML, but it
would be very difficult to write .visible? to handle this case.

As for IE#text, it seems like using this to detect things on a page is
a recipe for bad things to happen.  I can't see myself being in favor
of it.

Alan

From notethan at gmail.com  Wed May  5 13:47:06 2010
From: notethan at gmail.com (Ethan)
Date: Wed, 5 May 2010 13:47:06 -0400
Subject: [Wtr-development] Vapir
Message-ID: <w2hf58506c41005051047t8acf7117h71b5ae422afc4308@mail.gmail.com>

Dear Watir people,
I am happy to announce the release of the Vapir library, which is a
fork of Watir and FireWatir.

It is documented primarily at the github wiki at
http://wiki.github.com/vapir/vapir/
Documentation is sorely lacking at the moment, and improving it is my
highest priority, but putting the code out for people to use preceded
that.

Links to other aspects of the forked project are listed at http://vapir.org/

The API is in most cases the same, with some changes where I felt it
was best; these are enumerated at
http://wiki.github.com/vapir/vapir/differences-from-watir-api

It is a release candidate currently, and can be installed using the
--pre flag to rubygems (rubygems 1.3.6 is required; run gem update
--system if you are on an earlier version).
gem install --pre vapir-firefox
gem install --pre vapir-ie

Major improvements over Watir are:
- Modal dialog API which is (mostly) consistent between IE and Firefox
- http://wiki.github.com/vapir/vapir/modal-dialogs
- Unified codebase for both Firefox and IE interaction - basically,
everything that works in IE works in Firefox as well, which is not the
case with FireWatir.
- Many bug fixes and feature enhancements for issues in Watir's issue
tracker, which will be documented more thoroughly on the wiki in the
coming days.

I would encourage any questions or discussion to go to Vapir's mailing
list, not Watir's. The forked project is intended to stand on its own,
separate from the Watir library due to a great deal of changes in the
codebase which make it to some degree (a small degree, hopefully)
incompatible. Support will be on Vapir's mailing list at
http://groups.google.com/group/vapir

-Ethan

From tim.koops at gmail.com  Wed May  5 15:39:54 2010
From: tim.koops at gmail.com (Tim Koopmans)
Date: Thu, 6 May 2010 05:39:54 +1000
Subject: [Wtr-development] Vapir
In-Reply-To: <w2hf58506c41005051047t8acf7117h71b5ae422afc4308@mail.gmail.com>
References: <w2hf58506c41005051047t8acf7117h71b5ae422afc4308@mail.gmail.com>
Message-ID: <A2D1D2B1-4F75-4154-BA9C-C83D11416DA2@gmail.com>

This makes no sense to me. Shouldn't we just merge important changes  
like modal support into Watir main? Or am I missing something? Is  
vapir a silent protest of sorts?

Regards,
Tim



On 06/05/2010, at 3:47, Ethan <notethan at gmail.com> wrote:

> Dear Watir people,
> I am happy to announce the release of the Vapir library, which is a
> fork of Watir and FireWatir.
>
> It is documented primarily at the github wiki at
> http://wiki.github.com/vapir/vapir/
> Documentation is sorely lacking at the moment, and improving it is my
> highest priority, but putting the code out for people to use preceded
> that.
>
> Links to other aspects of the forked project are listed at http://vapir.org/
>
> The API is in most cases the same, with some changes where I felt it
> was best; these are enumerated at
> http://wiki.github.com/vapir/vapir/differences-from-watir-api
>
> It is a release candidate currently, and can be installed using the
> --pre flag to rubygems (rubygems 1.3.6 is required; run gem update
> --system if you are on an earlier version).
> gem install --pre vapir-firefox
> gem install --pre vapir-ie
>
> Major improvements over Watir are:
> - Modal dialog API which is (mostly) consistent between IE and Firefox
> - http://wiki.github.com/vapir/vapir/modal-dialogs
> - Unified codebase for both Firefox and IE interaction - basically,
> everything that works in IE works in Firefox as well, which is not the
> case with FireWatir.
> - Many bug fixes and feature enhancements for issues in Watir's issue
> tracker, which will be documented more thoroughly on the wiki in the
> coming days.
>
> I would encourage any questions or discussion to go to Vapir's mailing
> list, not Watir's. The forked project is intended to stand on its own,
> separate from the Watir library due to a great deal of changes in the
> codebase which make it to some degree (a small degree, hopefully)
> incompatible. Support will be on Vapir's mailing list at
> http://groups.google.com/group/vapir
>
> -Ethan
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development

From bret at pettichord.com  Wed May  5 17:01:26 2010
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 5 May 2010 16:01:26 -0500
Subject: [Wtr-development] Vapir
In-Reply-To: <A2D1D2B1-4F75-4154-BA9C-C83D11416DA2@gmail.com>
References: <w2hf58506c41005051047t8acf7117h71b5ae422afc4308@mail.gmail.com>
	<A2D1D2B1-4F75-4154-BA9C-C83D11416DA2@gmail.com>
Message-ID: <x2tade75c5b1005051401g6d2030eej8a0f04046de54719@mail.gmail.com>

Yes, please let us know if there are features of Vapir that you would like
to see merged into Watir. Vapir's modal support uses different method names
for features that are already in Watir. It is unclear to me what additional
functionality is present.

Bret

On Wed, May 5, 2010 at 2:39 PM, Tim Koopmans <tim.koops at gmail.com> wrote:

> This makes no sense to me. Shouldn't we just merge important changes like
> modal support into Watir main? Or am I missing something? Is vapir a silent
> protest of sorts?
>
> Regards,
> Tim
>
>
>
>
> On 06/05/2010, at 3:47, Ethan <notethan at gmail.com> wrote:
>
>  Dear Watir people,
>> I am happy to announce the release of the Vapir library, which is a
>> fork of Watir and FireWatir.
>>
>> It is documented primarily at the github wiki at
>> http://wiki.github.com/vapir/vapir/
>> Documentation is sorely lacking at the moment, and improving it is my
>> highest priority, but putting the code out for people to use preceded
>> that.
>>
>> Links to other aspects of the forked project are listed at
>> http://vapir.org/
>>
>> The API is in most cases the same, with some changes where I felt it
>> was best; these are enumerated at
>> http://wiki.github.com/vapir/vapir/differences-from-watir-api
>>
>> It is a release candidate currently, and can be installed using the
>> --pre flag to rubygems (rubygems 1.3.6 is required; run gem update
>> --system if you are on an earlier version).
>> gem install --pre vapir-firefox
>> gem install --pre vapir-ie
>>
>> Major improvements over Watir are:
>> - Modal dialog API which is (mostly) consistent between IE and Firefox
>> - http://wiki.github.com/vapir/vapir/modal-dialogs
>> - Unified codebase for both Firefox and IE interaction - basically,
>> everything that works in IE works in Firefox as well, which is not the
>> case with FireWatir.
>> - Many bug fixes and feature enhancements for issues in Watir's issue
>> tracker, which will be documented more thoroughly on the wiki in the
>> coming days.
>>
>> I would encourage any questions or discussion to go to Vapir's mailing
>> list, not Watir's. The forked project is intended to stand on its own,
>> separate from the Watir library due to a great deal of changes in the
>> codebase which make it to some degree (a small degree, hopefully)
>> incompatible. Support will be on Vapir's mailing list at
>> http://groups.google.com/group/vapir
>>
>> -Ethan
>> _______________________________________________
>> 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/20100505/71e4645c/attachment.html>

From bret at pettichord.com  Wed May  5 17:02:24 2010
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 5 May 2010 16:02:24 -0500
Subject: [Wtr-development] [JIRA] Commented: (WTR-433) IE#text.include?
	method returning true for hidden text also
In-Reply-To: <g2i2a379a301005041939pccf21db1h9eb0b656398f6ab5@mail.gmail.com>
References: <32383274.900.1271267377629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<8316533.79.1272557610610.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<n2iade75c5b1004300734kd9f3ddefydef2cc8b356447cc@mail.gmail.com>
	<i2z2a379a301005021926w42f621a0ne7ceec1b222d9ecb@mail.gmail.com>
	<g2jade75c5b1005030822h52d55e8fu338b93f854c476d@mail.gmail.com>
	<g2vb7bf92f01005030847o1c4db377o108610e2b112d796@mail.gmail.com>
	<i2uade75c5b1005031056w58a8a308uf9c0a972d46af530@mail.gmail.com>
	<g2i2a379a301005041939pccf21db1h9eb0b656398f6ab5@mail.gmail.com>
Message-ID: <h2yade75c5b1005051402sa10e2fcbpa60e6a0ce9b1fb88@mail.gmail.com>

Yes, I agree completely on both points.

Bret

On Tue, May 4, 2010 at 9:39 PM, Alan Baird <abaird at bairdsnet.net> wrote:

> Thanks for the reply Bret.  I also want to add my .02 that "visible"
> is a bit difficult to nail down.  I find the .visible? method to be
> pretty good, but not always 100% dependable.  For example, in one of
> the apps I test, an element is made not visible by using the zindex
> value of -999 to place certain elements behind others, thus making
> them not visible to the users, but "visible" in terms of the .visible?
> method.  This is a legitimate way of doing things in HTML, but it
> would be very difficult to write .visible? to handle this case.
>
> As for IE#text, it seems like using this to detect things on a page is
> a recipe for bad things to happen.  I can't see myself being in favor
> of it.
>
> Alan
> _______________________________________________
> 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/20100505/d9023c53/attachment.html>

From jarmo.p at gmail.com  Wed May  5 17:18:56 2010
From: jarmo.p at gmail.com (Jarmo)
Date: Thu, 6 May 2010 00:18:56 +0300
Subject: [Wtr-development] [JIRA] Commented: (WTR-433) IE#text.include?
	method returning true for hidden text also
In-Reply-To: <h2yade75c5b1005051402sa10e2fcbpa60e6a0ce9b1fb88@mail.gmail.com>
References: <32383274.900.1271267377629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<8316533.79.1272557610610.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<n2iade75c5b1004300734kd9f3ddefydef2cc8b356447cc@mail.gmail.com> 
	<i2z2a379a301005021926w42f621a0ne7ceec1b222d9ecb@mail.gmail.com> 
	<g2jade75c5b1005030822h52d55e8fu338b93f854c476d@mail.gmail.com> 
	<g2vb7bf92f01005030847o1c4db377o108610e2b112d796@mail.gmail.com> 
	<i2uade75c5b1005031056w58a8a308uf9c0a972d46af530@mail.gmail.com> 
	<g2i2a379a301005041939pccf21db1h9eb0b656398f6ab5@mail.gmail.com> 
	<h2yade75c5b1005051402sa10e2fcbpa60e6a0ce9b1fb88@mail.gmail.com>
Message-ID: <z2qb7bf92f01005051418ic3d639ccr9602fa6fd9aeaa6c@mail.gmail.com>

Okay, i agree with most of this, but i still think that using
IE#text.include? is not bad practice, when i want to check that
there's no global errors (or anything else global). So, for example -
browser.text.should_not include?(Exception).

Jarmo

On Thu, May 6, 2010 at 12:02 AM, Bret Pettichord <bret at pettichord.com> wrote:
> Yes, I agree completely on both points.
>
> Bret
>
> On Tue, May 4, 2010 at 9:39 PM, Alan Baird <abaird at bairdsnet.net> wrote:
>>
>> Thanks for the reply Bret. ?I also want to add my .02 that "visible"
>> is a bit difficult to nail down. ?I find the .visible? method to be
>> pretty good, but not always 100% dependable. ?For example, in one of
>> the apps I test, an element is made not visible by using the zindex
>> value of -999 to place certain elements behind others, thus making
>> them not visible to the users, but "visible" in terms of the .visible?
>> method. ?This is a legitimate way of doing things in HTML, but it
>> would be very difficult to write .visible? to handle this case.
>>
>> As for IE#text, it seems like using this to detect things on a page is
>> a recipe for bad things to happen. ?I can't see myself being in favor
>> of it.
>>
>> Alan
>> _______________________________________________
>> 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
>

From notethan at gmail.com  Wed May  5 18:15:24 2010
From: notethan at gmail.com (Ethan)
Date: Wed, 5 May 2010 18:15:24 -0400
Subject: [Wtr-development] [JIRA] Commented: (WTR-433) IE#text.include?
	method returning true for hidden text also
In-Reply-To: <g2i2a379a301005041939pccf21db1h9eb0b656398f6ab5@mail.gmail.com>
References: <32383274.900.1271267377629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<8316533.79.1272557610610.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<n2iade75c5b1004300734kd9f3ddefydef2cc8b356447cc@mail.gmail.com> 
	<i2z2a379a301005021926w42f621a0ne7ceec1b222d9ecb@mail.gmail.com> 
	<g2jade75c5b1005030822h52d55e8fu338b93f854c476d@mail.gmail.com> 
	<g2vb7bf92f01005030847o1c4db377o108610e2b112d796@mail.gmail.com> 
	<i2uade75c5b1005031056w58a8a308uf9c0a972d46af530@mail.gmail.com> 
	<g2i2a379a301005041939pccf21db1h9eb0b656398f6ab5@mail.gmail.com>
Message-ID: <h2mf58506c41005051515i63c4991fr213fdf1fabe72224@mail.gmail.com>

Having realized from this discussion that in some places in my application,
I really ought to be checking for visible text, not just text, I went ahead
and implemented this for vapir. It is, as Alan says, not 100%, as that is
probably not possible, but I believe it handles all cases of
style.visibility and style.display what with inheritance of css styles and
all.

It works for me in both firefox and IE. Currently only a method of Element,
not the browser class, but I'll add it to the browser class shortly.

Probably not trivial to port back to watir, and not possible on firewatir,
but it's there if anybody feels like having a look.

http://github.com/vapir/vapir/commit/6b27ab798d18fb56f4ebd05588f905d8f6524598

I'm with Jarmo; using #text isn't bad practice (and is quite necessary) as
long as you take into account that whitespace will probably end up being
different between browsers.

-Ethan

On Tue, May 4, 2010 at 22:39, Alan Baird <abaird at bairdsnet.net> wrote:

> Thanks for the reply Bret.  I also want to add my .02 that "visible"
> is a bit difficult to nail down.  I find the .visible? method to be
> pretty good, but not always 100% dependable.  For example, in one of
> the apps I test, an element is made not visible by using the zindex
> value of -999 to place certain elements behind others, thus making
> them not visible to the users, but "visible" in terms of the .visible?
> method.  This is a legitimate way of doing things in HTML, but it
> would be very difficult to write .visible? to handle this case.
>
> As for IE#text, it seems like using this to detect things on a page is
> a recipe for bad things to happen.  I can't see myself being in favor
> of 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/20100505/099533ae/attachment.html>

From jari.bakken at gmail.com  Wed May  5 23:07:58 2010
From: jari.bakken at gmail.com (Jari Bakken)
Date: Thu, 6 May 2010 05:07:58 +0200
Subject: [Wtr-development] [JIRA] Commented: (WTR-433) IE#text.include?
	method returning true for hidden text also
In-Reply-To: <h2mf58506c41005051515i63c4991fr213fdf1fabe72224@mail.gmail.com>
References: <32383274.900.1271267377629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<8316533.79.1272557610610.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<n2iade75c5b1004300734kd9f3ddefydef2cc8b356447cc@mail.gmail.com>
	<i2z2a379a301005021926w42f621a0ne7ceec1b222d9ecb@mail.gmail.com>
	<g2jade75c5b1005030822h52d55e8fu338b93f854c476d@mail.gmail.com>
	<g2vb7bf92f01005030847o1c4db377o108610e2b112d796@mail.gmail.com>
	<i2uade75c5b1005031056w58a8a308uf9c0a972d46af530@mail.gmail.com>
	<g2i2a379a301005041939pccf21db1h9eb0b656398f6ab5@mail.gmail.com>
	<h2mf58506c41005051515i63c4991fr213fdf1fabe72224@mail.gmail.com>
Message-ID: <g2teae5f6f91005052007r668a9104ic0f748f8ca6f6a66@mail.gmail.com>

On Thu, May 6, 2010 at 12:15 AM, Ethan <notethan at gmail.com> wrote:
> Having realized from this discussion that in some places in my application,
> I really ought to be checking for visible text, not just text, I went ahead
> and implemented this for vapir.

I should add that neither Celerity nor watir-webdriver returns
non-visible text for Browser#text or Element#text. That decision is
made by the underlying libraries, and not really feasible to work
around.

The Javascript algorithm used to get text in Firefox/Chrome is here:

  http://code.google.com/p/selenium/source/browse/trunk/firefox/src/extension/components/utils.js#340

I don't think this is a big deal - we've been running our tests on
both Watir and Celerity for ages without it being an issue. And a need
to do things a user wouldn't be able to in your browser tests is
usually a sign that it should be covered by tests in another part of
the stack instead.

From bret at pettichord.com  Wed May  5 23:25:13 2010
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 5 May 2010 22:25:13 -0500
Subject: [Wtr-development] [JIRA] Commented: (WTR-433) IE#text.include?
	method returning true for hidden text also
In-Reply-To: <g2teae5f6f91005052007r668a9104ic0f748f8ca6f6a66@mail.gmail.com>
References: <32383274.900.1271267377629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<8316533.79.1272557610610.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<n2iade75c5b1004300734kd9f3ddefydef2cc8b356447cc@mail.gmail.com>
	<i2z2a379a301005021926w42f621a0ne7ceec1b222d9ecb@mail.gmail.com>
	<g2jade75c5b1005030822h52d55e8fu338b93f854c476d@mail.gmail.com>
	<g2vb7bf92f01005030847o1c4db377o108610e2b112d796@mail.gmail.com>
	<i2uade75c5b1005031056w58a8a308uf9c0a972d46af530@mail.gmail.com>
	<g2i2a379a301005041939pccf21db1h9eb0b656398f6ab5@mail.gmail.com>
	<h2mf58506c41005051515i63c4991fr213fdf1fabe72224@mail.gmail.com>
	<g2teae5f6f91005052007r668a9104ic0f748f8ca6f6a66@mail.gmail.com>
Message-ID: <l2zade75c5b1005052025lab966735lea53f70f13a90d43@mail.gmail.com>

After reading the discussion on stack-overflow, I was already thinking that
Watir's text method should probably restrict itself to visible text as well.
http://stackoverflow.com/questions/2733080/does-watirs-browser-text-include-count-text-inside-invisible-divs-if-so-how-t

Jari, thanks for chiming in on this. Compatibility was another concern, and
it seems also another argument for not including visible text in the string
returned.

Bret

On Wed, May 5, 2010 at 10:07 PM, Jari Bakken <jari.bakken at gmail.com> wrote:

> On Thu, May 6, 2010 at 12:15 AM, Ethan <notethan at gmail.com> wrote:
> > Having realized from this discussion that in some places in my
> application,
> > I really ought to be checking for visible text, not just text, I went
> ahead
> > and implemented this for vapir.
>
> I should add that neither Celerity nor watir-webdriver returns
> non-visible text for Browser#text or Element#text. That decision is
> made by the underlying libraries, and not really feasible to work
> around.
>
> The Javascript algorithm used to get text in Firefox/Chrome is here:
>
>
> http://code.google.com/p/selenium/source/browse/trunk/firefox/src/extension/components/utils.js#340
>
> I don't think this is a big deal - we've been running our tests on
> both Watir and Celerity for ages without it being an issue. And a need
> to do things a user wouldn't be able to in your browser tests is
> usually a sign that it should be covered by tests in another part of
> the stack instead.
> _______________________________________________
> 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/20100505/0d108de4/attachment.html>

From watirjira at gmail.com  Wed May  5 23:27:30 2010
From: watirjira at gmail.com (Bret Pettichord (JIRA))
Date: Wed, 5 May 2010 22:27:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Reopened: (WTR-433) IE#text.include?
 method returning true for hidden text also
In-Reply-To: <32383274.900.1271267377629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <3798551.116.1273116450711.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


     [ http://jira.openqa.org/browse/WTR-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bret Pettichord reopened WTR-433:
---------------------------------


Reopening this in the face of public opinion to the contrary.

> IE#text.include? method returning true for hidden text also
> -----------------------------------------------------------
>
>                 Key: WTR-433
>                 URL: http://jira.openqa.org/browse/WTR-433
>             Project: Watir
>          Issue Type: Bug
>          Components: HTML Controls
>    Affects Versions: 1.5.6
>         Environment: windows xp
>            Reporter: shanth
>            Priority: Major
>
> IE#text.include? method returning true for hidden text also

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Wed May  5 23:27:30 2010
From: watirjira at gmail.com (Bret Pettichord (JIRA))
Date: Wed, 5 May 2010 22:27:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-433) IE#text.include?
 method returning true for hidden text also
In-Reply-To: <32383274.900.1271267377629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <5227007.118.1273116450983.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19625#action_19625 ] 

Bret Pettichord commented on WTR-433:
-------------------------------------

See several relevant arguments:
http://stackoverflow.com/questions/2733080/does-watirs-browser-text-include-count-text-inside-invisible-divs-if-so-how-t


> IE#text.include? method returning true for hidden text also
> -----------------------------------------------------------
>
>                 Key: WTR-433
>                 URL: http://jira.openqa.org/browse/WTR-433
>             Project: Watir
>          Issue Type: Bug
>          Components: HTML Controls
>    Affects Versions: 1.5.6
>         Environment: windows xp
>            Reporter: shanth
>            Priority: Major
>
> IE#text.include? method returning true for hidden text also

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Thu May  6 00:32:31 2010
From: watirjira at gmail.com (Alister Scott (JIRA))
Date: Wed, 5 May 2010 23:32:31 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-428) Firefox URL string is
	always blank
In-Reply-To: <21390032.468.1269375217002.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <3391317.120.1273120351168.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19626#action_19626 ] 

Alister Scott commented on WTR-428:
-----------------------------------

This is also a problem on Windows XP, so it doesn't look platform specific.

> Firefox URL string is always blank
> ----------------------------------
>
>                 Key: WTR-428
>                 URL: http://jira.openqa.org/browse/WTR-428
>             Project: Watir
>          Issue Type: Bug
>          Components: FireWatir
>    Affects Versions: 1.6.5
>         Environment: Watir 1.6.5
> Ruby 1.8.6-p111
> Gem 1.3.6
> Windows 7
> Firefox 3.6
>            Reporter: Mark Faust
>
> I just installed Watir on a Windows 7 server.  Noticed that when using the Firefox browser that the URL string is always blank.  The problem seems confined to this one method, as title returns a correct value for any open window.  An example irb session follows...
> irb(main):014:0> ff.goto "http://yahoo.com"
> => #<FireWatir::Firefox:0xfa7d8e8 url="" title="Yahoo!">
> irb(main):015:0> ff.url
> => ""
> irb(main):016:0> ff.goto "http://www.google.com"
> => #<FireWatir::Firefox:0xfa7d8e8 url="" title="Google">
> irb(main):017:0> ff.url
> => ""
> irb(main):018:0> ff.goto "http://www.mlb.com"
> => #<FireWatir::Firefox:0xfa7d8e8 url="" title="The Official Site of Major League Baseball | MLB.com: Homepage">
> irb(main):019:0> ff.url
> => ""
> irb(main):020:0>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Thu May  6 00:36:32 2010
From: watirjira at gmail.com (Alister Scott (JIRA))
Date: Wed, 5 May 2010 23:36:32 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-238) .flash method
Message-ID: <11209301.122.1273120592490.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19627#action_19627 ] 

Alister Scott commented on WTR-238:
-----------------------------------

This would be useful for irb.

> .flash method
> -------------
>
>                 Key: WTR-238
>                 URL: http://jira.openqa.org/browse/WTR-238
>             Project: Watir
>          Issue Type: New Feature
>          Components: FireWatir
>    Affects Versions: 1.5.3, 1.5.4, 1.5.5, 1.5.6
>         Environment: Firewatir - MacOSX
>            Reporter: Sameh Abdelhamid
>             Fix For: Next
>
>
> .flash mehod does not work in Firewatir. Same code was tested in Watir (windows) and it works succesfully
> The objects I have found work when i use the .click method. Which proves the object is being identified correctly. The object does "flash" yellow, when it is being clicked. 
> For example if you navigate to the google page:
> @f ||= FireWatir::Firefox.new()
> @f.button(:name,'btnG').click
> (.click clicks the button and flashes yellow as it should
> and
> @f.button(:name,'btnG').flash 
> Does not work 
> Would be great if this feature was added 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jarmo.p at gmail.com  Thu May  6 07:09:57 2010
From: jarmo.p at gmail.com (Jarmo)
Date: Thu, 6 May 2010 14:09:57 +0300
Subject: [Wtr-development] [JIRA] Commented: (WTR-433) IE#text.include?
	method returning true for hidden text also
In-Reply-To: <l2zade75c5b1005052025lab966735lea53f70f13a90d43@mail.gmail.com>
References: <32383274.900.1271267377629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<n2iade75c5b1004300734kd9f3ddefydef2cc8b356447cc@mail.gmail.com> 
	<i2z2a379a301005021926w42f621a0ne7ceec1b222d9ecb@mail.gmail.com> 
	<g2jade75c5b1005030822h52d55e8fu338b93f854c476d@mail.gmail.com> 
	<g2vb7bf92f01005030847o1c4db377o108610e2b112d796@mail.gmail.com> 
	<i2uade75c5b1005031056w58a8a308uf9c0a972d46af530@mail.gmail.com> 
	<g2i2a379a301005041939pccf21db1h9eb0b656398f6ab5@mail.gmail.com> 
	<h2mf58506c41005051515i63c4991fr213fdf1fabe72224@mail.gmail.com> 
	<g2teae5f6f91005052007r668a9104ic0f748f8ca6f6a66@mail.gmail.com> 
	<l2zade75c5b1005052025lab966735lea53f70f13a90d43@mail.gmail.com>
Message-ID: <g2mb7bf92f01005060409jb02db696ja47ac7f4dabfec70@mail.gmail.com>

I agree with Jari in the sense that it would be best, if IE#text would
return only visible text. Also there shouldn't be any special method
like "visible_text". But yeah, usually if i want to test if some text
appears on the page then i also access an element, check that it is
visible and then assert it's text.

Jarmo

On Thu, May 6, 2010 at 6:25 AM, Bret Pettichord <bret at pettichord.com> wrote:
> After reading the discussion on stack-overflow, I was already thinking that
> Watir's text method should probably restrict itself to visible text as well.
> http://stackoverflow.com/questions/2733080/does-watirs-browser-text-include-count-text-inside-invisible-divs-if-so-how-t
>
> Jari, thanks for chiming in on this. Compatibility was another concern, and
> it seems also another argument for not including visible text in the string
> returned.
>
> Bret
>
> On Wed, May 5, 2010 at 10:07 PM, Jari Bakken <jari.bakken at gmail.com> wrote:
>>
>> On Thu, May 6, 2010 at 12:15 AM, Ethan <notethan at gmail.com> wrote:
>> > Having realized from this discussion that in some places in my
>> > application,
>> > I really ought to be checking for visible text, not just text, I went
>> > ahead
>> > and implemented this for vapir.
>>
>> I should add that neither Celerity nor watir-webdriver returns
>> non-visible text for Browser#text or Element#text. That decision is
>> made by the underlying libraries, and not really feasible to work
>> around.
>>
>> The Javascript algorithm used to get text in Firefox/Chrome is here:
>>
>>
>> ?http://code.google.com/p/selenium/source/browse/trunk/firefox/src/extension/components/utils.js#340
>>
>> I don't think this is a big deal - we've been running our tests on
>> both Watir and Celerity for ages without it being an issue. And a need
>> to do things a user wouldn't be able to in your browser tests is
>> usually a sign that it should be covered by tests in another part of
>> the stack instead.
>> _______________________________________________
>> 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
>

From zeljko.filipin at wa-research.ch  Thu May  6 08:48:32 2010
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Thu, 6 May 2010 14:48:32 +0200
Subject: [Wtr-development] Fwd: Donate to Watir
In-Reply-To: <x2pf81b1251004020329iad00eecr2df849a29df94914@mail.gmail.com>
References: <f81b1251003010351y1778ef30ma96a7c9c31d5c1cd@mail.gmail.com> 
	<x2pf81b1251004020329iad00eecr2df849a29df94914@mail.gmail.com>
Message-ID: <x2zf81b1251005060548iffbe8474p3ea7c196f1296e96@mail.gmail.com>

If you like the Watir project, you can make a donation. There is donate
button at http://watir.com/.

We have raised $570 this year. We will spend it on hosting and stuff like
that. We will not spend it on beer, no matter how much I would like that. :)

You can see list of donors and Bret's thank you note at
http://pledgie.com/campaigns/2982

?eljko
--
watir.com - community manager
pledgie.com/campaigns/2982 - donate to Watir
watirpodcast.com - host
testingpodcast.com - audio podcasts on software testing. all of them
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20100506/93d441e7/attachment.html>

From zeljko.filipin at wa-research.ch  Thu May  6 11:00:28 2010
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Thu, 6 May 2010 17:00:28 +0200
Subject: [Wtr-development] [wtr-general] Re: Fwd: [selenium-developers]
	Proposal for a Selenium StackExchange site
In-Reply-To: <7c7fdba1-1225-4e44-acfe-201743db1b74@z13g2000prh.googlegroups.com>
References: <745eb3ec-9fe7-4b21-bea9-72685fb15aed@h27g2000yqm.googlegroups.com>
	<l2mf81b1251004300318n493c608by5bf0b2fb099feadd@mail.gmail.com> 
	<cd7a8c9b-24d9-4480-b2dd-c55648675521@s13g2000prc.googlegroups.com> 
	<k2jf81b1251005030249saf3eb5b0m69b08f9e9291721b@mail.gmail.com> 
	<a18bf4ee-6dcf-432a-8e38-51e560228105@s13g2000prc.googlegroups.com> 
	<1694c099-bf60-4e0f-a011-681a2f013249@v12g2000prb.googlegroups.com> 
	<z2lf81b1251005030810z2dc548a9w955047c7a9a398fa@mail.gmail.com> 
	<7c7fdba1-1225-4e44-acfe-201743db1b74@z13g2000prh.googlegroups.com>
Message-ID: <w2sf81b1251005060800s4f175ffcs287ee9f1462200b0@mail.gmail.com>

On Mon, May 3, 2010 at 8:34 PM, George <george.sanders at gmail.com> wrote:
> I am interested in helping, although I'm still a little unclear about
> what I need to do.

George (and everybody else interested in helping),

For now, all you have to do is:

1) Read http://meta.stackexchange.com/questions/6056/proposal-for-watir-site(1
minute)
2) If you like the idea, create account at
http://meta.stackexchange.com/and vote the question up (1 minute)
3) If you do not like the idea, do nothing
4) If you really do not like the idea, create account at
http://meta.stackexchange.com/ and vote the question down (1 minute)

If you have any comments or questions, comment here or there or at
http://twitter.com/#search?q=%23watirflow

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

From abaird at bairdsnet.net  Thu May  6 12:48:30 2010
From: abaird at bairdsnet.net (Alan Baird)
Date: Thu, 6 May 2010 11:48:30 -0500
Subject: [Wtr-development] [JIRA] Commented: (WTR-433) IE#text.include?
	method returning true for hidden text also
In-Reply-To: <g2mb7bf92f01005060409jb02db696ja47ac7f4dabfec70@mail.gmail.com>
References: <32383274.900.1271267377629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<i2z2a379a301005021926w42f621a0ne7ceec1b222d9ecb@mail.gmail.com>
	<g2jade75c5b1005030822h52d55e8fu338b93f854c476d@mail.gmail.com>
	<g2vb7bf92f01005030847o1c4db377o108610e2b112d796@mail.gmail.com>
	<i2uade75c5b1005031056w58a8a308uf9c0a972d46af530@mail.gmail.com>
	<g2i2a379a301005041939pccf21db1h9eb0b656398f6ab5@mail.gmail.com>
	<h2mf58506c41005051515i63c4991fr213fdf1fabe72224@mail.gmail.com>
	<g2teae5f6f91005052007r668a9104ic0f748f8ca6f6a66@mail.gmail.com>
	<l2zade75c5b1005052025lab966735lea53f70f13a90d43@mail.gmail.com>
	<g2mb7bf92f01005060409jb02db696ja47ac7f4dabfec70@mail.gmail.com>
Message-ID: <w2y2a379a301005060948l7f0ff37bi2c0d8c76ba3be6f8@mail.gmail.com>

Ok, so I have a bit of egg on my face.  Just yesterday I ran across
some of my code where I used IE#text on a page checker.  The reason I
did this was because I don't really know what the page is going to
look like and it's a really simple error message.  However, even that
specific instance would be pretty easily dealt with by iterating
through the elements on the page and concatenating a big string.

-AB

From watirjira at gmail.com  Thu May  6 17:50:31 2010
From: watirjira at gmail.com (Bret Pettichord (JIRA))
Date: Thu, 6 May 2010 16:50:31 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Updated: (WTR-428) Firefox URL string is
	always blank
In-Reply-To: <21390032.468.1269375217002.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <15457419.134.1273182631197.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


     [ http://jira.openqa.org/browse/WTR-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bret Pettichord updated WTR-428:
--------------------------------

    Priority: Major  (was: Minor)

Fix would be most welcome, as this is incompatible with IE-Watir.

> Firefox URL string is always blank
> ----------------------------------
>
>                 Key: WTR-428
>                 URL: http://jira.openqa.org/browse/WTR-428
>             Project: Watir
>          Issue Type: Bug
>          Components: FireWatir
>    Affects Versions: 1.6.5
>         Environment: Watir 1.6.5
> Ruby 1.8.6-p111
> Gem 1.3.6
> Windows 7
> Firefox 3.6
>            Reporter: Mark Faust
>            Priority: Major
>
> I just installed Watir on a Windows 7 server.  Noticed that when using the Firefox browser that the URL string is always blank.  The problem seems confined to this one method, as title returns a correct value for any open window.  An example irb session follows...
> irb(main):014:0> ff.goto "http://yahoo.com"
> => #<FireWatir::Firefox:0xfa7d8e8 url="" title="Yahoo!">
> irb(main):015:0> ff.url
> => ""
> irb(main):016:0> ff.goto "http://www.google.com"
> => #<FireWatir::Firefox:0xfa7d8e8 url="" title="Google">
> irb(main):017:0> ff.url
> => ""
> irb(main):018:0> ff.goto "http://www.mlb.com"
> => #<FireWatir::Firefox:0xfa7d8e8 url="" title="The Official Site of Major League Baseball | MLB.com: Homepage">
> irb(main):019:0> ff.url
> => ""
> irb(main):020:0>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From bret at pettichord.com  Thu May  6 17:50:53 2010
From: bret at pettichord.com (Bret Pettichord)
Date: Thu, 6 May 2010 16:50:53 -0500
Subject: [Wtr-development] [wtr-general] Re: Fwd: [selenium-developers]
	Proposal for a Selenium StackExchange site
In-Reply-To: <w2sf81b1251005060800s4f175ffcs287ee9f1462200b0@mail.gmail.com>
References: <745eb3ec-9fe7-4b21-bea9-72685fb15aed@h27g2000yqm.googlegroups.com>
	<l2mf81b1251004300318n493c608by5bf0b2fb099feadd@mail.gmail.com>
	<cd7a8c9b-24d9-4480-b2dd-c55648675521@s13g2000prc.googlegroups.com>
	<k2jf81b1251005030249saf3eb5b0m69b08f9e9291721b@mail.gmail.com>
	<a18bf4ee-6dcf-432a-8e38-51e560228105@s13g2000prc.googlegroups.com>
	<1694c099-bf60-4e0f-a011-681a2f013249@v12g2000prb.googlegroups.com>
	<z2lf81b1251005030810z2dc548a9w955047c7a9a398fa@mail.gmail.com>
	<7c7fdba1-1225-4e44-acfe-201743db1b74@z13g2000prh.googlegroups.com>
	<w2sf81b1251005060800s4f175ffcs287ee9f1462200b0@mail.gmail.com>
Message-ID: <n2made75c5b1005061450we53b4284y9249f4ba21820ddf@mail.gmail.com>

I upvoted the proposal.

On Thu, May 6, 2010 at 10:00 AM, ?eljko Filipin <
zeljko.filipin at wa-research.ch> wrote:

> On Mon, May 3, 2010 at 8:34 PM, George <george.sanders at gmail.com> wrote:
> > I am interested in helping, although I'm still a little unclear about
> > what I need to do.
>
> George (and everybody else interested in helping),
>
> For now, all you have to do is:
>
> 1) Read
> http://meta.stackexchange.com/questions/6056/proposal-for-watir-site (1
> minute)
> 2) If you like the idea, create account at http://meta.stackexchange.com/and vote the question up (1 minute)
> 3) If you do not like the idea, do nothing
> 4) If you really do not like the idea, create account at
> http://meta.stackexchange.com/ and vote the question down (1 minute)
>
> If you have any comments or questions, comment here or there or at
> http://twitter.com/#search?q=%23watirflow
>
> ?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/20100506/11ab693b/attachment.html>

From zeljko.filipin at wa-research.ch  Thu May  6 17:57:56 2010
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Thu, 6 May 2010 23:57:56 +0200
Subject: [Wtr-development] [wtr-general] Re: Fwd: [selenium-developers]
	Proposal for a Selenium StackExchange site
In-Reply-To: <n2made75c5b1005061450we53b4284y9249f4ba21820ddf@mail.gmail.com>
References: <745eb3ec-9fe7-4b21-bea9-72685fb15aed@h27g2000yqm.googlegroups.com>
	<l2mf81b1251004300318n493c608by5bf0b2fb099feadd@mail.gmail.com> 
	<cd7a8c9b-24d9-4480-b2dd-c55648675521@s13g2000prc.googlegroups.com> 
	<k2jf81b1251005030249saf3eb5b0m69b08f9e9291721b@mail.gmail.com> 
	<a18bf4ee-6dcf-432a-8e38-51e560228105@s13g2000prc.googlegroups.com> 
	<1694c099-bf60-4e0f-a011-681a2f013249@v12g2000prb.googlegroups.com> 
	<z2lf81b1251005030810z2dc548a9w955047c7a9a398fa@mail.gmail.com> 
	<7c7fdba1-1225-4e44-acfe-201743db1b74@z13g2000prh.googlegroups.com> 
	<w2sf81b1251005060800s4f175ffcs287ee9f1462200b0@mail.gmail.com> 
	<n2made75c5b1005061450we53b4284y9249f4ba21820ddf@mail.gmail.com>
Message-ID: <z2gf81b1251005061457q6039096co923717273714276c@mail.gmail.com>

On Thu, May 6, 2010 at 11:50 PM, Bret Pettichord <bret at pettichord.com>
wrote:
> I upvoted the proposal.

Thanks. The proposal got 5 upvotes so far, so at least 6 of us are
interested in it.

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

From jarmo.p at gmail.com  Fri May  7 11:42:51 2010
From: jarmo.p at gmail.com (Jarmo)
Date: Fri, 7 May 2010 18:42:51 +0300
Subject: [Wtr-development] 3 proposals regarding Watir 2.0
Message-ID: <r2vb7bf92f01005070842w97a5993dn3202cb5568b96ede@mail.gmail.com>

Hello.

I have exchanged some e-mails with Jari recently about Watir WebDriver
(and Watir 2.0) and have come up with at least
three proposals, which would change the current API a little by making
tests better, thus I would bring them up in here also.

Feel free to express yourself :)

1) Default locator for all elements should be :index => 0

I'm finding myself very often clicking links on the table with random
identifiers. Consider a table like this:

<table id="table_id">
 <tr>
   <td>Something</td>
   <td><a href="#" onclick=delete(somerandomid)>Delete</a></td>
 </tr>
 <tr>
   <td>Something else</td>
   <td><a href="#" onclick=delete(somerandomid)>Delete</a></td>
 </tr>
</table>

Now, if i want to delete "Something else", then
currently i have to do something like this:

product = b.table(:id => "table_id").rows.find {|row| row.text ==
"Something else"}
product.link(:index => 1).click

With my proposal it would be like this:
product = b.table(:id => "table_id").rows.find {|row| row.text ==
"Something else"}
product.link.click

And with the possibility (from Google Wave about Watir 2.0 by Jari) to
use locators for collections:
product = b.table(:id => "table_id").trs(:text => "Something else").first
product.link.click



2) Selenium has a lot of different ways of locating elements. This is
not what i would like to see in
Watir and as i understand then most of you in here also think like
that. But i think that it would
be great if ALL elements would accept one String as an identifier,
which would be used to locate an
element first by id and then by name. No exceptions - it would be the
same for every element.

For example:
b.text_field("blah").set "my text" # would search text fields with ID
and if not found then by NAME and if still not found
                                   # would raise exception

I'm asking this because most of the time i have to use ID or NAME (in
that order) to locate
elements, which means that my tests are full of method(:id => 'xxxx')
and method(:name => 'sfdas'). Would be great if there would be
less code.

Wouldn't it make sense to add this functionality then?



3) Allow only hash syntax for element locators (+ String in proposal
#2). So, text_field(:id, 'sfdsa') is not allowed anymore. Why?
Well, it's again to have less syntax for finding elements and you can
use only hash when using multiple identifiers anyway.
Especially newcomers might get confused if at one place they read
text_field(:id => 'sfdsa') and other place comma
is used.

I think that since it is going to be a major release then some
backwards incompatibilities are allowed, no?


Jarmo

From notethan at gmail.com  Fri May  7 12:18:55 2010
From: notethan at gmail.com (Ethan)
Date: Fri, 7 May 2010 12:18:55 -0400
Subject: [Wtr-development] 3 proposals regarding Watir 2.0
In-Reply-To: <r2vb7bf92f01005070842w97a5993dn3202cb5568b96ede@mail.gmail.com>
References: <r2vb7bf92f01005070842w97a5993dn3202cb5568b96ede@mail.gmail.com>
Message-ID: <j2tf58506c41005070918m2140c9a5k401c1d4df5e17da5@mail.gmail.com>

On Fri, May 7, 2010 at 11:42, Jarmo <jarmo.p at gmail.com> wrote:

> 1) Default locator for all elements should be :index => 0
>

Concur. I too am annoyed by having to type a bunch when I just want the
first element of the specified type. Same for IE.attach; if no :title or
:url specifier is given, it should just attach to the first IE it finds.

And with the possibility (from Google Wave about Watir 2.0 by Jari) to
> use locators for collections:
> product = b.table(:id => "table_id").trs(:text => "Something else").first
> product.link.click
>

Definitely. This is a priority for me in my fork.


> 2) Selenium has a lot of different ways of locating elements. This is
> not what i would like to see in
> Watir and as i understand then most of you in here also think like
> that. But i think that it would
> be great if ALL elements would accept one String as an identifier,
> which would be used to locate an
> element first by id and then by name. No exceptions - it would be the
> same for every element.
>

I'd limit this to just id. conflating it with name introduces significant
ambiguity, since the name of one element can be the same as the id of
another. Do we go with the first id that's found, or the first name, or the
first of either sort? The last seems most consistent with how watir operates
/ returns things, but incurs a significant performance hit because you can't
use getElementById or getElementByName, because you won't know which element
comes first.

3) Allow only hash syntax for element locators (+ String in proposal
> #2). So, text_field(:id, 'sfdsa') is not allowed anymore. Why?
> Well, it's again to have less syntax for finding elements and you can
> use only hash when using multiple identifiers anyway.
> Especially newcomers might get confused if at one place they read
> text_field(:id => 'sfdsa') and other place comma
> is used.
>

Sounds good to me.
Not mentioned here, but in the same vein, the third argument (value) passed
to radio/checkbox should definitely be dropped.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20100507/211f8eaa/attachment.html>

From bret at pettichord.com  Fri May  7 12:28:24 2010
From: bret at pettichord.com (Bret Pettichord)
Date: Fri, 7 May 2010 11:28:24 -0500
Subject: [Wtr-development] 3 proposals regarding Watir 2.0
In-Reply-To: <r2vb7bf92f01005070842w97a5993dn3202cb5568b96ede@mail.gmail.com>
References: <r2vb7bf92f01005070842w97a5993dn3202cb5568b96ede@mail.gmail.com>
Message-ID: <v2hade75c5b1005070928if72427cds1721d714bfa5ce11@mail.gmail.com>

I've previously proposed both #1 and #3. In theory people like  the idea.
But mostly people hate the idea of the compatibility problems these would
introduce. And looking at all the tests we have here at Convio, I see the
same problem. If these kinds of changes were made in Watir 2.0, we would not
be able to use it.

Bret

On Fri, May 7, 2010 at 10:42 AM, Jarmo <jarmo.p at gmail.com> wrote:

> Hello.
>
> I have exchanged some e-mails with Jari recently about Watir WebDriver
> (and Watir 2.0) and have come up with at least
> three proposals, which would change the current API a little by making
> tests better, thus I would bring them up in here also.
>
> Feel free to express yourself :)
>
> 1) Default locator for all elements should be :index => 0
>
> I'm finding myself very often clicking links on the table with random
> identifiers. Consider a table like this:
>
> <table id="table_id">
>  <tr>
>   <td>Something</td>
>   <td><a href="#" onclick=delete(somerandomid)>Delete</a></td>
>  </tr>
>  <tr>
>   <td>Something else</td>
>   <td><a href="#" onclick=delete(somerandomid)>Delete</a></td>
>  </tr>
> </table>
>
> Now, if i want to delete "Something else", then
> currently i have to do something like this:
>
> product = b.table(:id => "table_id").rows.find {|row| row.text ==
> "Something else"}
> product.link(:index => 1).click
>
> With my proposal it would be like this:
> product = b.table(:id => "table_id").rows.find {|row| row.text ==
> "Something else"}
> product.link.click
>
> And with the possibility (from Google Wave about Watir 2.0 by Jari) to
> use locators for collections:
> product = b.table(:id => "table_id").trs(:text => "Something else").first
> product.link.click
>
>
>
> 2) Selenium has a lot of different ways of locating elements. This is
> not what i would like to see in
> Watir and as i understand then most of you in here also think like
> that. But i think that it would
> be great if ALL elements would accept one String as an identifier,
> which would be used to locate an
> element first by id and then by name. No exceptions - it would be the
> same for every element.
>
> For example:
> b.text_field("blah").set "my text" # would search text fields with ID
> and if not found then by NAME and if still not found
>                                   # would raise exception
>
> I'm asking this because most of the time i have to use ID or NAME (in
> that order) to locate
> elements, which means that my tests are full of method(:id => 'xxxx')
> and method(:name => 'sfdas'). Would be great if there would be
> less code.
>
> Wouldn't it make sense to add this functionality then?
>
>
>
> 3) Allow only hash syntax for element locators (+ String in proposal
> #2). So, text_field(:id, 'sfdsa') is not allowed anymore. Why?
> Well, it's again to have less syntax for finding elements and you can
> use only hash when using multiple identifiers anyway.
> Especially newcomers might get confused if at one place they read
> text_field(:id => 'sfdsa') and other place comma
> is used.
>
> I think that since it is going to be a major release then some
> backwards incompatibilities are allowed, no?
>
>
> Jarmo
> _______________________________________________
> 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/20100507/19c0f766/attachment.html>

From jarmo.p at gmail.com  Fri May  7 13:04:01 2010
From: jarmo.p at gmail.com (Jarmo)
Date: Fri, 7 May 2010 20:04:01 +0300
Subject: [Wtr-development] 3 proposals regarding Watir 2.0
In-Reply-To: <v2hade75c5b1005070928if72427cds1721d714bfa5ce11@mail.gmail.com>
References: <r2vb7bf92f01005070842w97a5993dn3202cb5568b96ede@mail.gmail.com> 
	<v2hade75c5b1005070928if72427cds1721d714bfa5ce11@mail.gmail.com>
Message-ID: <q2gb7bf92f01005071004t42621717z2d87f46d03a1f91d@mail.gmail.com>

Hello, Bret.

How do you see that #1 will cause compatibility problems? Do you mean
0-based indexing? This is done anyway already with Watir WebDriver
(http://wiki.github.com/jarib/watir-webdriver/comparison-with-watir-1x)
and i think that it is a really good thing. If you have that in mind,
then default :index => won't bring any backwards compatibilities.

About #3 you might be correct, but i think that this is a one
technical debt which would be great to get rid of before it's too
late. Having backwards incompatibilities in mind i recommend to just
deprecate it in Watir 2.0 and remove completely in some newer version.
What if we issue Kernel.warn for every comma usage and show some
message when executing b.text_field(:id, "blah"):

***
Using 2 parameters as a element locator is DEPRECATED! Use at
c:/projects/project/spec/some_file_spec.rb:45 this instead:
text_field(:id => "blah")
***

It might get messy at first if comma notation is used a lot, but it
gives a possibility to clean things up and even to create some script
which would analyze this log and do it for you automatically. What do
you think about this or similar idea?

When i think about technical debts, then it's not reasonable to have
it forever due to the reason of not wanting to create backwards
incompatibilities.

Jarmo

On Fri, May 7, 2010 at 7:28 PM, Bret Pettichord <bret at pettichord.com> wrote:
> I've previously proposed both #1 and #3. In theory people like? the idea.
> But mostly people hate the idea of the compatibility problems these would
> introduce. And looking at all the tests we have here at Convio, I see the
> same problem. If these kinds of changes were made in Watir 2.0, we would not
> be able to use it.
>
> Bret
>
> On Fri, May 7, 2010 at 10:42 AM, Jarmo <jarmo.p at gmail.com> wrote:
>>
>> Hello.
>>
>> I have exchanged some e-mails with Jari recently about Watir WebDriver
>> (and Watir 2.0) and have come up with at least
>> three proposals, which would change the current API a little by making
>> tests better, thus I would bring them up in here also.
>>
>> Feel free to express yourself :)
>>
>> 1) Default locator for all elements should be :index => 0
>>
>> I'm finding myself very often clicking links on the table with random
>> identifiers. Consider a table like this:
>>
>> <table id="table_id">
>> ?<tr>
>> ? <td>Something</td>
>> ? <td><a href="#" onclick=delete(somerandomid)>Delete</a></td>
>> ?</tr>
>> ?<tr>
>> ? <td>Something else</td>
>> ? <td><a href="#" onclick=delete(somerandomid)>Delete</a></td>
>> ?</tr>
>> </table>
>>
>> Now, if i want to delete "Something else", then
>> currently i have to do something like this:
>>
>> product = b.table(:id => "table_id").rows.find {|row| row.text ==
>> "Something else"}
>> product.link(:index => 1).click
>>
>> With my proposal it would be like this:
>> product = b.table(:id => "table_id").rows.find {|row| row.text ==
>> "Something else"}
>> product.link.click
>>
>> And with the possibility (from Google Wave about Watir 2.0 by Jari) to
>> use locators for collections:
>> product = b.table(:id => "table_id").trs(:text => "Something else").first
>> product.link.click
>>
>>
>>
>> 2) Selenium has a lot of different ways of locating elements. This is
>> not what i would like to see in
>> Watir and as i understand then most of you in here also think like
>> that. But i think that it would
>> be great if ALL elements would accept one String as an identifier,
>> which would be used to locate an
>> element first by id and then by name. No exceptions - it would be the
>> same for every element.
>>
>> For example:
>> b.text_field("blah").set "my text" # would search text fields with ID
>> and if not found then by NAME and if still not found
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? # would raise exception
>>
>> I'm asking this because most of the time i have to use ID or NAME (in
>> that order) to locate
>> elements, which means that my tests are full of method(:id => 'xxxx')
>> and method(:name => 'sfdas'). Would be great if there would be
>> less code.
>>
>> Wouldn't it make sense to add this functionality then?
>>
>>
>>
>> 3) Allow only hash syntax for element locators (+ String in proposal
>> #2). So, text_field(:id, 'sfdsa') is not allowed anymore. Why?
>> Well, it's again to have less syntax for finding elements and you can
>> use only hash when using multiple identifiers anyway.
>> Especially newcomers might get confused if at one place they read
>> text_field(:id => 'sfdsa') and other place comma
>> is used.
>>
>> I think that since it is going to be a major release then some
>> backwards incompatibilities are allowed, no?
>>
>>
>> Jarmo
>> _______________________________________________
>> 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
>

From jarmo.p at gmail.com  Fri May  7 13:07:23 2010
From: jarmo.p at gmail.com (Jarmo)
Date: Fri, 7 May 2010 20:07:23 +0300
Subject: [Wtr-development] 3 proposals regarding Watir 2.0
In-Reply-To: <j2tf58506c41005070918m2140c9a5k401c1d4df5e17da5@mail.gmail.com>
References: <r2vb7bf92f01005070842w97a5993dn3202cb5568b96ede@mail.gmail.com> 
	<j2tf58506c41005070918m2140c9a5k401c1d4df5e17da5@mail.gmail.com>
Message-ID: <z2kb7bf92f01005071007yaa43461eq3e7d925095dae709@mail.gmail.com>

On Fri, May 7, 2010 at 7:18 PM, Ethan <notethan at gmail.com> wrote:
> On Fri, May 7, 2010 at 11:42, Jarmo <jarmo.p at gmail.com> wrote:
>>
>> 1) Default locator for all elements should be :index => 0
>
> Concur. I too am annoyed by having to type a bunch when I just want the
> first element of the specified type. Same for IE.attach; if no :title or
> :url specifier is given, it should just attach to the first IE it finds.
+ 1



>>
>> And with the possibility (from Google Wave about Watir 2.0 by Jari) to
>> use locators for collections:
>> product = b.table(:id => "table_id").trs(:text => "Something else").first
>> product.link.click
>
> Definitely. This is a priority for me in my fork.
This is already done in Watir WebDriver.



>
>>
>> 2) Selenium has a lot of different ways of locating elements...
>
> I'd limit this to just id. conflating it with name introduces significant
> ambiguity, since the name of one element can be the same as the id of
> another. Do we go with the first id that's found, or the first name, or the
> first of either sort? The last seems most consistent with how watir operates
> / returns things, but incurs a significant performance hit because you can't
> use getElementById or getElementByName, because you won't know which element
> comes first.
I totally agree with you. Limit it to id since it should be unique
within the page thus needing no special handling :)



>>
>> 3) Allow only hash syntax for element locators...
>
> Sounds good to me.
> Not mentioned here, but in the same vein, the third argument (value) passed
> to radio/checkbox should definitely be dropped.
It is also already done within Watir WebDriver.


Jarmo

From jari.bakken at gmail.com  Fri May  7 13:42:19 2010
From: jari.bakken at gmail.com (Jari Bakken)
Date: Fri, 7 May 2010 19:42:19 +0200
Subject: [Wtr-development] 3 proposals regarding Watir 2.0
In-Reply-To: <z2kb7bf92f01005071007yaa43461eq3e7d925095dae709@mail.gmail.com>
References: <r2vb7bf92f01005070842w97a5993dn3202cb5568b96ede@mail.gmail.com>
	<j2tf58506c41005070918m2140c9a5k401c1d4df5e17da5@mail.gmail.com>
	<z2kb7bf92f01005071007yaa43461eq3e7d925095dae709@mail.gmail.com>
Message-ID: <l2ieae5f6f91005071042m1dcc15dax2229d5d3ee665e40@mail.gmail.com>

Hi guys,

I like #1 as well. It has come up on Celerity's tracker before

  http://github.com/jarib/celerity/issues#issue/7

I don't think it will be a huge backwards compatibility issue since
the current behaviour is to raise an ArgumentError.

On Fri, May 7, 2010 at 7:04 PM, Jarmo <jarmo.p at gmail.com> wrote:
> How do you see that #1 will cause compatibility problems? Do you mean
> 0-based indexing? This is done anyway already with Watir WebDriver
> (http://wiki.github.com/jarib/watir-webdriver/comparison-with-watir-1x)
> and i think that it is a really good thing. If you have that in mind,
> then default :index => won't bring any backwards compatibilities.
>

Just to be clear: watir-webdriver implements 0-based indexing, but it
does not return the first element when calling an element method
without arguments


>
>>>
>>> And with the possibility (from Google Wave about Watir 2.0 by Jari) to
>>> use locators for collections:
>>> product = b.table(:id => "table_id").trs(:text => "Something else").first
>>> product.link.click
>>
>> Definitely. This is a priority for me in my fork.
> This is already done in Watir WebDriver.
>

No, watir-webdriver does not do this (yet). divs(:id => "foo") will
return all divs, not only those matching the argument. It's a bug.

I'm not a big fan of #2 - the default "hows" in 1.X were confusing
enough, and they're gone in watir-webdriver. Limiting it to id would
help somewhat, but I do like the selectors to be explicit. Another
argument is that migration will be easier if the single-argument
syntax raises an ArgumentError rather than an UnknownObjectException.

#3 was discussed in the "Watir Roadmap" wave, copied here:

>> Obsoleting non-hash syntax.
>> Nov 16, 2009
>>
>> Bret:
>> For example, I'm thinking that Watir 2.0 should only support hash syntax. Thus: browser.text_field(:id => 'name').set 'Grayson' will continue to work, but browser.text_field(:id, 'name').set 'Grayson' won't. I haven't made up my mind on this, and am eager for feedback, but I want to give you a picture, right now of the kind of disruptions I'm anticipating for Watir 2.0.
>> Nov 17, 2009
>>
>> Angrez at googlewave.com:
>> Any specific reason for going ahead with hash syntax? I am sure that it will break a lot of stuff
>> Nov 17, 2009
>>
>> Deniz:
>> I agree on this, I recall this discussion but there was no conclusion. I also vote for staying compatible with the old syntax, using only hash will break a lot of stuff and confuse a lot of people.
>> Nov 17, 2009
>>
>> Bret:
>> I can back off on this. Mainly, my thinking is that simplifying the api makes it easier to create implementations.
>>

I don't really have a strong opinion either way, but this change does
break backwards compatiblity for miniscule benefits. The
implementation argument is somewhat weak, since it's very easy to get
right:

  if args.size == 2
    args = { args.first => args.last }
  end

My vote is

#1: +1
#2: -1
#3: 0

Jari

PS. While we're on the topic; there are two other APIs that needs
discussion: tables and cookies. I'll bring them up in separate threads
when I've had time to create some sensible proposals.

From jarmo.p at gmail.com  Fri May  7 14:20:25 2010
From: jarmo.p at gmail.com (Jarmo)
Date: Fri, 7 May 2010 21:20:25 +0300
Subject: [Wtr-development] 3 proposals regarding Watir 2.0
In-Reply-To: <l2ieae5f6f91005071042m1dcc15dax2229d5d3ee665e40@mail.gmail.com>
References: <r2vb7bf92f01005070842w97a5993dn3202cb5568b96ede@mail.gmail.com> 
	<j2tf58506c41005070918m2140c9a5k401c1d4df5e17da5@mail.gmail.com> 
	<z2kb7bf92f01005071007yaa43461eq3e7d925095dae709@mail.gmail.com> 
	<l2ieae5f6f91005071042m1dcc15dax2229d5d3ee665e40@mail.gmail.com>
Message-ID: <g2qb7bf92f01005071120h1d50db8dw109edb1628d23d69@mail.gmail.com>

On Fri, May 7, 2010 at 8:42 PM, Jari Bakken <jari.bakken at gmail.com> wrote:
> Just to be clear: watir-webdriver implements 0-based indexing, but it
> does not return the first element when calling an element method
> without arguments

That's what i meant also.


>>> Definitely. This is a priority for me in my fork.
>> This is already done in Watir WebDriver.
>>
>
> No, watir-webdriver does not do this (yet). divs(:id => "foo") will
> return all divs, not only those matching the argument. It's a bug.
Sorry, i understood from the Google Wave that this feature already
exists as a side effect...


> I'm not a big fan of #2 - the default "hows" in 1.X were confusing
> enough, and they're gone in watir-webdriver. Limiting it to id would
> help somewhat, but I do like the selectors to be explicit.
As i understood then they were confusing because there were many
exceptional cases and different default how's to different elements.


> Another
> argument is that migration will be easier if the single-argument
> syntax raises an ArgumentError rather than an UnknownObjectException.
Agree with that one though.


>
> #3 was discussed in the "Watir Roadmap" wave, copied here:
>
>>> Obsoleting non-hash syntax.
>>> Nov 16, 2009
>>>
>>> Bret:
>>> For example, I'm thinking that Watir 2.0 should only support hash syntax. Thus: browser.text_field(:id => 'name').set 'Grayson' will continue to work, but browser.text_field(:id, 'name').set 'Grayson' won't. I haven't made up my mind on this, and am eager for feedback, but I want to give you a picture, right now of the kind of disruptions I'm anticipating for Watir 2.0.
>>> Nov 17, 2009
>>>
>>> Angrez at googlewave.com:
>>> Any specific reason for going ahead with hash syntax? I am sure that it will break a lot of stuff
>>> Nov 17, 2009
>>>
>>> Deniz:
>>> I agree on this, I recall this discussion but there was no conclusion. I also vote for staying compatible with the old syntax, using only hash will break a lot of stuff and confuse a lot of people.
>>> Nov 17, 2009
>>>
>>> Bret:
>>> I can back off on this. Mainly, my thinking is that simplifying the api makes it easier to create implementations.
Bret, what did you mean by that exactly?


> PS. While we're on the topic; there are two other APIs that needs
> discussion: tables and cookies. I'll bring them up in separate threads
> when I've had time to create some sensible proposals.

Same here regarding with one table bug and i'll write about it shortly.

From bret at pettichord.com  Fri May  7 19:00:04 2010
From: bret at pettichord.com (Bret Pettichord)
Date: Fri, 7 May 2010 18:00:04 -0500
Subject: [Wtr-development] 3 proposals regarding Watir 2.0
In-Reply-To: <q2gb7bf92f01005071004t42621717z2d87f46d03a1f91d@mail.gmail.com>
References: <r2vb7bf92f01005070842w97a5993dn3202cb5568b96ede@mail.gmail.com>
	<v2hade75c5b1005070928if72427cds1721d714bfa5ce11@mail.gmail.com>
	<q2gb7bf92f01005071004t42621717z2d87f46d03a1f91d@mail.gmail.com>
Message-ID: <s2pade75c5b1005071600oc340ff95p1ef4dd253641f684@mail.gmail.com>

On Fri, May 7, 2010 at 12:04 PM, Jarmo <jarmo.p at gmail.com> wrote:

> Hello, Bret.
>
> How do you see that #1 will cause compatibility problems? Do you mean
> 0-based indexing? This is done anyway already with Watir WebDriver
> (http://wiki.github.com/jarib/watir-webdriver/comparison-with-watir-1x)
> and i think that it is a really good thing. If you have that in mind,
> then default :index => won't bring any backwards compatibilities.
>

Yes, i'm sorry i didn't read your proposal very carefully. I was responding
to the idea of changing from a 1 to zero based indexing.

About #3 you might be correct, but i think that this is a one
> technical debt which would be great to get rid of before it's too
> late. Having backwards incompatibilities in mind i recommend to just
> deprecate it in Watir 2.0 and remove completely in some newer version.
> What if we issue Kernel.warn for every comma usage and show some
> message when executing b.text_field(:id, "blah"):
>
> ***
> Using 2 parameters as a element locator is DEPRECATED! Use at
> c:/projects/project/spec/some_file_spec.rb:45 this instead:
> text_field(:id => "blah")
> ***
>
> It might get messy at first if comma notation is used a lot, but it
> gives a possibility to clean things up and even to create some script
> which would analyze this log and do it for you automatically. What do
> you think about this or similar idea?
>

I think this makes sense.


> When i think about technical debts, then it's not reasonable to have
> it forever due to the reason of not wanting to create backwards
> incompatibilities.
>

I agree. Probably doing in two steps, where we give a warning in one
version, before removing/changing the feature in a future version is the way
to manage this.

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/20100507/65abecd5/attachment.html>

From bret at pettichord.com  Fri May  7 19:03:50 2010
From: bret at pettichord.com (Bret Pettichord)
Date: Fri, 7 May 2010 18:03:50 -0500
Subject: [Wtr-development] 3 proposals regarding Watir 2.0
In-Reply-To: <s2pade75c5b1005071600oc340ff95p1ef4dd253641f684@mail.gmail.com>
References: <r2vb7bf92f01005070842w97a5993dn3202cb5568b96ede@mail.gmail.com>
	<v2hade75c5b1005070928if72427cds1721d714bfa5ce11@mail.gmail.com>
	<q2gb7bf92f01005071004t42621717z2d87f46d03a1f91d@mail.gmail.com>
	<s2pade75c5b1005071600oc340ff95p1ef4dd253641f684@mail.gmail.com>
Message-ID: <p2kade75c5b1005071603m30eb9c1dwbfaf0e32a8b897b0@mail.gmail.com>

This thread is getting confusing, partly because three mostly unrelated
topics are being combined.

I think we need to move this to three separate threads.

Does it make sense to try and have these conversions in the comments to
three separate Jira tickets?

Bret

On Fri, May 7, 2010 at 6:00 PM, Bret Pettichord <bret at pettichord.com> wrote:

> On Fri, May 7, 2010 at 12:04 PM, Jarmo <jarmo.p at gmail.com> wrote:
>
>> Hello, Bret.
>>
>> How do you see that #1 will cause compatibility problems? Do you mean
>> 0-based indexing? This is done anyway already with Watir WebDriver
>> (http://wiki.github.com/jarib/watir-webdriver/comparison-with-watir-1x)
>> and i think that it is a really good thing. If you have that in mind,
>> then default :index => won't bring any backwards compatibilities.
>>
>
> Yes, i'm sorry i didn't read your proposal very carefully. I was responding
> to the idea of changing from a 1 to zero based indexing.
>
> About #3 you might be correct, but i think that this is a one
>> technical debt which would be great to get rid of before it's too
>> late. Having backwards incompatibilities in mind i recommend to just
>> deprecate it in Watir 2.0 and remove completely in some newer version.
>> What if we issue Kernel.warn for every comma usage and show some
>> message when executing b.text_field(:id, "blah"):
>>
>> ***
>> Using 2 parameters as a element locator is DEPRECATED! Use at
>> c:/projects/project/spec/some_file_spec.rb:45 this instead:
>> text_field(:id => "blah")
>> ***
>>
>> It might get messy at first if comma notation is used a lot, but it
>> gives a possibility to clean things up and even to create some script
>> which would analyze this log and do it for you automatically. What do
>> you think about this or similar idea?
>>
>
> I think this makes sense.
>
>
>> When i think about technical debts, then it's not reasonable to have
>> it forever due to the reason of not wanting to create backwards
>> incompatibilities.
>>
>
> I agree. Probably doing in two steps, where we give a warning in one
> version, before removing/changing the feature in a future version is the way
> to manage this.
>
> 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
>
>


-- 
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/20100507/4beee6fc/attachment-0001.html>

From watirjira at gmail.com  Fri May  7 19:30:31 2010
From: watirjira at gmail.com (Jarmo Pertman (JIRA))
Date: Fri, 7 May 2010 18:30:31 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Created: (WTR-435) Default locator for all
 elements should be :index => 0
Message-ID: <23000233.144.1273275031178.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>

Default locator for all elements should be :index => 0
------------------------------------------------------

                 Key: WTR-435
                 URL: http://jira.openqa.org/browse/WTR-435
             Project: Watir
          Issue Type: New Feature
          Components: Other
    Affects Versions: 2.0
         Environment: any
            Reporter: Jarmo Pertman


I'm finding myself very often clicking links on the table with random
identifiers. Consider a table like this:

<table id="table_id">
 <tr>
  <td>Something</td>
  <td><a href="#" onclick=delete(somerandomid)>Delete</a></td>
 </tr>
 <tr>
  <td>Something else</td>
  <td><a href="#" onclick=delete(somerandomid)>Delete</a></td>
 </tr>
</table>

Now, if i want to delete "Something else", then
currently i have to do something like this:

product = b.table(:id => "table_id").rows.find {|row| row.text ==
"Something else"}
product.link(:index => 1).click

With my proposal it would be like this:
product = b.table(:id => "table_id").rows.find {|row| row.text ==
"Something else"}
product.link.click

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Fri May  7 19:32:30 2010
From: watirjira at gmail.com (Jarmo Pertman (JIRA))
Date: Fri, 7 May 2010 18:32:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Assigned: (WTR-435) Default locator for
 all elements should be :index => 0
In-Reply-To: <23000233.144.1273275031178.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <25219583.146.1273275150473.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


     [ http://jira.openqa.org/browse/WTR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jarmo Pertman reassigned WTR-435:
---------------------------------

    Assignee: Jarmo Pertman

> Default locator for all elements should be :index => 0
> ------------------------------------------------------
>
>                 Key: WTR-435
>                 URL: http://jira.openqa.org/browse/WTR-435
>             Project: Watir
>          Issue Type: New Feature
>          Components: Other
>    Affects Versions: 2.0
>         Environment: any
>            Reporter: Jarmo Pertman
>            Assignee: Jarmo Pertman
>
> I'm finding myself very often clicking links on the table with random
> identifiers. Consider a table like this:
> <table id="table_id">
>  <tr>
>   <td>Something</td>
>   <td><a href="#" onclick=delete(somerandomid)>Delete</a></td>
>  </tr>
>  <tr>
>   <td>Something else</td>
>   <td><a href="#" onclick=delete(somerandomid)>Delete</a></td>
>  </tr>
> </table>
> Now, if i want to delete "Something else", then
> currently i have to do something like this:
> product = b.table(:id => "table_id").rows.find {|row| row.text ==
> "Something else"}
> product.link(:index => 1).click
> With my proposal it would be like this:
> product = b.table(:id => "table_id").rows.find {|row| row.text ==
> "Something else"}
> product.link.click

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Fri May  7 19:34:30 2010
From: watirjira at gmail.com (Jarmo Pertman (JIRA))
Date: Fri, 7 May 2010 18:34:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Assigned: (WTR-435) Default locator for
 all elements should be :index => 0
In-Reply-To: <23000233.144.1273275031178.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <22755875.148.1273275270454.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


     [ http://jira.openqa.org/browse/WTR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jarmo Pertman reassigned WTR-435:
---------------------------------

    Assignee:     (was: Jarmo Pertman)

> Default locator for all elements should be :index => 0
> ------------------------------------------------------
>
>                 Key: WTR-435
>                 URL: http://jira.openqa.org/browse/WTR-435
>             Project: Watir
>          Issue Type: New Feature
>          Components: Other
>    Affects Versions: 2.0
>         Environment: any
>            Reporter: Jarmo Pertman
>
> I'm finding myself very often clicking links on the table with random
> identifiers. Consider a table like this:
> <table id="table_id">
>  <tr>
>   <td>Something</td>
>   <td><a href="#" onclick=delete(somerandomid)>Delete</a></td>
>  </tr>
>  <tr>
>   <td>Something else</td>
>   <td><a href="#" onclick=delete(somerandomid)>Delete</a></td>
>  </tr>
> </table>
> Now, if i want to delete "Something else", then
> currently i have to do something like this:
> product = b.table(:id => "table_id").rows.find {|row| row.text ==
> "Something else"}
> product.link(:index => 1).click
> With my proposal it would be like this:
> product = b.table(:id => "table_id").rows.find {|row| row.text ==
> "Something else"}
> product.link.click

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Fri May  7 19:39:30 2010
From: watirjira at gmail.com (Jarmo Pertman (JIRA))
Date: Fri, 7 May 2010 18:39:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Created: (WTR-436) All Elements should
 allow String locator, which will be used as an :id
Message-ID: <2079608.150.1273275570443.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>

All Elements should allow String locator, which will be used as an :id
----------------------------------------------------------------------

                 Key: WTR-436
                 URL: http://jira.openqa.org/browse/WTR-436
             Project: Watir
          Issue Type: New Feature
          Components: Other
    Affects Versions: 2.0
         Environment: any
            Reporter: Jarmo Pertman


Selenium has a lot of different ways of locating elements. This is
not what i would like to see in
Watir and as i understand then most of you in here also think like
that. But i think that it would
be great if ALL elements would accept one String as an identifier,
which would be used to locate an
element by id. No exceptions - it would be the
same for every element.

For example:
b.text_field("blah").set "my text" # would search text fields with ID and if not found
# would raise an exception

Most of the time i'm finding myself to use ID to locate
elements, which means that my tests are full of method(:id => 'xxxx').
Would be great if there would be less code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Fri May  7 19:44:30 2010
From: watirjira at gmail.com (Jarmo Pertman (JIRA))
Date: Fri, 7 May 2010 18:44:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Created: (WTR-437) Allow only hash
 locators when searching for elements
Message-ID: <12151033.152.1273275870441.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>

Allow only hash locators when searching for elements
----------------------------------------------------

                 Key: WTR-437
                 URL: http://jira.openqa.org/browse/WTR-437
             Project: Watir
          Issue Type: New Feature
          Components: Other
    Affects Versions: 2.0
         Environment: any
            Reporter: Jarmo Pertman


So, text_field(:id, 'sfdsa') is not allowed anymore. Why?
Well, it's again to have less syntax for finding elements and you can
use only hash when using multiple identifiers anyway.
Especially newcomers might get confused if at one place they read
text_field(:id => 'sfdsa') and other place comma
is used.

This is actually a 3 step improvement:
1) Remove all usages of comma in tutorials/documentation/examples at Watir websites and Watir code.
2) Having backwards incompatibilities in mind i recommend to just
deprecate it in Watir 2.0 and remove completely in some newer version.
What if we issue Kernel.warn for every comma usage and show some
message when executing b.text_field(:id, "blah"):

***
Using 2 parameters as a element locator is DEPRECATED! Use at
c:/projects/project/spec/some_file_spec.rb:45 this instead:
text_field(:id => "blah")
***

It might get messy at first if comma notation is used a lot, but it
gives a possibility to clean things up and even to create some script
which would analyze this log and do it for you automatically.

3) Remove support for comma syntax completely in some newer version

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jarmo.p at gmail.com  Fri May  7 19:44:23 2010
From: jarmo.p at gmail.com (Jarmo)
Date: Sat, 8 May 2010 02:44:23 +0300
Subject: [Wtr-development] 3 proposals regarding Watir 2.0
In-Reply-To: <p2kade75c5b1005071603m30eb9c1dwbfaf0e32a8b897b0@mail.gmail.com>
References: <r2vb7bf92f01005070842w97a5993dn3202cb5568b96ede@mail.gmail.com> 
	<v2hade75c5b1005070928if72427cds1721d714bfa5ce11@mail.gmail.com> 
	<q2gb7bf92f01005071004t42621717z2d87f46d03a1f91d@mail.gmail.com> 
	<s2pade75c5b1005071600oc340ff95p1ef4dd253641f684@mail.gmail.com> 
	<p2kade75c5b1005071603m30eb9c1dwbfaf0e32a8b897b0@mail.gmail.com>
Message-ID: <y2vb7bf92f01005071644p7884ae57j6aec61283b222c40@mail.gmail.com>

Done. Hopefully you all got e-mails from JIRA :)

Modified proposal #2 to work with ID only.

Please go and add your comments there.

Jarmo

On Sat, May 8, 2010 at 2:03 AM, Bret Pettichord <bret at pettichord.com> wrote:
> This thread is getting confusing, partly because three mostly unrelated
> topics are being combined.
>
> I think we need to move this to three separate threads.
>
> Does it make sense to try and have these conversions in the comments to
> three separate Jira tickets?
>
> Bret
>
> On Fri, May 7, 2010 at 6:00 PM, Bret Pettichord <bret at pettichord.com> wrote:
>>
>> On Fri, May 7, 2010 at 12:04 PM, Jarmo <jarmo.p at gmail.com> wrote:
>>>
>>> Hello, Bret.
>>>
>>> How do you see that #1 will cause compatibility problems? Do you mean
>>> 0-based indexing? This is done anyway already with Watir WebDriver
>>> (http://wiki.github.com/jarib/watir-webdriver/comparison-with-watir-1x)
>>> and i think that it is a really good thing. If you have that in mind,
>>> then default :index => won't bring any backwards compatibilities.
>>
>> Yes, i'm sorry i didn't read your proposal very carefully. I was
>> responding to the idea of changing from a 1 to zero based indexing.
>>
>>> About #3 you might be correct, but i think that this is a one
>>> technical debt which would be great to get rid of before it's too
>>> late. Having backwards incompatibilities in mind i recommend to just
>>> deprecate it in Watir 2.0 and remove completely in some newer version.
>>> What if we issue Kernel.warn for every comma usage and show some
>>> message when executing b.text_field(:id, "blah"):
>>>
>>> ***
>>> Using 2 parameters as a element locator is DEPRECATED! Use at
>>> c:/projects/project/spec/some_file_spec.rb:45 this instead:
>>> text_field(:id => "blah")
>>> ***
>>>
>>> It might get messy at first if comma notation is used a lot, but it
>>> gives a possibility to clean things up and even to create some script
>>> which would analyze this log and do it for you automatically. What do
>>> you think about this or similar idea?
>>
>> I think this makes sense.
>>
>>>
>>> When i think about technical debts, then it's not reasonable to have
>>> it forever due to the reason of not wanting to create backwards
>>> incompatibilities.
>>
>> I agree. Probably doing in two steps, where we give a warning in one
>> version, before removing/changing the feature in a future version is the way
>> to manage this.
>>
>> Bret
>> --
>> Bret Pettichord
>> Lead Developer, Watir, www.watir.com
>>
>> Blog, www.io.com/~wazmo/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
>

From jarmo.p at gmail.com  Fri May  7 19:56:47 2010
From: jarmo.p at gmail.com (Jarmo)
Date: Sat, 8 May 2010 02:56:47 +0300
Subject: [Wtr-development] bugfix for Watir::Table#to_a
Message-ID: <s2ob7bf92f01005071656w2dcda546rd79d8676a341da16@mail.gmail.com>

Hello again.

I noticed at one point that Watir::Table#to_a does return empty String
for TH tags so i digged into it and saw right away from the code why
it does that.

I fixed it and saw that there was a comment before the method:
# This method returns the table as a 2 dimensional array.
# Don't expect too much if there are nested tables, colspan etc.

So i got an idea and made it also work with nested tables by returning
multi-dimensional array and not just a 2 dimensional one if nested
tables are in use.

Also, i added max_depth parameter which by default will be 1, so it
would work exactly the same as it was before, except also returning
data for TH tags, which was definitely a bug.

My solution introduces also #to_a(max_depth=1) to Watir::TableRow,
which means that it is possible now to use:
row(:something => "something").to_a

This also works with nested tables. Actually only this works with
nested tables and Watir::Table#to_a just calls #to_a on every row and
then just adds all these arrays together
into one big array.

In short, my fixes/changes will do:
1) fix a bug for Watir::Table#to_a, which also breaks backwards
compatibility because TH contents will be returned now
2) add #to_a to Watir::TableRow
3) Support nested tables with max_depth parameter

I wanted to know before forking Watir, applying the patch+changes and
trying to create tests within Watir repo, if anyone is even interested
in these changes.

Also, as a sidenote, there has to be something changed with tables
API, because other methods won't work with nested tables correctly and
the question is of course, how would
be the correct behaviour :)

Jarmo

From watirjira at gmail.com  Sat May  8 06:39:30 2010
From: watirjira at gmail.com (Alister Scott (JIRA))
Date: Sat, 8 May 2010 05:39:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-428) Firefox URL string is
	always blank
In-Reply-To: <21390032.468.1269375217002.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <21962713.155.1273315170767.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19630#action_19630 ] 

Alister Scott commented on WTR-428:
-----------------------------------

I fixed this locally.

Changed line 445 of

C:\Ruby\lib\ruby\gems\1.8\gems\firewatir-1.6.5\lib\firewatir\firefox.rb

from

@window_url = js_eval "#{document_var}.location"

to

@window_url = js_eval "#{document_var}.URL"

Now to work out how to submit this as a patch.

> Firefox URL string is always blank
> ----------------------------------
>
>                 Key: WTR-428
>                 URL: http://jira.openqa.org/browse/WTR-428
>             Project: Watir
>          Issue Type: Bug
>          Components: FireWatir
>    Affects Versions: 1.6.5
>         Environment: Watir 1.6.5
> Ruby 1.8.6-p111
> Gem 1.3.6
> Windows 7
> Firefox 3.6
>            Reporter: Mark Faust
>            Priority: Major
>
> I just installed Watir on a Windows 7 server.  Noticed that when using the Firefox browser that the URL string is always blank.  The problem seems confined to this one method, as title returns a correct value for any open window.  An example irb session follows...
> irb(main):014:0> ff.goto "http://yahoo.com"
> => #<FireWatir::Firefox:0xfa7d8e8 url="" title="Yahoo!">
> irb(main):015:0> ff.url
> => ""
> irb(main):016:0> ff.goto "http://www.google.com"
> => #<FireWatir::Firefox:0xfa7d8e8 url="" title="Google">
> irb(main):017:0> ff.url
> => ""
> irb(main):018:0> ff.goto "http://www.mlb.com"
> => #<FireWatir::Firefox:0xfa7d8e8 url="" title="The Official Site of Major League Baseball | MLB.com: Homepage">
> irb(main):019:0> ff.url
> => ""
> irb(main):020:0>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Sat May  8 13:45:30 2010
From: watirjira at gmail.com (Bret Pettichord (JIRA))
Date: Sat, 8 May 2010 12:45:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-437) Allow only hash
 locators when searching for elements
In-Reply-To: <12151033.152.1273275870441.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <167108.158.1273340730617.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19631#action_19631 ] 

Bret Pettichord commented on WTR-437:
-------------------------------------

I like this idea, and have proposed it myself in the past. I think it would take some time to push people to use the new syntax.

I particularly like the idea of us pushing the "Watir Way" (like the Ruby Way) which means that although there is more than one way to do it, there is a way that is considered to be the best idiom. In my personal practice, for some time now, I have focused on using the hash syntax exclusively.

I also agree that this would be a three step process, as outlined.

I suppose the first step is to really get agreement within the community that we want to exclusively promote the hash syntax and therefore update all our documentation to feature it. I think it is worth seeking agreement on that even if we can't get agreement on all three steps.



> Allow only hash locators when searching for elements
> ----------------------------------------------------
>
>                 Key: WTR-437
>                 URL: http://jira.openqa.org/browse/WTR-437
>             Project: Watir
>          Issue Type: New Feature
>          Components: Other
>    Affects Versions: 2.0
>         Environment: any
>            Reporter: Jarmo Pertman
>
> So, text_field(:id, 'sfdsa') is not allowed anymore. Why?
> Well, it's again to have less syntax for finding elements and you can
> use only hash when using multiple identifiers anyway.
> Especially newcomers might get confused if at one place they read
> text_field(:id => 'sfdsa') and other place comma
> is used.
> This is actually a 3 step improvement:
> 1) Remove all usages of comma in tutorials/documentation/examples at Watir websites and Watir code.
> 2) Having backwards incompatibilities in mind i recommend to just
> deprecate it in Watir 2.0 and remove completely in some newer version.
> What if we issue Kernel.warn for every comma usage and show some
> message when executing b.text_field(:id, "blah"):
> ***
> Using 2 parameters as a element locator is DEPRECATED! Use at
> c:/projects/project/spec/some_file_spec.rb:45 this instead:
> text_field(:id => "blah")
> ***
> It might get messy at first if comma notation is used a lot, but it
> gives a possibility to clean things up and even to create some script
> which would analyze this log and do it for you automatically.
> 3) Remove support for comma syntax completely in some newer version

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Sat May  8 13:57:30 2010
From: watirjira at gmail.com (Bret Pettichord (JIRA))
Date: Sat, 8 May 2010 12:57:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Updated: (WTR-435) Default locator for all
 elements should be :index => 1
In-Reply-To: <23000233.144.1273275031178.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <31462723.160.1273341450609.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


     [ http://jira.openqa.org/browse/WTR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bret Pettichord updated WTR-435:
--------------------------------

    Summary: Default locator for all elements should be :index => 1  (was: Default locator for all elements should be :index => 0)

Changing the title, since we haven't yet changed the index origin in Watir.

> Default locator for all elements should be :index => 1
> ------------------------------------------------------
>
>                 Key: WTR-435
>                 URL: http://jira.openqa.org/browse/WTR-435
>             Project: Watir
>          Issue Type: New Feature
>          Components: Other
>    Affects Versions: 2.0
>         Environment: any
>            Reporter: Jarmo Pertman
>
> I'm finding myself very often clicking links on the table with random
> identifiers. Consider a table like this:
> <table id="table_id">
>  <tr>
>   <td>Something</td>
>   <td><a href="#" onclick=delete(somerandomid)>Delete</a></td>
>  </tr>
>  <tr>
>   <td>Something else</td>
>   <td><a href="#" onclick=delete(somerandomid)>Delete</a></td>
>  </tr>
> </table>
> Now, if i want to delete "Something else", then
> currently i have to do something like this:
> product = b.table(:id => "table_id").rows.find {|row| row.text ==
> "Something else"}
> product.link(:index => 1).click
> With my proposal it would be like this:
> product = b.table(:id => "table_id").rows.find {|row| row.text ==
> "Something else"}
> product.link.click

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Sat May  8 14:01:30 2010
From: watirjira at gmail.com (Bret Pettichord (JIRA))
Date: Sat, 8 May 2010 13:01:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-436) All Elements should
 allow String locator, which will be used as an :id
In-Reply-To: <2079608.150.1273275570443.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <433833.162.1273341690489.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19633#action_19633 ] 

Bret Pettichord commented on WTR-436:
-------------------------------------

Watir 1.0 had different defaulting rules. E.g. ie.button("OK") meant ie.button(:value => "OK"). This behavior is no longer documented, but is still implemented. We would need to deprecate it before we could switch to a different defaulting rule.

Not sure if this change is worth the trouble and potential confusion. Love to hear other thoughts on this. I also think this proposal is somewhat in conflict with the other proposal that we only support hash syntax (which i like better). If we are going to require hashes, then let's always require hashes.

> All Elements should allow String locator, which will be used as an :id
> ----------------------------------------------------------------------
>
>                 Key: WTR-436
>                 URL: http://jira.openqa.org/browse/WTR-436
>             Project: Watir
>          Issue Type: New Feature
>          Components: Other
>    Affects Versions: 2.0
>         Environment: any
>            Reporter: Jarmo Pertman
>
> Selenium has a lot of different ways of locating elements. This is
> not what i would like to see in
> Watir and as i understand then most of you in here also think like
> that. But i think that it would
> be great if ALL elements would accept one String as an identifier,
> which would be used to locate an
> element by id. No exceptions - it would be the
> same for every element.
> For example:
> b.text_field("blah").set "my text" # would search text fields with ID and if not found
> # would raise an exception
> Most of the time i'm finding myself to use ID to locate
> elements, which means that my tests are full of method(:id => 'xxxx').
> Would be great if there would be less code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Sat May  8 14:12:30 2010
From: watirjira at gmail.com (Jari Bakken (JIRA))
Date: Sat, 8 May 2010 13:12:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-436) All Elements should
 allow String locator, which will be used as an :id
In-Reply-To: <2079608.150.1273275570443.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <3904938.164.1273342350472.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19634#action_19634 ] 

Jari Bakken commented on WTR-436:
---------------------------------

I agree with Bret that this isn't worth the trouble. I'm not sure how much use the single argument variant has seen up to know, since it's not well documented and hard to understand. The alternatives boil down to:

1. deprecate the single argument API entirely
2. make the behavior consistent across elements, only locating by id
3. leave it as is

I prefer #1, that's also how it's implemented in watir-webdriver at the moment.


> All Elements should allow String locator, which will be used as an :id
> ----------------------------------------------------------------------
>
>                 Key: WTR-436
>                 URL: http://jira.openqa.org/browse/WTR-436
>             Project: Watir
>          Issue Type: New Feature
>          Components: Other
>    Affects Versions: 2.0
>         Environment: any
>            Reporter: Jarmo Pertman
>
> Selenium has a lot of different ways of locating elements. This is
> not what i would like to see in
> Watir and as i understand then most of you in here also think like
> that. But i think that it would
> be great if ALL elements would accept one String as an identifier,
> which would be used to locate an
> element by id. No exceptions - it would be the
> same for every element.
> For example:
> b.text_field("blah").set "my text" # would search text fields with ID and if not found
> # would raise an exception
> Most of the time i'm finding myself to use ID to locate
> elements, which means that my tests are full of method(:id => 'xxxx').
> Would be great if there would be less code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Sat May  8 14:14:30 2010
From: watirjira at gmail.com (Jari Bakken (JIRA))
Date: Sat, 8 May 2010 13:14:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-436) All Elements should
 allow String locator, which will be used as an :id
In-Reply-To: <2079608.150.1273275570443.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <9743593.166.1273342470452.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19635#action_19635 ] 

Jari Bakken commented on WTR-436:
---------------------------------

Another argument against:

People who rely on the current behavior would start seeing UnknownObjectExceptions with the proposed change (#2), as opposed to ArgumentErrors with #1. 

> All Elements should allow String locator, which will be used as an :id
> ----------------------------------------------------------------------
>
>                 Key: WTR-436
>                 URL: http://jira.openqa.org/browse/WTR-436
>             Project: Watir
>          Issue Type: New Feature
>          Components: Other
>    Affects Versions: 2.0
>         Environment: any
>            Reporter: Jarmo Pertman
>
> Selenium has a lot of different ways of locating elements. This is
> not what i would like to see in
> Watir and as i understand then most of you in here also think like
> that. But i think that it would
> be great if ALL elements would accept one String as an identifier,
> which would be used to locate an
> element by id. No exceptions - it would be the
> same for every element.
> For example:
> b.text_field("blah").set "my text" # would search text fields with ID and if not found
> # would raise an exception
> Most of the time i'm finding myself to use ID to locate
> elements, which means that my tests are full of method(:id => 'xxxx').
> Would be great if there would be less code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Sat May  8 14:18:30 2010
From: watirjira at gmail.com (Jari Bakken (JIRA))
Date: Sat, 8 May 2010 13:18:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-435) Default locator for
 all elements should be :index => 1
In-Reply-To: <23000233.144.1273275031178.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <29757590.168.1273342710459.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19636#action_19636 ] 

Jari Bakken commented on WTR-435:
---------------------------------

I like this change. It's already been suggested in the Celerity tracker [1] and does won't break existing code (since the current behavior is to raise an ArgumentError if no arguments are given)

[1] http://github.com/jarib/celerity/issues#issue/7



> Default locator for all elements should be :index => 1
> ------------------------------------------------------
>
>                 Key: WTR-435
>                 URL: http://jira.openqa.org/browse/WTR-435
>             Project: Watir
>          Issue Type: New Feature
>          Components: Other
>    Affects Versions: 2.0
>         Environment: any
>            Reporter: Jarmo Pertman
>
> I'm finding myself very often clicking links on the table with random
> identifiers. Consider a table like this:
> <table id="table_id">
>  <tr>
>   <td>Something</td>
>   <td><a href="#" onclick=delete(somerandomid)>Delete</a></td>
>  </tr>
>  <tr>
>   <td>Something else</td>
>   <td><a href="#" onclick=delete(somerandomid)>Delete</a></td>
>  </tr>
> </table>
> Now, if i want to delete "Something else", then
> currently i have to do something like this:
> product = b.table(:id => "table_id").rows.find {|row| row.text ==
> "Something else"}
> product.link(:index => 1).click
> With my proposal it would be like this:
> product = b.table(:id => "table_id").rows.find {|row| row.text ==
> "Something else"}
> product.link.click

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Sat May  8 14:28:30 2010
From: watirjira at gmail.com (Jari Bakken (JIRA))
Date: Sat, 8 May 2010 13:28:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-437) Allow only hash
 locators when searching for elements
In-Reply-To: <12151033.152.1273275870441.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <24316083.170.1273343310457.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19637#action_19637 ] 

Jari Bakken commented on WTR-437:
---------------------------------

I'm neutral. Angrez and Deniz argued against it in the Watir Roadmap wave, and it does seem to introduce backward incompatibility for little gain.

There's a slight performance penalty for creating a new hash with every call [1], although this is likely negligible in the big picture (Celerity and watir-webdriver at least will convert the two-argument syntax to a hash immediately anyway)

[1] http://gist.github.com/379998

watir-webdriver currently supports both ways of calling the locator methods.

> Allow only hash locators when searching for elements
> ----------------------------------------------------
>
>                 Key: WTR-437
>                 URL: http://jira.openqa.org/browse/WTR-437
>             Project: Watir
>          Issue Type: New Feature
>          Components: Other
>    Affects Versions: 2.0
>         Environment: any
>            Reporter: Jarmo Pertman
>
> So, text_field(:id, 'sfdsa') is not allowed anymore. Why?
> Well, it's again to have less syntax for finding elements and you can
> use only hash when using multiple identifiers anyway.
> Especially newcomers might get confused if at one place they read
> text_field(:id => 'sfdsa') and other place comma
> is used.
> This is actually a 3 step improvement:
> 1) Remove all usages of comma in tutorials/documentation/examples at Watir websites and Watir code.
> 2) Having backwards incompatibilities in mind i recommend to just
> deprecate it in Watir 2.0 and remove completely in some newer version.
> What if we issue Kernel.warn for every comma usage and show some
> message when executing b.text_field(:id, "blah"):
> ***
> Using 2 parameters as a element locator is DEPRECATED! Use at
> c:/projects/project/spec/some_file_spec.rb:45 this instead:
> text_field(:id => "blah")
> ***
> It might get messy at first if comma notation is used a lot, but it
> gives a possibility to clean things up and even to create some script
> which would analyze this log and do it for you automatically.
> 3) Remove support for comma syntax completely in some newer version

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Sat May  8 14:32:30 2010
From: watirjira at gmail.com (Bret Pettichord (JIRA))
Date: Sat, 8 May 2010 13:32:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-428) Firefox URL string is
	always blank
In-Reply-To: <21390032.468.1269375217002.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <31501491.172.1273343550563.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19638#action_19638 ] 

Bret Pettichord commented on WTR-428:
-------------------------------------

This is enough information. Thanks for the fix.

> Firefox URL string is always blank
> ----------------------------------
>
>                 Key: WTR-428
>                 URL: http://jira.openqa.org/browse/WTR-428
>             Project: Watir
>          Issue Type: Bug
>          Components: FireWatir
>    Affects Versions: 1.6.5
>         Environment: Watir 1.6.5
> Ruby 1.8.6-p111
> Gem 1.3.6
> Windows 7
> Firefox 3.6
>            Reporter: Mark Faust
>            Priority: Major
>
> I just installed Watir on a Windows 7 server.  Noticed that when using the Firefox browser that the URL string is always blank.  The problem seems confined to this one method, as title returns a correct value for any open window.  An example irb session follows...
> irb(main):014:0> ff.goto "http://yahoo.com"
> => #<FireWatir::Firefox:0xfa7d8e8 url="" title="Yahoo!">
> irb(main):015:0> ff.url
> => ""
> irb(main):016:0> ff.goto "http://www.google.com"
> => #<FireWatir::Firefox:0xfa7d8e8 url="" title="Google">
> irb(main):017:0> ff.url
> => ""
> irb(main):018:0> ff.goto "http://www.mlb.com"
> => #<FireWatir::Firefox:0xfa7d8e8 url="" title="The Official Site of Major League Baseball | MLB.com: Homepage">
> irb(main):019:0> ff.url
> => ""
> irb(main):020:0>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Sat May  8 15:03:30 2010
From: watirjira at gmail.com (Ethan (JIRA))
Date: Sat, 8 May 2010 14:03:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-437) Allow only hash
 locators when searching for elements
In-Reply-To: <12151033.152.1273275870441.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <17195781.174.1273345410923.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19639#action_19639 ] 

Ethan commented on WTR-437:
---------------------------

How will this play with selectors that aren't attributes (ie, xpath, ole_object)? 

Hash notation is nice for attributes, where you can select by as many as you want, but doesn't really make sense for things where 'how' is not a dom attribute. there's only one value, so the hash could only have one entry, which seems like a silly thing for a hash. having two arguments makes sense there. 


> Allow only hash locators when searching for elements
> ----------------------------------------------------
>
>                 Key: WTR-437
>                 URL: http://jira.openqa.org/browse/WTR-437
>             Project: Watir
>          Issue Type: New Feature
>          Components: Other
>    Affects Versions: 2.0
>         Environment: any
>            Reporter: Jarmo Pertman
>
> So, text_field(:id, 'sfdsa') is not allowed anymore. Why?
> Well, it's again to have less syntax for finding elements and you can
> use only hash when using multiple identifiers anyway.
> Especially newcomers might get confused if at one place they read
> text_field(:id => 'sfdsa') and other place comma
> is used.
> This is actually a 3 step improvement:
> 1) Remove all usages of comma in tutorials/documentation/examples at Watir websites and Watir code.
> 2) Having backwards incompatibilities in mind i recommend to just
> deprecate it in Watir 2.0 and remove completely in some newer version.
> What if we issue Kernel.warn for every comma usage and show some
> message when executing b.text_field(:id, "blah"):
> ***
> Using 2 parameters as a element locator is DEPRECATED! Use at
> c:/projects/project/spec/some_file_spec.rb:45 this instead:
> text_field(:id => "blah")
> ***
> It might get messy at first if comma notation is used a lot, but it
> gives a possibility to clean things up and even to create some script
> which would analyze this log and do it for you automatically.
> 3) Remove support for comma syntax completely in some newer version

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Sat May  8 15:24:30 2010
From: watirjira at gmail.com (Bret Pettichord (JIRA))
Date: Sat, 8 May 2010 14:24:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Resolved: (WTR-428) Firefox URL string is
	always blank
In-Reply-To: <21390032.468.1269375217002.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <15639998.176.1273346670523.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


     [ http://jira.openqa.org/browse/WTR-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bret Pettichord resolved WTR-428.
---------------------------------

       Resolution: Fixed
    Fix Version/s: Next

Fix committed http://github.com/bret/watir/commit/ff86c3fa6b1852075443ca32ef6937d1d8aa0f80

> Firefox URL string is always blank
> ----------------------------------
>
>                 Key: WTR-428
>                 URL: http://jira.openqa.org/browse/WTR-428
>             Project: Watir
>          Issue Type: Bug
>          Components: FireWatir
>    Affects Versions: 1.6.5
>         Environment: Watir 1.6.5
> Ruby 1.8.6-p111
> Gem 1.3.6
> Windows 7
> Firefox 3.6
>            Reporter: Mark Faust
>            Priority: Major
>             Fix For: Next
>
>
> I just installed Watir on a Windows 7 server.  Noticed that when using the Firefox browser that the URL string is always blank.  The problem seems confined to this one method, as title returns a correct value for any open window.  An example irb session follows...
> irb(main):014:0> ff.goto "http://yahoo.com"
> => #<FireWatir::Firefox:0xfa7d8e8 url="" title="Yahoo!">
> irb(main):015:0> ff.url
> => ""
> irb(main):016:0> ff.goto "http://www.google.com"
> => #<FireWatir::Firefox:0xfa7d8e8 url="" title="Google">
> irb(main):017:0> ff.url
> => ""
> irb(main):018:0> ff.goto "http://www.mlb.com"
> => #<FireWatir::Firefox:0xfa7d8e8 url="" title="The Official Site of Major League Baseball | MLB.com: Homepage">
> irb(main):019:0> ff.url
> => ""
> irb(main):020:0>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Sat May  8 15:26:30 2010
From: watirjira at gmail.com (Jarmo Pertman (JIRA))
Date: Sat, 8 May 2010 14:26:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-437) Allow only hash
 locators when searching for elements
In-Reply-To: <12151033.152.1273275870441.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <17428000.178.1273346790468.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19641#action_19641 ] 

Jarmo Pertman commented on WTR-437:
-----------------------------------

Bret: Thanks for the Ruby Way analogy :)


Jari: Don't even try to bring here this performance "penalty". I wouldn't even consider this as a penalty if the numbers are like they are plus majority of the time with testing web applications is spent for waiting after application under test. If we're going to bring this kind of reasons in here then why not try to implement Watir in pure C to gain performance boost (kiddin')? :)

This improvement is not done in 1 step due to this backwards incompatibility problem. I still think that it would be more clear if there would be only one syntax and no dealing with arrays.

def text_field(args*)
  args = {args.first => args.last} if args.size == 2
end

would become

def text_field(args)
end

It's not a huge improvement, but think of it as a growing technical debt - you'll have to support both of these syntaxes for every new part you code and everyone else codes. Even if you're going to extend Watir's classes then you'd have to put these if-statements everywhere. It just looks bad.


Ethan: How often do you think that regular users will use ie or ole_object? I'm quite sure that it happens almost never. And if you're talking about xpath, then:

1) I wouldn't recommend it to use at all because it just looks ugly and makes your tests look uglier. Just add an 'id' to the html element or make the developers to add those.

2) If you make these xpath-s to be very specific, then they will probably break if html changes.

3) If you make these xpath-s to be too loose, then they will probably break if html changes.

4) Searching by xpath is slower.

5) If you think of it then xpath is an element attribute as a location of the element. It's as much of an attribute as a 'text' is for example. I don't see any problems with using xpath attribute with hash.

To be honest, i have never in my Watir 3+ years used xpath for locating element.

Jarmo

> Allow only hash locators when searching for elements
> ----------------------------------------------------
>
>                 Key: WTR-437
>                 URL: http://jira.openqa.org/browse/WTR-437
>             Project: Watir
>          Issue Type: New Feature
>          Components: Other
>    Affects Versions: 2.0
>         Environment: any
>            Reporter: Jarmo Pertman
>
> So, text_field(:id, 'sfdsa') is not allowed anymore. Why?
> Well, it's again to have less syntax for finding elements and you can
> use only hash when using multiple identifiers anyway.
> Especially newcomers might get confused if at one place they read
> text_field(:id => 'sfdsa') and other place comma
> is used.
> This is actually a 3 step improvement:
> 1) Remove all usages of comma in tutorials/documentation/examples at Watir websites and Watir code.
> 2) Having backwards incompatibilities in mind i recommend to just
> deprecate it in Watir 2.0 and remove completely in some newer version.
> What if we issue Kernel.warn for every comma usage and show some
> message when executing b.text_field(:id, "blah"):
> ***
> Using 2 parameters as a element locator is DEPRECATED! Use at
> c:/projects/project/spec/some_file_spec.rb:45 this instead:
> text_field(:id => "blah")
> ***
> It might get messy at first if comma notation is used a lot, but it
> gives a possibility to clean things up and even to create some script
> which would analyze this log and do it for you automatically.
> 3) Remove support for comma syntax completely in some newer version

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Sat May  8 16:03:31 2010
From: watirjira at gmail.com (Ethan (JIRA))
Date: Sat, 8 May 2010 15:03:31 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-437) Allow only hash
 locators when searching for elements
In-Reply-To: <12151033.152.1273275870441.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <14737504.180.1273349011495.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19642#action_19642 ] 

Ethan commented on WTR-437:
---------------------------

Performance comparison of hash to arguments is negligible and no issue, agreed. 

Regarding "support both of these syntaxes for every new part you code and everyone else codes" - no, not at all. This only needs to be dealt with in one place, between container methods taking their args and initializing a new Element object from them. There's no reason this should affect more than one piece of code in one place. 

No, users won't be likely to use ole_obect. xpath is used with some frequency though. I don't buy into your recommendation not to use it, but either of our opinions on it aren't relevant here: watir does support it, and it will need to be in the API in some way that makes sense. It can't be combined with other stuff, so a hash makes less sense than two-argument how/what. 

> Allow only hash locators when searching for elements
> ----------------------------------------------------
>
>                 Key: WTR-437
>                 URL: http://jira.openqa.org/browse/WTR-437
>             Project: Watir
>          Issue Type: New Feature
>          Components: Other
>    Affects Versions: 2.0
>         Environment: any
>            Reporter: Jarmo Pertman
>
> So, text_field(:id, 'sfdsa') is not allowed anymore. Why?
> Well, it's again to have less syntax for finding elements and you can
> use only hash when using multiple identifiers anyway.
> Especially newcomers might get confused if at one place they read
> text_field(:id => 'sfdsa') and other place comma
> is used.
> This is actually a 3 step improvement:
> 1) Remove all usages of comma in tutorials/documentation/examples at Watir websites and Watir code.
> 2) Having backwards incompatibilities in mind i recommend to just
> deprecate it in Watir 2.0 and remove completely in some newer version.
> What if we issue Kernel.warn for every comma usage and show some
> message when executing b.text_field(:id, "blah"):
> ***
> Using 2 parameters as a element locator is DEPRECATED! Use at
> c:/projects/project/spec/some_file_spec.rb:45 this instead:
> text_field(:id => "blah")
> ***
> It might get messy at first if comma notation is used a lot, but it
> gives a possibility to clean things up and even to create some script
> which would analyze this log and do it for you automatically.
> 3) Remove support for comma syntax completely in some newer version

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Sat May  8 17:36:30 2010
From: watirjira at gmail.com (Jari Bakken (JIRA))
Date: Sat, 8 May 2010 16:36:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-437) Allow only hash
 locators when searching for elements
In-Reply-To: <12151033.152.1273275870441.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <17072284.182.1273354590663.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19643#action_19643 ] 

Jari Bakken commented on WTR-437:
---------------------------------

Ethan is right - implementation complexity is not an argument in this case since the conversion only needs to happen once (in Element's constructor).



> Allow only hash locators when searching for elements
> ----------------------------------------------------
>
>                 Key: WTR-437
>                 URL: http://jira.openqa.org/browse/WTR-437
>             Project: Watir
>          Issue Type: New Feature
>          Components: Other
>    Affects Versions: 2.0
>         Environment: any
>            Reporter: Jarmo Pertman
>
> So, text_field(:id, 'sfdsa') is not allowed anymore. Why?
> Well, it's again to have less syntax for finding elements and you can
> use only hash when using multiple identifiers anyway.
> Especially newcomers might get confused if at one place they read
> text_field(:id => 'sfdsa') and other place comma
> is used.
> This is actually a 3 step improvement:
> 1) Remove all usages of comma in tutorials/documentation/examples at Watir websites and Watir code.
> 2) Having backwards incompatibilities in mind i recommend to just
> deprecate it in Watir 2.0 and remove completely in some newer version.
> What if we issue Kernel.warn for every comma usage and show some
> message when executing b.text_field(:id, "blah"):
> ***
> Using 2 parameters as a element locator is DEPRECATED! Use at
> c:/projects/project/spec/some_file_spec.rb:45 this instead:
> text_field(:id => "blah")
> ***
> It might get messy at first if comma notation is used a lot, but it
> gives a possibility to clean things up and even to create some script
> which would analyze this log and do it for you automatically.
> 3) Remove support for comma syntax completely in some newer version

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Sun May  9 15:32:31 2010
From: watirjira at gmail.com (Bret Pettichord (JIRA))
Date: Sun, 9 May 2010 14:32:31 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Created: (WTR-438) Deprecate single
	argument api
Message-ID: <25589846.186.1273433551165.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>

Deprecate single argument api
-----------------------------

                 Key: WTR-438
                 URL: http://jira.openqa.org/browse/WTR-438
             Project: Watir
          Issue Type: New Feature
          Components: HTML Controls
    Affects Versions: 1.6.5
         Environment: windows
            Reporter: Bret Pettichord


Currently there are several cases where things like browser.button("OK") work. In this case it is interpreted as browser.button(:value, "OK"). The proposal is deprecate this API, which is already little known and not documented much. In other words, we would discourage this API in our docs and issue warnings when people used it. However, it would still work, at least for IE.

Some day we might also decide to remove support entirely (in the interests of simplicity and compatibility), but first we would need to deprecate it.

This issue came up in the discussion of 
http://jira.openqa.org/browse/WTR-436

If there is interest in this, next step would be to come up with a comprehensive list, which I can do.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Sun May  9 15:39:30 2010
From: watirjira at gmail.com (Jari Bakken (JIRA))
Date: Sun, 9 May 2010 14:39:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-438) Deprecate single
	argument api
In-Reply-To: <25589846.186.1273433551165.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <15394115.188.1273433970494.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19644#action_19644 ] 

Jari Bakken commented on WTR-438:
---------------------------------

Here's the list from Celerity - it should match Watir's unless we made any mistakes in creating it 

$ jruby -I lib -r celerity -e 'ObjectSpace.each_object(Class) { |klass| p [klass, klass::DEFAULT_HOW] if klass < Celerity::Element }'
[Celerity::Form, :name]
[Celerity::Meta, :id]
[Celerity::InputElement, nil]
[Celerity::SelectList, :name]
[Celerity::FileField, :name]
[Celerity::TextField, :name]
[Celerity::Button, :value]
[Celerity::RadioCheckCommon, :name]
[Celerity::Hidden, :name]
[Celerity::Radio, :name]
[Celerity::CheckBox, :name]
[Celerity::TableElement, :id]
[Celerity::TableHeader, :id]
[Celerity::TableFooter, :id]
[Celerity::TableBody, :id]
[Celerity::Table, :id]
[Celerity::NonControlElement, :id]
[Celerity::P, :id]
[Celerity::Ol, :id]
[Celerity::Map, :id]
[Celerity::Li, :id]
[Celerity::Ul, :id]
[Celerity::Div, :id]
[Celerity::Strong, :id]
[Celerity::Dl, :id]
[Celerity::Span, :id]
[Celerity::Area, :id]
[Celerity::Pre, :id]
[Celerity::Dd, :id]
[Celerity::H1, :id]
[Celerity::H2, :id]
[Celerity::Dt, :id]
[Celerity::Em, :id]
[Celerity::H5, :id]
[Celerity::H6, :id]
[Celerity::H3, :id]
[Celerity::H4, :id]
[Celerity::Option, :text]
[Celerity::TableRow, :id]
[Celerity::TableCell, :id]
[Celerity::Th, :id]
[Celerity::Link, :href]
[Celerity::Label, :text]
[Celerity::Image, :src]
[Celerity::Frame, :name]



> Deprecate single argument api
> -----------------------------
>
>                 Key: WTR-438
>                 URL: http://jira.openqa.org/browse/WTR-438
>             Project: Watir
>          Issue Type: New Feature
>          Components: HTML Controls
>    Affects Versions: 1.6.5
>         Environment: windows
>            Reporter: Bret Pettichord
>
> Currently there are several cases where things like browser.button("OK") work. In this case it is interpreted as browser.button(:value, "OK"). The proposal is deprecate this API, which is already little known and not documented much. In other words, we would discourage this API in our docs and issue warnings when people used it. However, it would still work, at least for IE.
> Some day we might also decide to remove support entirely (in the interests of simplicity and compatibility), but first we would need to deprecate it.
> This issue came up in the discussion of 
> http://jira.openqa.org/browse/WTR-436
> If there is interest in this, next step would be to come up with a comprehensive list, which I can do.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Tue May 11 07:48:30 2010
From: watirjira at gmail.com (Marc Betts (JIRA))
Date: Tue, 11 May 2010 06:48:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Created: (WTR-439) error using attach
	method with => syntax
Message-ID: <2798750.201.1273578510734.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>

error using attach method with => syntax
----------------------------------------

                 Key: WTR-439
                 URL: http://jira.openqa.org/browse/WTR-439
             Project: Watir
          Issue Type: Bug
          Components: Window Attachment
    Affects Versions: 1.6.5
         Environment: Windows XP, IE8
            Reporter: Marc Betts


browser.attach(:title=>"title") returns the following error:

ArgumentError: wrong number of arguments (1 for 2)

This works fine using browser.attach(:title, "title")

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Tue May 11 13:23:30 2010
From: watirjira at gmail.com (Bret Pettichord (JIRA))
Date: Tue, 11 May 2010 12:23:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-439) error using attach
 method with => syntax
In-Reply-To: <2798750.201.1273578510734.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <31123119.204.1273598610755.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19646#action_19646 ] 

Bret Pettichord commented on WTR-439:
-------------------------------------

Yes, we should fix this.

> error using attach method with => syntax
> ----------------------------------------
>
>                 Key: WTR-439
>                 URL: http://jira.openqa.org/browse/WTR-439
>             Project: Watir
>          Issue Type: Bug
>          Components: Window Attachment
>    Affects Versions: 1.6.5
>         Environment: Windows XP, IE8
>            Reporter: Marc Betts
>
> browser.attach(:title=>"title") returns the following error:
> ArgumentError: wrong number of arguments (1 for 2)
> This works fine using browser.attach(:title, "title")

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From zeljko.filipin at wa-research.ch  Thu May 13 05:09:05 2010
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Thu, 13 May 2010 11:09:05 +0200
Subject: [Wtr-development] Watir Platforms
In-Reply-To: <y2gf81b1251004290325hee8f07d5l183dce8ecc1bdfb7@mail.gmail.com>
References: <u2pf81b1251004120450x48b93318j1320b65125cd7073@mail.gmail.com> 
	<x2wf81b1251004290319xa0980968u5e75d642467d0eb7@mail.gmail.com> 
	<y2gf81b1251004290325hee8f07d5l183dce8ecc1bdfb7@mail.gmail.com>
Message-ID: <AANLkTild8BWli3KdWS7gQKXI51Oa-3s9FgCs8PIjKQiP@mail.gmail.com>

 chromewatir gem is yanked:

http://help.rubygems.org/discussions/questions/21-delete-chromewatir-gem
http://rubygems.org/gems/chromewatir

It is still available for download for the people that really need it, but
it is deleted from gem index, so it can not be installed with "gem install
chromewatir". Since it is broken for months, and installation was the only
thing that worked, I guess nobody will complain.

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

From JXu6 at StateStreet.com  Thu May 13 05:18:43 2010
From: JXu6 at StateStreet.com (Xu, Jian)
Date: Thu, 13 May 2010 05:18:43 -0400
Subject: [Wtr-development] attach embedded  browser to watir
Message-ID: <D1F0EAF9A051C3418A438177125816BB0F7C25B9@GDCPW1082.corp.statestr.com>

Hi all:
I want to let watir attach embedded browser, and control it. I have
search on google and  
read some reference. It seems someone has solved this problem. 
But I can't let it work yet. I can't understand all those details. 
My problem is as following: 
  In an Eclipse RCP program, I use SWT OLE to create a browser. 
  ------Java Code 
                OleFrame frame = new OleFrame(parent, SWT.NONE); 
                OleClientSite client = new 
OleClientSite(frame,SWT.NONE,"Shell.Explorer.2"); 
                client.doVerb(OLE.OLEIVERB_SHOW); 
                OleAutomation oa = new OleAutomation(client); 
                Variant str = new Variant("www.google.com
<http://www.google.com/url?sa=D&q=www.google.com&usg=AFQjCNEbQmySw5dEh-H
1m6n4CjHWihV2vg> "); 
                oa.invoke(104, new Variant[]{str}); 
  Then I want to use watir to control it. 
My question is: 
  1.That browser instant is a embedded browser here? 
  2.Could watir be used as I has described? 
Actually I find threads such as
http://rubyforge.org/pipermail/wtr-development/2009-August/001174.html
<http://www.google.com/url?sa=D&q=http://rubyforge.org/pipermail/wtr-dev
elopment/2009-August/001174.html&usg=AFQjCNHznViri05J6Qnp_-AKxTMzx5GK9A>

I understand that may be solved already. 
and here
https://gist.github.com/224981/9d643daf08c9558235bf0e3ce65ed4ca0019f97f
<http://www.google.com/url?sa=D&q=https://gist.github.com/224981/9d643da
f08c9558235bf0e3ce65ed4ca0019f97f&usg=AFQjCNGwEosV4b9cHLlk8kYsT2-GpMdPMA
>  
post the source code. 
But it can't work for me... It's a pity since I know little about 
win32ole.etc...
Any suggestion is every appreciated!! 


Regards, 
Jian Xu(James)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20100513/81f4f86c/attachment.html>

From watirjira at gmail.com  Thu May 13 05:43:30 2010
From: watirjira at gmail.com (Katherine (JIRA))
Date: Thu, 13 May 2010 04:43:30 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-281) add exists? for frames
Message-ID: <28603382.235.1273743810727.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


    [ http://jira.openqa.org/browse/WTR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19650#action_19650 ] 

Katherine commented on WTR-281:
-------------------------------

Is there a reason why this defect is marked as trivial? Is there a workaround? Please let me know.

It blocks me. I need to check if an operation is completed, and so check for a presence of a button: 
frame1.frame2.button1.extsts?
Although if the operation is not completed, frame2 doesn't exists and "frame1.frame2.button1.extsts?" returns an exception (not false or nil). So the only way is to check if frame2 exists first. But there is not such method.

> add exists? for frames
> ----------------------
>
>                 Key: WTR-281
>                 URL: http://jira.openqa.org/browse/WTR-281
>             Project: Watir
>          Issue Type: New Feature
>          Components: Frame
>    Affects Versions: 1.6.2
>            Reporter: Charley Baker
>            Priority: Trivial
>             Fix For: Soon
>
>
> This has come up in the mailing list a few times. Monkey patch from MHwee: 
> Michael Hwee
>  to watir-general
> 	
> frame does not support exists?().
> However, you can *monkey-patch* as followed.
> module Watir
>   class Frame
>     alias_method :_locate, :locate
>     def locate
>       begin
>         return _locate
>       rescue
>         return nil
>       end
>     end 
>     def exists?
>       return @o != nil
>     end
>   end
> end 
> Michael

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Thu May 13 10:53:31 2010
From: watirjira at gmail.com (Bret Pettichord (JIRA))
Date: Thu, 13 May 2010 09:53:31 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Updated: (WTR-281) add exists? for frames
Message-ID: <11514548.244.1273762411406.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


     [ http://jira.openqa.org/browse/WTR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bret Pettichord updated WTR-281:
--------------------------------

    Fix Version/s:     (was: Soon)
                   Next

> add exists? for frames
> ----------------------
>
>                 Key: WTR-281
>                 URL: http://jira.openqa.org/browse/WTR-281
>             Project: Watir
>          Issue Type: New Feature
>          Components: Frame
>    Affects Versions: 1.6.2
>         Environment: x
>            Reporter: Charley Baker
>            Assignee: Bret Pettichord
>             Fix For: Next
>
>
> This has come up in the mailing list a few times. Monkey patch from MHwee: 
> Michael Hwee
>  to watir-general
> 	
> frame does not support exists?().
> However, you can *monkey-patch* as followed.
> module Watir
>   class Frame
>     alias_method :_locate, :locate
>     def locate
>       begin
>         return _locate
>       rescue
>         return nil
>       end
>     end 
>     def exists?
>       return @o != nil
>     end
>   end
> end 
> Michael

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From watirjira at gmail.com  Thu May 13 10:53:31 2010
From: watirjira at gmail.com (Bret Pettichord (JIRA))
Date: Thu, 13 May 2010 09:53:31 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Updated: (WTR-281) add exists? for frames
Message-ID: <13556513.240.1273762411296.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


     [ http://jira.openqa.org/browse/WTR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bret Pettichord updated WTR-281:
--------------------------------

       Priority: Minor  (was: Trivial)
       Assignee: Bret Pettichord
    Environment: x

The workaround would be to apply the monkey patch. I have changed the priority. We'll look into getting this fixed in the next release of Watir.

> add exists? for frames
> ----------------------
>
>                 Key: WTR-281
>                 URL: http://jira.openqa.org/browse/WTR-281
>             Project: Watir
>          Issue Type: New Feature
>          Components: Frame
>    Affects Versions: 1.6.2
>         Environment: x
>            Reporter: Charley Baker
>            Assignee: Bret Pettichord
>             Fix For: Next
>
>
> This has come up in the mailing list a few times. Monkey patch from MHwee: 
> Michael Hwee
>  to watir-general
> 	
> frame does not support exists?().
> However, you can *monkey-patch* as followed.
> module Watir
>   class Frame
>     alias_method :_locate, :locate
>     def locate
>       begin
>         return _locate
>       rescue
>         return nil
>       end
>     end 
>     def exists?
>       return @o != nil
>     end
>   end
> end 
> Michael

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From notethan at gmail.com  Thu May 13 10:53:16 2010
From: notethan at gmail.com (Ethan)
Date: Thu, 13 May 2010 10:53:16 -0400
Subject: [Wtr-development] attach embedded browser to watir
In-Reply-To: <D1F0EAF9A051C3418A438177125816BB0F7C25B9@GDCPW1082.corp.statestr.com>
References: <D1F0EAF9A051C3418A438177125816BB0F7C25B9@GDCPW1082.corp.statestr.com>
Message-ID: <AANLkTil5ZwOm-Mh04FJv3ABE7f-8xAkUadHcR-mw6chQ@mail.gmail.com>

What have you tried so far? Where is it failing and how is it failing?

On Thu, May 13, 2010 at 05:18, Xu, Jian <JXu6 at statestreet.com> wrote:

>  Hi all:
>
> I want to let watir attach embedded browser, and control it. I have search
> on google and
> read some reference. It seems someone has solved this problem.
> But I can't let it work yet. I can't understand all those details.
>
> My problem is as following:
>   In an Eclipse RCP program, I use SWT OLE to create a browser.
>   ------Java Code
>                 OleFrame frame = new OleFrame(parent, SWT.NONE);
>                 OleClientSite client = new
> OleClientSite(frame,SWT.NONE,"Shell.Explorer.2");
>                 client.doVerb(OLE.OLEIVERB_SHOW);
>                 OleAutomation oa = new OleAutomation(client);
>                 Variant str = new Variant(?*www.google.com*<http://www.google.com/url?sa=D&q=www.google.com&usg=AFQjCNEbQmySw5dEh-H1m6n4CjHWihV2vg>
> ");
>                 oa.invoke(104, new Variant[]{str});
>
>   Then I want to use watir to control it.
>
> My question is:
>   1.That browser instant is a embedded browser here?
>   2.Could watir be used as I has described?
>
> Actually I find threads such as *
> http://rubyforge.org/pipermail/wtr-development/2009-August/001174.html*<http://www.google.com/url?sa=D&q=http://rubyforge.org/pipermail/wtr-development/2009-August/001174.html&usg=AFQjCNHznViri05J6Qnp_-AKxTMzx5GK9A>
> I understand that may be solved already.
> and here *
> https://gist.github.com/224981/9d643daf08c9558235bf0e3ce65ed4ca0019f97f*<http://www.google.com/url?sa=D&q=https://gist.github.com/224981/9d643daf08c9558235bf0e3ce65ed4ca0019f97f&usg=AFQjCNGwEosV4b9cHLlk8kYsT2-GpMdPMA>
> post the source code.
> But it can't work for me... It's a pity since I know little about
> win32ole.etc...
>
> Any suggestion is every appreciated!!
>
> Regards,
>  Jian Xu(James)
>
>
> _______________________________________________
> 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/20100513/bedda8a5/attachment-0001.html>

From JXu6 at StateStreet.com  Thu May 13 22:08:32 2010
From: JXu6 at StateStreet.com (Xu, Jian)
Date: Thu, 13 May 2010 22:08:32 -0400
Subject: [Wtr-development] attach embedded browser to watir
In-Reply-To: <AANLkTil5ZwOm-Mh04FJv3ABE7f-8xAkUadHcR-mw6chQ@mail.gmail.com>
References: <D1F0EAF9A051C3418A438177125816BB0F7C25B9@GDCPW1082.corp.statestr.com>
	<AANLkTil5ZwOm-Mh04FJv3ABE7f-8xAkUadHcR-mw6chQ@mail.gmail.com>
Message-ID: <D1F0EAF9A051C3418A438177125816BB0F9250C7@GDCPW1082.corp.statestr.com>

Thanks Ethan:

 

After using embedded_ie.rb, it only says it can't locate a window with
classnameNN of Internet Explorer_Server1 or can't locate a window with
handle...

So I've no idea how to continue. I have little knowledge about
WIN32.etc...

 

---Java Code

OleFrame frame = new OleFrame(parent, SWT.NONE);

            OleControlSite client = new
OleControlSite(frame,SWT.NONE,"Shell.Explorer.2");

            client.doVerb(OLE.OLEIVERB_SHOW);

            OleAutomation oa = new OleAutomation(client);

            Variant str = new Variant("http://www.google.com");

            oa.invoke(104, new Variant[]{str});

            

            System.out.println(Integer.toHexString(client.handle));

 

---And embedded_ie.rb code

See attachment

 

 

 

________________________________

From: wtr-development-bounces at rubyforge.org
[mailto:wtr-development-bounces at rubyforge.org] On Behalf Of Ethan
Sent: Thursday, May 13, 2010 10:53 AM
To: Watir development
Subject: Re: [Wtr-development] attach embedded browser to watir

 

What have you tried so far? Where is it failing and how is it failing? 

On Thu, May 13, 2010 at 05:18, Xu, Jian <JXu6 at statestreet.com> wrote:

Hi all:

I want to let watir attach embedded browser, and control it. I have
search on google and 
read some reference. It seems someone has solved this problem.
But I can't let it work yet. I can't understand all those details. 

My problem is as following:
  In an Eclipse RCP program, I use SWT OLE to create a browser.
  ------Java Code
                OleFrame frame = new OleFrame(parent, SWT.NONE);
                OleClientSite client = new
OleClientSite(frame,SWT.NONE,"Shell.Explorer.2");
                client.doVerb(OLE.OLEIVERB_SHOW);
                OleAutomation oa = new OleAutomation(client);
                Variant str = new Variant("www.google.com
<http://www.google.com/url?sa=D&q=www.google.com&usg=AFQjCNEbQmySw5dEh-H
1m6n4CjHWihV2vg> ");
                oa.invoke(104, new Variant[]{str}); 

  Then I want to use watir to control it. 

My question is:
  1.That browser instant is a embedded browser here?
  2.Could watir be used as I has described? 

Actually I find threads such as 
http://rubyforge.org/pipermail/wtr-development/2009-August/001174.html
<http://www.google.com/url?sa=D&q=http://rubyforge.org/pipermail/wtr-dev
elopment/2009-August/001174.html&usg=AFQjCNHznViri05J6Qnp_-AKxTMzx5GK9A>

I understand that may be solved already.
and here 
https://gist.github.com/224981/9d643daf08c9558235bf0e3ce65ed4ca0019f97f
<http://www.google.com/url?sa=D&q=https://gist.github.com/224981/9d643da
f08c9558235bf0e3ce65ed4ca0019f97f&usg=AFQjCNGwEosV4b9cHLlk8kYsT2-GpMdPMA
> 
post the source code.
But it can't work for me... It's a pity since I know little about
win32ole.etc...

Any suggestion is every appreciated!! 

Regards,
Jian Xu(James)


_______________________________________________
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/20100513/e7ce84ab/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: embedded_ie.rb.zip
Type: application/x-zip-compressed
Size: 2057 bytes
Desc: embedded_ie.rb.zip
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20100513/e7ce84ab/attachment.bin>

From abaird at bairdsnet.net  Sat May 15 14:27:20 2010
From: abaird at bairdsnet.net (Alan Baird)
Date: Sat, 15 May 2010 13:27:20 -0500
Subject: [Wtr-development] bugfix for Watir::Table#to_a
In-Reply-To: <s2ob7bf92f01005071656w2dcda546rd79d8676a341da16@mail.gmail.com>
References: <s2ob7bf92f01005071656w2dcda546rd79d8676a341da16@mail.gmail.com>
Message-ID: <AANLkTimLnLHm4p6XlLGN_8LpkBT4Y3IkHiX4FKXG2KYk@mail.gmail.com>

Jarmo -

I'm looking forward to looking at your code, but while I'm thinking
about it, you said:

> Also, as a sidenote, there has to be something changed with tables
> API, because other methods won't work with nested tables correctly and
> the question is of course, how would
> be the correct behaviour :)

This was a recent fix in 1.6.5 to make the table itterator always use,
in your parlance, max_depth = 1.  This was added because the itterator
was using the normal row_count method, which returns the count of all
<tr>'s regardless of whether they were an immediate child of the table
or not.  Thus, if you are itterating on a table with nested tables,
you would have to rescue (at least) the itteration to keep your script
from crashing.

I submit that this should be the default behavior.  I think that
rarely what you want is to really get "all" of the <tr>'s in a nested
table and if that is what you want, it's probably not the most common
use case.

Also, I think that it would be really nice to have a .th method for
tables as well, or a way to exclude them from itteration.  Most of the
time, when I am processing a table, I really want to just look at the
"data" rows, or sometimes just the header.  You can easily accomplish
this if your devs have put sensible class names for the table rows,
but if they are using the <th> tags anyway, being able to use them
will give a certain amount of robustness against changes to the class
names.

Let me know what you think.

Alan

From jarmo.p at gmail.com  Sat May 15 15:01:35 2010
From: jarmo.p at gmail.com (Jarmo)
Date: Sat, 15 May 2010 22:01:35 +0300
Subject: [Wtr-development] bugfix for Watir::Table#to_a
In-Reply-To: <AANLkTimLnLHm4p6XlLGN_8LpkBT4Y3IkHiX4FKXG2KYk@mail.gmail.com>
References: <s2ob7bf92f01005071656w2dcda546rd79d8676a341da16@mail.gmail.com> 
	<AANLkTimLnLHm4p6XlLGN_8LpkBT4Y3IkHiX4FKXG2KYk@mail.gmail.com>
Message-ID: <AANLkTim40QP7gPg1t5CuZDylPQMZVxgziyaWD_ETV7o1@mail.gmail.com>

Hi.

I'm trying to make a pull request soon or submit a patch, whichever is
more preferable. Unfortunately i'm kinda busy with school at the
moment so it won't happen right away.

I think that #th method would be great, but just for searching
elements. For exclusion, you can use regular Array methods like #shift
or #delete_at.

Jarmo

On Sat, May 15, 2010 at 9:27 PM, Alan Baird <abaird at bairdsnet.net> wrote:
> Jarmo -
>
> I'm looking forward to looking at your code, but while I'm thinking
> about it, you said:
>
>> Also, as a sidenote, there has to be something changed with tables
>> API, because other methods won't work with nested tables correctly and
>> the question is of course, how would
>> be the correct behaviour :)
>
> This was a recent fix in 1.6.5 to make the table itterator always use,
> in your parlance, max_depth = 1. ?This was added because the itterator
> was using the normal row_count method, which returns the count of all
> <tr>'s regardless of whether they were an immediate child of the table
> or not. ?Thus, if you are itterating on a table with nested tables,
> you would have to rescue (at least) the itteration to keep your script
> from crashing.
>
> I submit that this should be the default behavior. ?I think that
> rarely what you want is to really get "all" of the <tr>'s in a nested
> table and if that is what you want, it's probably not the most common
> use case.
>
> Also, I think that it would be really nice to have a .th method for
> tables as well, or a way to exclude them from itteration. ?Most of the
> time, when I am processing a table, I really want to just look at the
> "data" rows, or sometimes just the header. ?You can easily accomplish
> this if your devs have put sensible class names for the table rows,
> but if they are using the <th> tags anyway, being able to use them
> will give a certain amount of robustness against changes to the class
> names.
>
> Let me know what you think.
>
> Alan
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>

From charley.baker at gmail.com  Sat May 15 15:27:54 2010
From: charley.baker at gmail.com (Charley Baker)
Date: Sat, 15 May 2010 13:27:54 -0600
Subject: [Wtr-development] bugfix for Watir::Table#to_a
In-Reply-To: <AANLkTim40QP7gPg1t5CuZDylPQMZVxgziyaWD_ETV7o1@mail.gmail.com>
References: <s2ob7bf92f01005071656w2dcda546rd79d8676a341da16@mail.gmail.com>
	<AANLkTimLnLHm4p6XlLGN_8LpkBT4Y3IkHiX4FKXG2KYk@mail.gmail.com>
	<AANLkTim40QP7gPg1t5CuZDylPQMZVxgziyaWD_ETV7o1@mail.gmail.com>
Message-ID: <AANLkTik15WrT0_BG-IWBKfvPvmwCB6l7NlG0q1hw5szt@mail.gmail.com>

Either/or is fine, a pull request can be slightly simpler if you're working
of the current master.

 -c

On Sat, May 15, 2010 at 1:01 PM, Jarmo <jarmo.p at gmail.com> wrote:

> Hi.
>
> I'm trying to make a pull request soon or submit a patch, whichever is
> more preferable. Unfortunately i'm kinda busy with school at the
> moment so it won't happen right away.
>
> I think that #th method would be great, but just for searching
> elements. For exclusion, you can use regular Array methods like #shift
> or #delete_at.
>
> Jarmo
>
> On Sat, May 15, 2010 at 9:27 PM, Alan Baird <abaird at bairdsnet.net> wrote:
> > Jarmo -
> >
> > I'm looking forward to looking at your code, but while I'm thinking
> > about it, you said:
> >
> >> Also, as a sidenote, there has to be something changed with tables
> >> API, because other methods won't work with nested tables correctly and
> >> the question is of course, how would
> >> be the correct behaviour :)
> >
> > This was a recent fix in 1.6.5 to make the table itterator always use,
> > in your parlance, max_depth = 1.  This was added because the itterator
> > was using the normal row_count method, which returns the count of all
> > <tr>'s regardless of whether they were an immediate child of the table
> > or not.  Thus, if you are itterating on a table with nested tables,
> > you would have to rescue (at least) the itteration to keep your script
> > from crashing.
> >
> > I submit that this should be the default behavior.  I think that
> > rarely what you want is to really get "all" of the <tr>'s in a nested
> > table and if that is what you want, it's probably not the most common
> > use case.
> >
> > Also, I think that it would be really nice to have a .th method for
> > tables as well, or a way to exclude them from itteration.  Most of the
> > time, when I am processing a table, I really want to just look at the
> > "data" rows, or sometimes just the header.  You can easily accomplish
> > this if your devs have put sensible class names for the table rows,
> > but if they are using the <th> tags anyway, being able to use them
> > will give a certain amount of robustness against changes to the class
> > names.
> >
> > Let me know what you think.
> >
> > 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/20100515/9c3a25df/attachment.html>

From zeljko.filipin at wa-research.ch  Thu May 27 10:37:51 2010
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Thu, 27 May 2010 16:37:51 +0200
Subject: [Wtr-development] Fwd: [wtr-general] anyone want to do a watir
	version?
In-Reply-To: <AANLkTims0X-1s04TL817fgiC1NvDbUxsaqv0QDLCRqET@mail.gmail.com>
References: <AANLkTims0X-1s04TL817fgiC1NvDbUxsaqv0QDLCRqET@mail.gmail.com>
Message-ID: <AANLkTinsZsyAjso5HO901wAHttWIupoNqxdlIqBXvZUj@mail.gmail.com>

I guess a lot of you are not monitoring watir-general. Paul sent an
interesting mail a few days ago, and I decided to give it a try. At the
moment, Pacman just goes randomly in all directions:

http://github.com/zeljkofilipin/pacman

Feel free to fork.

There is a short video, too:

http://www.youtube.com/watch?v=r9Y6RtKiTQs

?eljko

---------- Forwarded message ----------
From: Paul Rogers <paul.rogers at shaw.ca>
Date: Tue, May 25, 2010 at 8:13 PM
Subject: [wtr-general] anyone want to do a watir version?
To: watir-general at googlegroups.com

http://seleniumexamples.com/blog/examples/play-pacman-with-selenium-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20100527/6f87c231/attachment.html>

From zeljko.filipin at wa-research.ch  Thu May 27 17:28:02 2010
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Thu, 27 May 2010 23:28:02 +0200
Subject: [Wtr-development] Watir Podcast #34: Zhimin Zhan on TestWise
Message-ID: <AANLkTinCko6CgEXE-650KHrUBIT2-hwAVuI7eLdONfQb@mail.gmail.com>

I have just published another podcast:

http://watirpodcast.com/34-zhimin-zhan-on-testwise/

It is a big day for Watir Podcast. Today it is 2 years old! :)

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