From alister.scott at gmail.com  Mon Nov  1 02:39:05 2010
From: alister.scott at gmail.com (Alister Scott)
Date: Mon, 1 Nov 2010 16:39:05 +1000
Subject: [Wtr-development] A solution for JavaScript dialogs in Watir
In-Reply-To: <5041064815485816556@unknownmsgid>
References: <AANLkTin6pbq8KyLcVPV2Y8qAgz=4JTJeDyKSz0MbuY5V@mail.gmail.com>
	<AANLkTimGLwkJgeseRhXenaSvFrQ=uQe1erqk9jcYgkdy@mail.gmail.com>
	<AANLkTim6XtPsOD6x1w1bzvG8eZZSiNkLHYYi4q8rSkiP@mail.gmail.com>
	<283480053526741930@unknownmsgid> <5041064815485816556@unknownmsgid>
Message-ID: <AANLkTinfMQzcRLempb6gsyUC1bV9FMeVG78VjrSLac4H@mail.gmail.com>

I've written a blog post on this:
http://watirmelon.com/2010/10/31/dismissing-pesky-javascript-dialogs-with-watir/

and updated the wiki:  http://wiki.openqa.org/display/WTR/JavaScript+Pop+Ups

Cheers,
Alister

On Sat, Oct 30, 2010 at 7:52 AM, Alister Scott <alister.scott at gmail.com>wrote:

> Any ideas why my code won't work in FireWatir?
>
> Cheers, Alister.
>
> On 30/10/2010, at 6:47 AM, Jari Bakken <jari.bakken at gmail.com> wrote:
>
> watir-webdriver has a decent Ruby API for this as an optional require:
>
>
> <http://github.com/jarib/watir-webdriver/blob/master/lib/watir-webdriver/extensions/alerts.rb>
> http://github.com/jarib/watir-webdriver/blob/master/lib/watir-webdriver/extensions/alerts.rb
>
> Feel free to use it in Watir. I might change it when WebDriver provides its
> own solution though.
>
> Den 29. okt. 2010 kl. 21:23 skrev Bret Pettichord < <bret at pettichord.com>
> bret at pettichord.com>:
>
> You can add the technique to this page:
>
> <http://wiki.openqa.org/display/WTR/JavaScript+Pop+Ups><http://wiki.openqa.org/display/WTR/JavaScript+Pop+Ups>
> http://wiki.openqa.org/display/WTR/JavaScript+Pop+Ups
>
> Bret
>
> On Thu, Oct 28, 2010 at 11:42 PM, Alister Scott <<alister.scott at gmail.com><alister.scott at gmail.com>
> alister.scott at gmail.com> wrote:
>
>> I forgot to mention, I can't get this working in Firefox, only IE at the
>> moment.
>>
>> Cheers,
>> Alister
>>
>>
>> On Fri, Oct 29, 2010 at 12:16 PM, Alister Scott <<alister.scott at gmail.com><alister.scott at gmail.com>
>> alister.scott at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> One of the guys I am working with setting up Cucumber and Watir on a
>>> ThoughtWorks project told me about a way to get rid of the pesky JavaScript
>>> dialogs that cause Watir scripts to be unstable. It involves overriding the
>>> JavaScript function to always return true, so the dialogs never appear.
>>>
>>> I wrote an example for Watir:
>>>
>>> require 'rubygems'
>>> require 'watir'
>>> b = Watir::Browser.start "<http://www.sislands.com/coin70/week1/dialogbox.htm><http://www.sislands.com/coin70/week1/dialogbox.htm>
>>> http://www.sislands.com/coin70/week1/dialogbox.htm"
>>> b.execute_script "window.confirm = function() { return true; }"
>>> b.execute_script "window.alert = function() { return true; }"
>>> b.execute_script "window.prompt = function() { return true; }"
>>> b.button(:value => 'confirm').click
>>>
>>>
>>> What do you think of this? Is it worthwhile putting this out for Watir
>>> users to see and use?
>>>
>>> Cheers,
>>>
>>> Alister Scott
>>> Brisbane, Australia
>>> Watir Web Master: <http://watir.com> <http://watir.com>http://watir.com
>>> Blog: <http://watirmelon.com> <http://watirmelon.com>
>>> http://watirmelon.com
>>> LinkedIn: <http://www.linkedin.com/in/alisterscott><http://www.linkedin.com/in/alisterscott>
>>> http://www.linkedin.com/in/alisterscott
>>>
>>> "There are two ways to get enough: One is to continue to accumulate more
>>> and more. The other is to desire less." *~ G. K. Chesterton*
>>>
>>
>>
>> _______________________________________________
>> Wtr-development mailing list
>>  <Wtr-development at rubyforge.org> <Wtr-development at rubyforge.org>
>> Wtr-development at rubyforge.org
>>  <http://rubyforge.org/mailman/listinfo/wtr-development><http://rubyforge.org/mailman/listinfo/wtr-development>
>> http://rubyforge.org/mailman/listinfo/wtr-development
>>
>
>
>
> --
> Bret Pettichord
> Lead Developer, Watir, <http://www.watir.com> <http://www.watir.com>
> www.watir.com
>
> Blog, <http://www.io.com/%7Ewazmo/blog> <http://www.io.com/%7Ewazmo/blog>
> www.io.com/~wazmo/blog <http://www.io.com/%7Ewazmo/blog>
> Twitter, <http://www.twitter.com/bpettichord><http://www.twitter.com/bpettichord>
> www.twitter.com/bpettichord
>
> _______________________________________________
> Wtr-development mailing list
> <Wtr-development at rubyforge.org>Wtr-development at rubyforge.org
>  <http://rubyforge.org/mailman/listinfo/wtr-development>
> 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/20101101/7bcc3b8b/attachment.html>

From watirjira at gmail.com  Mon Nov  1 13:31:20 2010
From: watirjira at gmail.com (Ian Glover (JIRA))
Date: Mon, 1 Nov 2010 12:31:20 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-427) WIN32OLERuntimeErrors
 on almost every proerty and method
In-Reply-To: <5184744.466.1269374737677.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <3019390.476.1288632680919.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Ian Glover commented on WTR-427:
--------------------------------

I can reproduce this issue, when connecting to intranet sites on Windows 7. It is also discussed at http://www.mail-archive.com/wtr-development at rubyforge.org/msg00011.html

I found two work arounds:
 - Run Watir from a shell with administrator permissions.
 - Set protected mode on for intranet sites.

The later seems to be the opposite advice to the aforementioned thread, I'm not sure why: it may be because I first connect to a Internet site and then to intranet site so the two zones have to be the same.

> WIN32OLERuntimeErrors on almost every proerty and method
> --------------------------------------------------------
>
>                 Key: WTR-427
>                 URL: http://jira.openqa.org/browse/WTR-427
>             Project: Watir
>          Issue Type: Bug
>          Components: Other
>    Affects Versions: 1.6.5
>         Environment: Watir 1.6.5
> Ruby 1.8.6-p111
> Gem 1.3.6
> Windows 7 Enterprise (version 6.1, build 7600)
> Internet Explorer 8 (version 8.0.7600.16385)
>            Reporter: Mark Faust
>            Priority: Blocker
>
> I just installed Watir on a Windows 7 workstation.  Almost every operation under IE is returning a WIN32OLERuntimeError for unknown property or method, followed by an error code and an announcement that the interface is unknown or the RPC server is unavailable.  The same operations are not problematic under Firefox.  This is not occurring after opening and closing many IE windows (a problem that was apparently quite frequent under Win Vista in the past), it occurs with the first window opened.  I installed Ruby, updated the Gem and installed Watir as an administrative user.
> An example irb session follows:
> C:\ruby>irb
> irb(main):001:0> require 'Watir'
> => true
> irb(main):002:0> ie = Watir::IE.new
> => #<Watir::IE:0x4bba590 url="about:blank" title="">
> irb(main):003:0> ie.goto "http://localhost/demo"
> => 0.225
> irb(main):004:0> ie.text_field(:name, "username").set "GWashington"
> WIN32OLERuntimeError: unknown property or method `document'
>     HRESULT error code:0x800706b5
>       The interface is unknown.
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/ie-class.rb:46
> 0:in `method_missing'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/ie-class.rb:46
> 0:in `document'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/container.rb:8
> 00:in `locate_input_element'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/input_elements
> .rb:5:in `locate'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/element.rb:53:
> in `assert_exists'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/element.rb:288
> :in `enabled?'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/element.rb:60:
> in `assert_enabled'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/input_elements
> .rb:327:in `set'
>         from (irb):4
> irb(main):005:0> ie.button(:value, "Login").click
> WIN32OLERuntimeError: unknown property or method `document'
>     HRESULT error code:0x800706b5
>       The interface is unknown.
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/ie-class.rb:46
> 0:in `method_missing'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/ie-class.rb:46
> 0:in `document'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/container.rb:8
> 00:in `locate_input_element'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/input_elements
> .rb:5:in `locate'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/element.rb:53:
> in `assert_exists'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/element.rb:288
> :in `enabled?'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/element.rb:60:
> in `assert_enabled'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/element.rb:233
> :in `click!'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/element.rb:219
> :in `click'
>         from (irb):5
> irb(main):006:0> ie.url
> WIN32OLERuntimeError: unknown property or method `LocationURL'
>     HRESULT error code:0x800706b5
>       The interface is unknown.
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/ie-class.rb:46
> 5:in `method_missing'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/ie-class.rb:46
> 5:in `url'
>         from (irb):6
> irb(main):007:0> ie.title
> WIN32OLERuntimeError: unknown property or method `document'
>     HRESULT error code:0x800706ba
>       The RPC server is unavailable.
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/ie-class.rb:33
> 9:in `method_missing'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/ie-class.rb:33
> 9:in `title'
>         from (irb):13
> irb(main):008: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  Mon Nov  1 15:33:20 2010
From: watirjira at gmail.com (Charley Baker (JIRA))
Date: Mon, 1 Nov 2010 14:33:20 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-427) WIN32OLERuntimeErrors
 on almost every proerty and method
In-Reply-To: <5184744.466.1269374737677.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <8205318.480.1288640000762.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Charley Baker commented on WTR-427:
-----------------------------------

Can you update the wiki to include at least the first instruction? The latter one sounds peculiar and doesn't make sense, feel free to ask other people on the Watir general list. 

> WIN32OLERuntimeErrors on almost every proerty and method
> --------------------------------------------------------
>
>                 Key: WTR-427
>                 URL: http://jira.openqa.org/browse/WTR-427
>             Project: Watir
>          Issue Type: Bug
>          Components: Other
>    Affects Versions: 1.6.5
>         Environment: Watir 1.6.5
> Ruby 1.8.6-p111
> Gem 1.3.6
> Windows 7 Enterprise (version 6.1, build 7600)
> Internet Explorer 8 (version 8.0.7600.16385)
>            Reporter: Mark Faust
>            Priority: Blocker
>
> I just installed Watir on a Windows 7 workstation.  Almost every operation under IE is returning a WIN32OLERuntimeError for unknown property or method, followed by an error code and an announcement that the interface is unknown or the RPC server is unavailable.  The same operations are not problematic under Firefox.  This is not occurring after opening and closing many IE windows (a problem that was apparently quite frequent under Win Vista in the past), it occurs with the first window opened.  I installed Ruby, updated the Gem and installed Watir as an administrative user.
> An example irb session follows:
> C:\ruby>irb
> irb(main):001:0> require 'Watir'
> => true
> irb(main):002:0> ie = Watir::IE.new
> => #<Watir::IE:0x4bba590 url="about:blank" title="">
> irb(main):003:0> ie.goto "http://localhost/demo"
> => 0.225
> irb(main):004:0> ie.text_field(:name, "username").set "GWashington"
> WIN32OLERuntimeError: unknown property or method `document'
>     HRESULT error code:0x800706b5
>       The interface is unknown.
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/ie-class.rb:46
> 0:in `method_missing'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/ie-class.rb:46
> 0:in `document'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/container.rb:8
> 00:in `locate_input_element'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/input_elements
> .rb:5:in `locate'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/element.rb:53:
> in `assert_exists'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/element.rb:288
> :in `enabled?'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/element.rb:60:
> in `assert_enabled'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/input_elements
> .rb:327:in `set'
>         from (irb):4
> irb(main):005:0> ie.button(:value, "Login").click
> WIN32OLERuntimeError: unknown property or method `document'
>     HRESULT error code:0x800706b5
>       The interface is unknown.
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/ie-class.rb:46
> 0:in `method_missing'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/ie-class.rb:46
> 0:in `document'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/container.rb:8
> 00:in `locate_input_element'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/input_elements
> .rb:5:in `locate'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/element.rb:53:
> in `assert_exists'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/element.rb:288
> :in `enabled?'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/element.rb:60:
> in `assert_enabled'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/element.rb:233
> :in `click!'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/element.rb:219
> :in `click'
>         from (irb):5
> irb(main):006:0> ie.url
> WIN32OLERuntimeError: unknown property or method `LocationURL'
>     HRESULT error code:0x800706b5
>       The interface is unknown.
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/ie-class.rb:46
> 5:in `method_missing'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/ie-class.rb:46
> 5:in `url'
>         from (irb):6
> irb(main):007:0> ie.title
> WIN32OLERuntimeError: unknown property or method `document'
>     HRESULT error code:0x800706ba
>       The RPC server is unavailable.
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/ie-class.rb:33
> 9:in `method_missing'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/ie-class.rb:33
> 9:in `title'
>         from (irb):13
> irb(main):008: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  Tue Nov  2 05:24:20 2010
From: watirjira at gmail.com (Zeljko (JIRA))
Date: Tue, 2 Nov 2010 04:24:20 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-93) ie.divs.show not
	working
Message-ID: <11774041.487.1288689860408.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Zeljko commented on WTR-93:
---------------------------

I have just found out that we already have a ticket for it:

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

> ie.divs.show not working
> ------------------------
>
>                 Key: WTR-93
>                 URL: http://jira.openqa.org/browse/WTR-93
>             Project: Watir
>          Issue Type: Bug
>          Components: HTML Controls
>    Affects Versions: 1.5.0/1.5.1
>         Environment: Microsoft Windows XP Professional, Version: 5.1.2600, Service Pack: 2.0
> ruby 1.8.4 (2006-04-14) [i386-mswin32]
> watir-1.5.1.1065
>            Reporter: Zeljko
>            Priority: Major
>             Fix For: Soon
>
>
> - go to irb
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> ie = Watir::IE.start("http://www.yahoo.com/")
> => #<Watir::IE:0x2e54280
> [...]
> >
> irb(main):003:0> ie.divs.show
> index id                  className
> 1
> 2
> [...]
> 74
> 75
> => nil
> - only indexes are printed, all ids are empty
> - this is snippet of html of that page (divs have ids)
> [...]
> <div id="page">
> <div id="masthead">
> <div id="mastheadhd">
> <div id="eyebrow">
> <div class="iemw" style="width:925px;"></div>
> [...]

-- 
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  Tue Nov  2 07:53:12 2010
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Tue, 2 Nov 2010 12:53:12 +0100
Subject: [Wtr-development] Watir Podcast #37: Jeff Lusenhop on Janova
In-Reply-To: <AANLkTika0uaFE7mEHm4hPhoCx3yK=etfFP62t_zZn=5a@mail.gmail.com>
References: <AANLkTika0uaFE7mEHm4hPhoCx3yK=etfFP62t_zZn=5a@mail.gmail.com>
Message-ID: <AANLkTi=CatvXYp7mqA+s0pJjQEmDjUFph4KOEx+w6ib1@mail.gmail.com>

Part 2 of 3 is just released:

http://watirpodcast.com/38-jeff-lusenhop-on-janova-2-3/

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

From watirjira at gmail.com  Wed Nov  3 11:11:20 2010
From: watirjira at gmail.com (Bret Pettichord (JIRA))
Date: Wed, 3 Nov 2010 10:11:20 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-93) ie.divs.show not
	working
Message-ID: <11214634.508.1288797080204.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Bret Pettichord commented on WTR-93:
------------------------------------

Zeljko, OK I see the ticket, but no one has voted on it.

> ie.divs.show not working
> ------------------------
>
>                 Key: WTR-93
>                 URL: http://jira.openqa.org/browse/WTR-93
>             Project: Watir
>          Issue Type: Bug
>          Components: HTML Controls
>    Affects Versions: 1.5.0/1.5.1
>         Environment: Microsoft Windows XP Professional, Version: 5.1.2600, Service Pack: 2.0
> ruby 1.8.4 (2006-04-14) [i386-mswin32]
> watir-1.5.1.1065
>            Reporter: Zeljko
>            Priority: Major
>             Fix For: Soon
>
>
> - go to irb
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> ie = Watir::IE.start("http://www.yahoo.com/")
> => #<Watir::IE:0x2e54280
> [...]
> >
> irb(main):003:0> ie.divs.show
> index id                  className
> 1
> 2
> [...]
> 74
> 75
> => nil
> - only indexes are printed, all ids are empty
> - this is snippet of html of that page (divs have ids)
> [...]
> <div id="page">
> <div id="masthead">
> <div id="mastheadhd">
> <div id="eyebrow">
> <div class="iemw" style="width:925px;"></div>
> [...]

-- 
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 Nov  3 11:13:19 2010
From: watirjira at gmail.com (Zeljko (JIRA))
Date: Wed, 3 Nov 2010 10:13:19 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-93) ie.divs.show not
	working
Message-ID: <28603302.510.1288797199813.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Zeljko commented on WTR-93:
---------------------------

I guess people do not know about the ticket. Or do you think nobody would like show methods to be removed?

> ie.divs.show not working
> ------------------------
>
>                 Key: WTR-93
>                 URL: http://jira.openqa.org/browse/WTR-93
>             Project: Watir
>          Issue Type: Bug
>          Components: HTML Controls
>    Affects Versions: 1.5.0/1.5.1
>         Environment: Microsoft Windows XP Professional, Version: 5.1.2600, Service Pack: 2.0
> ruby 1.8.4 (2006-04-14) [i386-mswin32]
> watir-1.5.1.1065
>            Reporter: Zeljko
>            Priority: Major
>             Fix For: Soon
>
>
> - go to irb
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> ie = Watir::IE.start("http://www.yahoo.com/")
> => #<Watir::IE:0x2e54280
> [...]
> >
> irb(main):003:0> ie.divs.show
> index id                  className
> 1
> 2
> [...]
> 74
> 75
> => nil
> - only indexes are printed, all ids are empty
> - this is snippet of html of that page (divs have ids)
> [...]
> <div id="page">
> <div id="masthead">
> <div id="mastheadhd">
> <div id="eyebrow">
> <div class="iemw" style="width:925px;"></div>
> [...]

-- 
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 Nov  3 14:26:20 2010
From: watirjira at gmail.com (Jarmo Pertman (JIRA))
Date: Wed, 3 Nov 2010 13:26:20 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-93) ie.divs.show not
	working
Message-ID: <1239273.515.1288808780028.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Jarmo Pertman commented on WTR-93:
----------------------------------

I'm also in favor of removing those methods since they don't add any additional value, but only adding additional code.

> ie.divs.show not working
> ------------------------
>
>                 Key: WTR-93
>                 URL: http://jira.openqa.org/browse/WTR-93
>             Project: Watir
>          Issue Type: Bug
>          Components: HTML Controls
>    Affects Versions: 1.5.0/1.5.1
>         Environment: Microsoft Windows XP Professional, Version: 5.1.2600, Service Pack: 2.0
> ruby 1.8.4 (2006-04-14) [i386-mswin32]
> watir-1.5.1.1065
>            Reporter: Zeljko
>            Priority: Major
>             Fix For: Soon
>
>
> - go to irb
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> ie = Watir::IE.start("http://www.yahoo.com/")
> => #<Watir::IE:0x2e54280
> [...]
> >
> irb(main):003:0> ie.divs.show
> index id                  className
> 1
> 2
> [...]
> 74
> 75
> => nil
> - only indexes are printed, all ids are empty
> - this is snippet of html of that page (divs have ids)
> [...]
> <div id="page">
> <div id="masthead">
> <div id="mastheadhd">
> <div id="eyebrow">
> <div class="iemw" style="width:925px;"></div>
> [...]

-- 
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  Wed Nov  3 15:55:28 2010
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 3 Nov 2010 14:55:28 -0500
Subject: [Wtr-development] [JIRA] Commented: (WTR-93) ie.divs.show not
	working
In-Reply-To: <1239273.515.1288808780028.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
References: <1239273.515.1288808780028.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <AANLkTi=yC=_q5iAWDA7wPP+g3VWqXyOJgirkL+3UiDsZ@mail.gmail.com>

Here's my point: your comments are on the wrong ticket. Please add your
comments/votes to the other ticket.

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

Bret

On Wed, Nov 3, 2010 at 1:26 PM, Jarmo Pertman (JIRA) <watirjira at gmail.com>wrote:

>
>    [
> http://jira.openqa.org/browse/WTR-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19992#action_19992]
>
> Jarmo Pertman commented on WTR-93:
> ----------------------------------
>
> I'm also in favor of removing those methods since they don't add any
> additional value, but only adding additional code.
>
> > ie.divs.show not working
> > ------------------------
> >
> >                 Key: WTR-93
> >                 URL: http://jira.openqa.org/browse/WTR-93
> >             Project: Watir
> >          Issue Type: Bug
> >          Components: HTML Controls
> >    Affects Versions: 1.5.0/1.5.1
> >         Environment: Microsoft Windows XP Professional, Version:
> 5.1.2600, Service Pack: 2.0
> > ruby 1.8.4 (2006-04-14) [i386-mswin32]
> > watir-1.5.1.1065
> >            Reporter: Zeljko
> >            Priority: Major
> >             Fix For: Soon
> >
> >
> > - go to irb
> > irb(main):001:0> require 'watir'
> > => true
> > irb(main):002:0> ie = Watir::IE.start("http://www.yahoo.com/")
> > => #<Watir::IE:0x2e54280
> > [...]
> > >
> > irb(main):003:0> ie.divs.show
> > index id                  className
> > 1
> > 2
> > [...]
> > 74
> > 75
> > => nil
> > - only indexes are printed, all ids are empty
> > - this is snippet of html of that page (divs have ids)
> > [...]
> > <div id="page">
> > <div id="masthead">
> > <div id="mastheadhd">
> > <div id="eyebrow">
> > <div class="iemw" style="width:925px;"></div>
> > [...]
>
> --
> 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
>
>
> _______________________________________________
> 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/20101103/c56786fd/attachment.html>

From jarmo.p at gmail.com  Wed Nov  3 17:47:56 2010
From: jarmo.p at gmail.com (Jarmo)
Date: Wed, 3 Nov 2010 23:47:56 +0200
Subject: [Wtr-development] [JIRA] Commented: (WTR-93) ie.divs.show not
	working
In-Reply-To: <AANLkTi=yC=_q5iAWDA7wPP+g3VWqXyOJgirkL+3UiDsZ@mail.gmail.com>
References: <1239273.515.1288808780028.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<AANLkTi=yC=_q5iAWDA7wPP+g3VWqXyOJgirkL+3UiDsZ@mail.gmail.com>
Message-ID: <AANLkTim6vzzHV-aP84K-Ncu+horgSmfS4fGDhO4aC1+D@mail.gmail.com>

Does it really matter? We all seem to agree on removing those methods...

Jarmo

On Wed, Nov 3, 2010 at 9:55 PM, Bret Pettichord <bret at pettichord.com> wrote:
> Here's my point: your comments are on the wrong ticket. Please add your
> comments/votes to the other ticket.
>
> http://jira.openqa.org/browse/WTR-255
>
> Bret
>
> On Wed, Nov 3, 2010 at 1:26 PM, Jarmo Pertman (JIRA) <watirjira at gmail.com>
> wrote:
>>
>> ? ?[
>> http://jira.openqa.org/browse/WTR-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19992#action_19992
>> ]
>>
>> Jarmo Pertman commented on WTR-93:
>> ----------------------------------
>>
>> I'm also in favor of removing those methods since they don't add any
>> additional value, but only adding additional code.
>>
>> > ie.divs.show not working
>> > ------------------------
>> >
>> > ? ? ? ? ? ? ? ? Key: WTR-93
>> > ? ? ? ? ? ? ? ? URL: http://jira.openqa.org/browse/WTR-93
>> > ? ? ? ? ? ? Project: Watir
>> > ? ? ? ? ?Issue Type: Bug
>> > ? ? ? ? ?Components: HTML Controls
>> > ? ?Affects Versions: 1.5.0/1.5.1
>> > ? ? ? ? Environment: Microsoft Windows XP Professional, Version:
>> > 5.1.2600, Service Pack: 2.0
>> > ruby 1.8.4 (2006-04-14) [i386-mswin32]
>> > watir-1.5.1.1065
>> > ? ? ? ? ? ?Reporter: Zeljko
>> > ? ? ? ? ? ?Priority: Major
>> > ? ? ? ? ? ? Fix For: Soon
>> >
>> >
>> > - go to irb
>> > irb(main):001:0> require 'watir'
>> > => true
>> > irb(main):002:0> ie = Watir::IE.start("http://www.yahoo.com/")
>> > => #<Watir::IE:0x2e54280
>> > [...]
>> > >
>> > irb(main):003:0> ie.divs.show
>> > index id ? ? ? ? ? ? ? ? ?className
>> > 1
>> > 2
>> > [...]
>> > 74
>> > 75
>> > => nil
>> > - only indexes are printed, all ids are empty
>> > - this is snippet of html of that page (divs have ids)
>> > [...]
>> > <div id="page">
>> > <div id="masthead">
>> > <div id="mastheadhd">
>> > <div id="eyebrow">
>> > <div class="iemw" style="width:925px;"></div>
>> > [...]
>>
>> --
>> 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
>>
>>
>> _______________________________________________
>> 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 watirjira at gmail.com  Fri Nov  5 15:04:20 2010
From: watirjira at gmail.com (Alan Baird (JIRA))
Date: Fri, 5 Nov 2010 14:04:20 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Created: (WTR-462) Watir::IE#close doesn't
 set @closing variable to false after closing IE
Message-ID: <1790011.523.1288983860585.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>

Watir::IE#close doesn't set @closing variable to false after closing IE
-----------------------------------------------------------------------

                 Key: WTR-462
                 URL: http://jira.openqa.org/browse/WTR-462
             Project: Watir
          Issue Type: Bug
          Components: Other
    Affects Versions: 1.6.7
         Environment: WIN XP, IE7
            Reporter: Alan Baird
            Priority: Major


All -

Consider the following example where I am trying to restart a browser using Watir's instance methods:

irb(main):001:0> require 'watir'
=> true
irb(main):002:0> br = Watir::IE.new
=> #<Watir::IE:0x2e384a4 url="about:blank" title=""> irb(main):003:0> br.goto 'google.com'
=> 1.641
irb(main):004:0> br.close
=> nil
irb(main):005:0> br._new_window_init
=> 0.422
irb(main):006:0> br.goto 'google.com'
=> 0.859
irb(main):007:0> br.close
=> nil

This actually works just fine until the last line where the browser doesn't close (but the first br.close does close the browser).  

So, I examined the close method:

    # Closes the Browser
    def close
      return unless exists?
      @closing = true
      @ie.stop
      wait rescue nil
      chwnd = @ie.hwnd.to_i
      @ie.quit
      while Win32API.new("user32","IsWindow", 'L', 'L').Call(chwnd) == 1
        sleep 0.3
      end
    end

Note that @closing is never set to false.  Thus, whenever close is called subsequently, it will return immediately because the first thing #exists? does is: 

	return false if @closing

The fix is simple, just add @closing = false to the end of #close.  I tested this in a monkeypatched version and it fixes the problem as I recreated it in IRB above.







-- 
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 Nov  5 15:13:19 2010
From: watirjira at gmail.com (Alan Baird (JIRA))
Date: Fri, 5 Nov 2010 14:13:19 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-462) Watir::IE#close
 doesn't set @closing variable to false after closing IE
In-Reply-To: <1790011.523.1288983860585.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <21760808.525.1288984399832.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Alan Baird commented on WTR-462:
--------------------------------

well, I intended to clean up the formatting on the ticket but apparently JIRA is not letting me edit my own tickets.  :(

> Watir::IE#close doesn't set @closing variable to false after closing IE
> -----------------------------------------------------------------------
>
>                 Key: WTR-462
>                 URL: http://jira.openqa.org/browse/WTR-462
>             Project: Watir
>          Issue Type: Bug
>          Components: Other
>    Affects Versions: 1.6.7
>         Environment: WIN XP, IE7
>            Reporter: Alan Baird
>            Priority: Major
>
> All -
> Consider the following example where I am trying to restart a browser using Watir's instance methods:
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> => #<Watir::IE:0x2e384a4 url="about:blank" title=""> irb(main):003:0> br.goto 'google.com'
> => 1.641
> irb(main):004:0> br.close
> => nil
> irb(main):005:0> br._new_window_init
> => 0.422
> irb(main):006:0> br.goto 'google.com'
> => 0.859
> irb(main):007:0> br.close
> => nil
> This actually works just fine until the last line where the browser doesn't close (but the first br.close does close the browser).  
> So, I examined the close method:
>     # Closes the Browser
>     def close
>       return unless exists?
>       @closing = true
>       @ie.stop
>       wait rescue nil
>       chwnd = @ie.hwnd.to_i
>       @ie.quit
>       while Win32API.new("user32","IsWindow", 'L', 'L').Call(chwnd) == 1
>         sleep 0.3
>       end
>     end
> Note that @closing is never set to false.  Thus, whenever close is called subsequently, it will return immediately because the first thing #exists? does is: 
> 	return false if @closing
> The fix is simple, just add @closing = false to the end of #close.  I tested this in a monkeypatched version and it fixes the problem as I recreated it in IRB above.

-- 
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 Nov  5 16:01:21 2010
From: watirjira at gmail.com (Jarmo Pertman (JIRA))
Date: Fri, 5 Nov 2010 15:01:21 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-462) Watir::IE#close
 doesn't set @closing variable to false after closing IE
In-Reply-To: <1790011.523.1288983860585.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <26927691.527.1288987281837.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Jarmo Pertman commented on WTR-462:
-----------------------------------

I think that using #_new_window_init like that is not intended since it is an internal method (notice the leading underscore).

But adding that one assignment statement wouldn't hurt also i guess. Although i'd put it into #_new_window_init method instead of #close because if you execute #close multiple times in a row currently then #exists? would return false for the second invocation which is the correct behavior.

> Watir::IE#close doesn't set @closing variable to false after closing IE
> -----------------------------------------------------------------------
>
>                 Key: WTR-462
>                 URL: http://jira.openqa.org/browse/WTR-462
>             Project: Watir
>          Issue Type: Bug
>          Components: Other
>    Affects Versions: 1.6.7
>         Environment: WIN XP, IE7
>            Reporter: Alan Baird
>            Priority: Major
>
> All -
> Consider the following example where I am trying to restart a browser using Watir's instance methods:
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> => #<Watir::IE:0x2e384a4 url="about:blank" title=""> irb(main):003:0> br.goto 'google.com'
> => 1.641
> irb(main):004:0> br.close
> => nil
> irb(main):005:0> br._new_window_init
> => 0.422
> irb(main):006:0> br.goto 'google.com'
> => 0.859
> irb(main):007:0> br.close
> => nil
> This actually works just fine until the last line where the browser doesn't close (but the first br.close does close the browser).  
> So, I examined the close method:
>     # Closes the Browser
>     def close
>       return unless exists?
>       @closing = true
>       @ie.stop
>       wait rescue nil
>       chwnd = @ie.hwnd.to_i
>       @ie.quit
>       while Win32API.new("user32","IsWindow", 'L', 'L').Call(chwnd) == 1
>         sleep 0.3
>       end
>     end
> Note that @closing is never set to false.  Thus, whenever close is called subsequently, it will return immediately because the first thing #exists? does is: 
> 	return false if @closing
> The fix is simple, just add @closing = false to the end of #close.  I tested this in a monkeypatched version and it fixes the problem as I recreated it in IRB above.

-- 
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 Nov  5 16:31:20 2010
From: watirjira at gmail.com (Ethan (JIRA))
Date: Fri, 5 Nov 2010 15:31:20 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-462) Watir::IE#close
 doesn't set @closing variable to false after closing IE
In-Reply-To: <1790011.523.1288983860585.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <28134621.529.1288989080247.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Ethan commented on WTR-462:
---------------------------

yeah, _new_window_init should be private. a browser object should immutably refer to one browser, I think, and closing multiple times shouldn't be an issue in that case. 

However, occasionally a call to @ie.quit does silently fail, in my experience, and #close behaves poorly then, but that's a different issue to this I think. 

> Watir::IE#close doesn't set @closing variable to false after closing IE
> -----------------------------------------------------------------------
>
>                 Key: WTR-462
>                 URL: http://jira.openqa.org/browse/WTR-462
>             Project: Watir
>          Issue Type: Bug
>          Components: Other
>    Affects Versions: 1.6.7
>         Environment: WIN XP, IE7
>            Reporter: Alan Baird
>            Priority: Major
>
> All -
> Consider the following example where I am trying to restart a browser using Watir's instance methods:
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> => #<Watir::IE:0x2e384a4 url="about:blank" title=""> irb(main):003:0> br.goto 'google.com'
> => 1.641
> irb(main):004:0> br.close
> => nil
> irb(main):005:0> br._new_window_init
> => 0.422
> irb(main):006:0> br.goto 'google.com'
> => 0.859
> irb(main):007:0> br.close
> => nil
> This actually works just fine until the last line where the browser doesn't close (but the first br.close does close the browser).  
> So, I examined the close method:
>     # Closes the Browser
>     def close
>       return unless exists?
>       @closing = true
>       @ie.stop
>       wait rescue nil
>       chwnd = @ie.hwnd.to_i
>       @ie.quit
>       while Win32API.new("user32","IsWindow", 'L', 'L').Call(chwnd) == 1
>         sleep 0.3
>       end
>     end
> Note that @closing is never set to false.  Thus, whenever close is called subsequently, it will return immediately because the first thing #exists? does is: 
> 	return false if @closing
> The fix is simple, just add @closing = false to the end of #close.  I tested this in a monkeypatched version and it fixes the problem as I recreated it in IRB above.

-- 
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 tim.koops at gmail.com  Fri Nov  5 16:47:06 2010
From: tim.koops at gmail.com (Tim Koopmans)
Date: Sat, 6 Nov 2010 07:47:06 +1100
Subject: [Wtr-development] [JIRA] Commented: (WTR-462) Watir::IE#close
 doesn't set @closing variable to false after closing IE
In-Reply-To: <21760808.525.1288984399832.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
References: <1790011.523.1288983860585.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
	<21760808.525.1288984399832.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <AANLkTimEQOdYm+BmmPLCwo+8Qr7KaHgR-0DV8ib+m-XF@mail.gmail.com>

On 11/6/10, Alan Baird (JIRA) <watirjira at gmail.com> wrote:
>
>     [
> http://jira.openqa.org/browse/WTR-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19993#action_19993
> ]
>
> Alan Baird commented on WTR-462:
> --------------------------------
>
> well, I intended to clean up the formatting on the ticket but apparently
> JIRA is not letting me edit my own tickets.  :(
>
>> Watir::IE#close doesn't set @closing variable to false after closing IE
>> -----------------------------------------------------------------------
>>
>>                 Key: WTR-462
>>                 URL: http://jira.openqa.org/browse/WTR-462
>>             Project: Watir
>>          Issue Type: Bug
>>          Components: Other
>>    Affects Versions: 1.6.7
>>         Environment: WIN XP, IE7
>>            Reporter: Alan Baird
>>            Priority: Major
>>
>> All -
>> Consider the following example where I am trying to restart a browser
>> using Watir's instance methods:
>> irb(main):001:0> require 'watir'
>> => true
>> irb(main):002:0> br = Watir::IE.new
>> => #<Watir::IE:0x2e384a4 url="about:blank" title=""> irb(main):003:0>
>> br.goto 'google.com'
>> => 1.641
>> irb(main):004:0> br.close
>> => nil
>> irb(main):005:0> br._new_window_init
>> => 0.422
>> irb(main):006:0> br.goto 'google.com'
>> => 0.859
>> irb(main):007:0> br.close
>> => nil
>> This actually works just fine until the last line where the browser
>> doesn't close (but the first br.close does close the browser).
>> So, I examined the close method:
>>     # Closes the Browser
>>     def close
>>       return unless exists?
>>       @closing = true
>>       @ie.stop
>>       wait rescue nil
>>       chwnd = @ie.hwnd.to_i
>>       @ie.quit
>>       while Win32API.new("user32","IsWindow", 'L', 'L').Call(chwnd) == 1
>>         sleep 0.3
>>       end
>>     end
>> Note that @closing is never set to false.  Thus, whenever close is called
>> subsequently, it will return immediately because the first thing #exists?
>> does is:
>> 	return false if @closing
>> The fix is simple, just add @closing = false to the end of #close.  I
>> tested this in a monkeypatched version and it fixes the problem as I
>> recreated it in IRB above.
>
> --
> 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
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>

-- 
Sent from my mobile device

Cheers,
Tim

From watirjira at gmail.com  Fri Nov  5 17:29:20 2010
From: watirjira at gmail.com (Alan Baird (JIRA))
Date: Fri, 5 Nov 2010 16:29:20 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-462) Watir::IE#close
 doesn't set @closing variable to false after closing IE
In-Reply-To: <1790011.523.1288983860585.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <2497929.531.1288992560174.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Alan Baird commented on WTR-462:
--------------------------------

If _new_window_init is supposed to be a private method, then why isn't it explicitly private like Watir::IE#create_browser_window?

And, if it's intended to be private, why?  If you do Watir::IE.new, and then #close, you have effectively killed that instance of Watir::IE (assuming it closes correctly) since it can't be legitimately restarted without calling _new_window_init.  You can call new again, but that defeats my purpose in trying to restart IE without invalidating the instance of Watir::IE.  

Maybe there is a really good reason for this that I am unaware of, but I'd like to know what it is, as it would give me a legitimate reason to tell people never to subclass Watir.

> Watir::IE#close doesn't set @closing variable to false after closing IE
> -----------------------------------------------------------------------
>
>                 Key: WTR-462
>                 URL: http://jira.openqa.org/browse/WTR-462
>             Project: Watir
>          Issue Type: Bug
>          Components: Other
>    Affects Versions: 1.6.7
>         Environment: WIN XP, IE7
>            Reporter: Alan Baird
>            Priority: Major
>
> All -
> Consider the following example where I am trying to restart a browser using Watir's instance methods:
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> => #<Watir::IE:0x2e384a4 url="about:blank" title=""> irb(main):003:0> br.goto 'google.com'
> => 1.641
> irb(main):004:0> br.close
> => nil
> irb(main):005:0> br._new_window_init
> => 0.422
> irb(main):006:0> br.goto 'google.com'
> => 0.859
> irb(main):007:0> br.close
> => nil
> This actually works just fine until the last line where the browser doesn't close (but the first br.close does close the browser).  
> So, I examined the close method:
>     # Closes the Browser
>     def close
>       return unless exists?
>       @closing = true
>       @ie.stop
>       wait rescue nil
>       chwnd = @ie.hwnd.to_i
>       @ie.quit
>       while Win32API.new("user32","IsWindow", 'L', 'L').Call(chwnd) == 1
>         sleep 0.3
>       end
>     end
> Note that @closing is never set to false.  Thus, whenever close is called subsequently, it will return immediately because the first thing #exists? does is: 
> 	return false if @closing
> The fix is simple, just add @closing = false to the end of #close.  I tested this in a monkeypatched version and it fixes the problem as I recreated it in IRB above.

-- 
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 Nov  5 18:10:20 2010
From: watirjira at gmail.com (Charley Baker (JIRA))
Date: Fri, 5 Nov 2010 17:10:20 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-462) Watir::IE#close
 doesn't set @closing variable to false after closing IE
In-Reply-To: <1790011.523.1288983860585.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <23433350.533.1288995020031.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Charley Baker commented on WTR-462:
-----------------------------------

laziness, convention, take your pick. You should avoid _method names when calling, that is the convention. That being said, we should probably make this private. 

Alan, I'm not sure what you're intending to do, yes it's closing that instance, and good point about the @closing var, I can add that or you can do a pull request. 

Missed your point about subclassing Watir, you mean monkey patching or something else? I highly wouldn't recommend subclassing anything. 

> Watir::IE#close doesn't set @closing variable to false after closing IE
> -----------------------------------------------------------------------
>
>                 Key: WTR-462
>                 URL: http://jira.openqa.org/browse/WTR-462
>             Project: Watir
>          Issue Type: Bug
>          Components: Other
>    Affects Versions: 1.6.7
>         Environment: WIN XP, IE7
>            Reporter: Alan Baird
>            Priority: Major
>
> All -
> Consider the following example where I am trying to restart a browser using Watir's instance methods:
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> => #<Watir::IE:0x2e384a4 url="about:blank" title=""> irb(main):003:0> br.goto 'google.com'
> => 1.641
> irb(main):004:0> br.close
> => nil
> irb(main):005:0> br._new_window_init
> => 0.422
> irb(main):006:0> br.goto 'google.com'
> => 0.859
> irb(main):007:0> br.close
> => nil
> This actually works just fine until the last line where the browser doesn't close (but the first br.close does close the browser).  
> So, I examined the close method:
>     # Closes the Browser
>     def close
>       return unless exists?
>       @closing = true
>       @ie.stop
>       wait rescue nil
>       chwnd = @ie.hwnd.to_i
>       @ie.quit
>       while Win32API.new("user32","IsWindow", 'L', 'L').Call(chwnd) == 1
>         sleep 0.3
>       end
>     end
> Note that @closing is never set to false.  Thus, whenever close is called subsequently, it will return immediately because the first thing #exists? does is: 
> 	return false if @closing
> The fix is simple, just add @closing = false to the end of #close.  I tested this in a monkeypatched version and it fixes the problem as I recreated it in IRB above.

-- 
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 Nov  6 01:42:20 2010
From: watirjira at gmail.com (Ethan (JIRA))
Date: Sat, 6 Nov 2010 00:42:20 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-462) Watir::IE#close
 doesn't set @closing variable to false after closing IE
In-Reply-To: <1790011.523.1288983860585.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <18716517.536.1289022140819.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Ethan commented on WTR-462:
---------------------------

"You can call new again, but that defeats my purpose in trying to restart IE without invalidating the instance of Watir::IE." 

I can't think why it would preferable to change an existing instance of the Watir::IE class to point to a different browser, as opposed to just calling IE.new. 

> Watir::IE#close doesn't set @closing variable to false after closing IE
> -----------------------------------------------------------------------
>
>                 Key: WTR-462
>                 URL: http://jira.openqa.org/browse/WTR-462
>             Project: Watir
>          Issue Type: Bug
>          Components: Other
>    Affects Versions: 1.6.7
>         Environment: WIN XP, IE7
>            Reporter: Alan Baird
>            Priority: Major
>
> All -
> Consider the following example where I am trying to restart a browser using Watir's instance methods:
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> => #<Watir::IE:0x2e384a4 url="about:blank" title=""> irb(main):003:0> br.goto 'google.com'
> => 1.641
> irb(main):004:0> br.close
> => nil
> irb(main):005:0> br._new_window_init
> => 0.422
> irb(main):006:0> br.goto 'google.com'
> => 0.859
> irb(main):007:0> br.close
> => nil
> This actually works just fine until the last line where the browser doesn't close (but the first br.close does close the browser).  
> So, I examined the close method:
>     # Closes the Browser
>     def close
>       return unless exists?
>       @closing = true
>       @ie.stop
>       wait rescue nil
>       chwnd = @ie.hwnd.to_i
>       @ie.quit
>       while Win32API.new("user32","IsWindow", 'L', 'L').Call(chwnd) == 1
>         sleep 0.3
>       end
>     end
> Note that @closing is never set to false.  Thus, whenever close is called subsequently, it will return immediately because the first thing #exists? does is: 
> 	return false if @closing
> The fix is simple, just add @closing = false to the end of #close.  I tested this in a monkeypatched version and it fixes the problem as I recreated it in IRB above.

-- 
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 Nov  6 23:37:20 2010
From: watirjira at gmail.com (Alan Baird (JIRA))
Date: Sat, 6 Nov 2010 22:37:20 -0500 (CDT)
Subject: [Wtr-development] [JIRA] Commented: (WTR-462) Watir::IE#close
 doesn't set @closing variable to false after closing IE
In-Reply-To: <1790011.523.1288983860585.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <3833741.539.1289101040604.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Alan Baird commented on WTR-462:
--------------------------------

Simplified quite a lot, this is the design of one of the frameworks we are using:

class MyFramework < Watir::IE
  def initialize
    super
  end
  def goto_google
    goto 'google.com'
  end
  def recycle_browser
    close
    _new_window_init
  end
end

I never liked this design, but I inherited it and have to live with it.  It would be nice, for reasons that aren't worth going into, for the MyFramework class to handle it's own browser if it detected an error and needed to restart itself.  That's why I asked the question, since I couldn't really tell if restarting the underlying IE instance without getting a new Watir::IE instance was something that *should* be done or not.

I prefer to design frameworks that use Watir with a pointer to an instance of Watir, more like this:

class MyFramework
  attr_accessor :br  
  def initialize
    @br = Watir::IE.new
  end
  def goto_google
    @br.goto 'google.com'
  end
  def recycle_browser
    @br.close
    @br = Watir::IE.new
  end
end

Mind you, these are really simplistic, I'm just trying to show the concept.  However, I have been in arguments where people don't like typing all the @br's in the second example and want to use the first.  To me, this issue (not being able to restart IE out from under an instance of Watir::IE) it a good argument for designing it the 2nd way.

Sorry for the long winded explanation.  At the very least, I think close should end with setting @closing since there is already a wait in there for IE.  I will try to send a pull request soon.
    

> Watir::IE#close doesn't set @closing variable to false after closing IE
> -----------------------------------------------------------------------
>
>                 Key: WTR-462
>                 URL: http://jira.openqa.org/browse/WTR-462
>             Project: Watir
>          Issue Type: Bug
>          Components: Other
>    Affects Versions: 1.6.7
>         Environment: WIN XP, IE7
>            Reporter: Alan Baird
>            Priority: Major
>
> All -
> Consider the following example where I am trying to restart a browser using Watir's instance methods:
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> => #<Watir::IE:0x2e384a4 url="about:blank" title=""> irb(main):003:0> br.goto 'google.com'
> => 1.641
> irb(main):004:0> br.close
> => nil
> irb(main):005:0> br._new_window_init
> => 0.422
> irb(main):006:0> br.goto 'google.com'
> => 0.859
> irb(main):007:0> br.close
> => nil
> This actually works just fine until the last line where the browser doesn't close (but the first br.close does close the browser).  
> So, I examined the close method:
>     # Closes the Browser
>     def close
>       return unless exists?
>       @closing = true
>       @ie.stop
>       wait rescue nil
>       chwnd = @ie.hwnd.to_i
>       @ie.quit
>       while Win32API.new("user32","IsWindow", 'L', 'L').Call(chwnd) == 1
>         sleep 0.3
>       end
>     end
> Note that @closing is never set to false.  Thus, whenever close is called subsequently, it will return immediately because the first thing #exists? does is: 
> 	return false if @closing
> The fix is simple, just add @closing = false to the end of #close.  I tested this in a monkeypatched version and it fixes the problem as I recreated it in IRB above.

-- 
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 alister.scott at gmail.com  Mon Nov  8 01:11:01 2010
From: alister.scott at gmail.com (Alister Scott)
Date: Mon, 8 Nov 2010 16:11:01 +1000
Subject: [Wtr-development] fire_event 'onchange' intermittently timing out?
Message-ID: <AANLkTimPSoUWs-udRCV6ERTie3cVNT5NcS2HFKypzms2@mail.gmail.com>

Hi,

I am testing an AJAX heavy web app which uses 'onchange' events on text
fields. Approx one tenth of the time, when I fire an onchange event using
fire_event, it causes Watir to timeout for 5 minutes.

For example:

When I set "Letter" to "Blah"                                             #
features/step_definitions/input_text_steps.rb:7

   execution expired (Timeout::Error)

C:/Sandbox/Tools/ruby-1.8.7-p302-i386-mingw32/lib/ruby/1.8/timeout.rb:64:in
`wait'
   ./features/support/../../lib/blah/form.rb:38:in `[]='
   ./features/step_definitions/input_text_steps.rb:8:in `/^I set "([^"]*)"
to "([^"]*)"$/'
   features\sociability\blah\blah.feature:45:in `When I set "Letter" to
"blah"'

I traced this down the the element.rb file, and have monkey patched this
class to remove the @container.wait, but I was wondering if there is a
better way? As it only happens about 10% of the time, it makes it hard to
debug, but removing the wait from fire_event seems to have resolved the
issue. I thought about catching the Timeout::Error, but I don't want my
script to freeze for 5 minutes at a time.

Any help would be appreciated.

    def fire_event(event)
      assert_exists
      assert_enabled

     highlight(:set)
     ole_object.fireEvent(event)
      #@container.wait
      highlight(:clear)
   end

Cheers,

Alister
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20101108/19affe55/attachment.html>

From jarmo.p at gmail.com  Mon Nov  8 06:40:06 2010
From: jarmo.p at gmail.com (Jarmo)
Date: Mon, 8 Nov 2010 13:40:06 +0200
Subject: [Wtr-development] fire_event 'onchange' intermittently timing
	out?
In-Reply-To: <AANLkTimPSoUWs-udRCV6ERTie3cVNT5NcS2HFKypzms2@mail.gmail.com>
References: <AANLkTimPSoUWs-udRCV6ERTie3cVNT5NcS2HFKypzms2@mail.gmail.com>
Message-ID: <AANLkTikmHvP37WJHb1SH2MJ1Xc2uRjPqNOiqVCcOrZi4@mail.gmail.com>

Removing @container.wait is definitely not going to solve the problem
since there could be some events which should wait. You could try to
add some sleep statements before fire_event and also provide us with
the stack where that timeout exactly occurs.

Jarmo

On Mon, Nov 8, 2010 at 8:11 AM, Alister Scott <alister.scott at gmail.com> wrote:
> Hi,
>
> I am testing an AJAX heavy web app which uses 'onchange' events on text
> fields. Approx one tenth of the time, when I fire an onchange event using
> fire_event, it causes Watir to timeout for 5 minutes.
>
> For example:
>
> When I set "Letter" to "Blah"???????????????????????????????????????????? #
> features/step_definitions/input_text_steps.rb:7
>
> ?? execution expired (Timeout::Error)
>
> C:/Sandbox/Tools/ruby-1.8.7-p302-i386-mingw32/lib/ruby/1.8/timeout.rb:64:in
> `wait'
> ?? ./features/support/../../lib/blah/form.rb:38:in `[]='
> ?? ./features/step_definitions/input_text_steps.rb:8:in `/^I set "([^"]*)"
> to "([^"]*)"$/'
> ?? features\sociability\blah\blah.feature:45:in `When I set "Letter" to
> "blah"'
>
> I traced this down the the element.rb file, and have monkey patched this
> class to remove the @container.wait, but I was wondering if there is a
> better way? As it only happens about 10% of the time, it makes it hard to
> debug, but removing the wait from fire_event seems to have resolved the
> issue. I thought about catching the Timeout::Error, but I don't want my
> script to freeze for 5 minutes at a time.
>
> Any help would be appreciated.
>
> ??? def fire_event(event)
> ????? assert_exists
> ????? assert_enabled
>
> ???? highlight(:set)
> ???? ole_object.fireEvent(event)
> ? ? ? #@container.wait
> ? ? ? highlight(:clear)
> ?? end
>
> Cheers,
>
> Alister
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>

From watirjira at gmail.com  Mon Nov  8 13:20:20 2010
From: watirjira at gmail.com (Alan Baird (JIRA))
Date: Mon, 8 Nov 2010 12:20:20 -0600 (CST)
Subject: [Wtr-development] [JIRA] Created: (WTR-463) close_all throws
	exception in Watir 1.6.7
Message-ID: <5370673.548.1289240420022.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>

close_all throws exception in Watir 1.6.7
-----------------------------------------

                 Key: WTR-463
                 URL: http://jira.openqa.org/browse/WTR-463
             Project: Watir
          Issue Type: Bug
          Components: Wait
    Affects Versions: 1.6.7
         Environment: Windows XP, IE7
            Reporter: Alan Baird
            Priority: Critical


Watir::IE.close_all appears to be broken in 1.6.7 (it's possible it's broke in 1.6.6 but I don't think this was changed in 1.6.6).  Consider the following code.  I have addded a line in Watir::Exception.until_with_timeout to record the timeout that is being passed to Wait.until in line 10 of module.rb.  This clearly shows that 0 is being passed to Wait.until.  This causes the unexpected Watir::Wait::TimeoutError.
{code}
N:\gauntlet>irb --noreadline
irb(main):001:0> require 'watir'
=> true
irb(main):002:0> br = Watir::IE.new
=> #<Watir::IE:0x4108a48 url="about:blank" title="">
irb(main):003:0> br.close
=> false
irb(main):004:0> br = Watir::IE.new
=> #<Watir::IE:0x40f6de8 url="about:blank" title="">
irb(main):005:0> Watir::IE.close_all
the attach timeout is 0
Watir::Wait::TimeoutError: timed out after 0 seconds
        from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/wait.rb:23:in `until'
        from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/module.rb:11:in `until_with_timeout'
        from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:16:in `find_modal_from_window'
        from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:36:in `locate'
        from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:86:in `initialize'
        from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/container.rb:188:in `new'
        from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/container.rb:188:in `modal_dialog'
        from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:29:in `close_modal'
        from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:16:in `close_all_but'
        from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/ie-class.rb:245:in `each'
        from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/ie-class.rb:240:in `each'
        from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:15:in `close_all_but'
        from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:7:in `close_all'
        from (irb):5
irb(main):006:0> puts Watir::IE.attach_timeout
2.0
=> nil
{code}
The culprit, I believe, is Watir::IE#close_modal: 
{code}
# close modal dialog. unlike IE#modal_dialog.close, does not wait for dialog
# to appear and does not raise exception if no window is found.
# returns true if modal was found and close, otherwise false
def close_modal
  begin
    original_attach_timeout = IE.attach_timeout
    IE.attach_timeout = 0
    self.modal_dialog.close
    true
  rescue NoMatchingWindowFoundException, TimeOutException
    false
  ensure
    IE.attach_timeout = original_attach_timeout
  end
end
{code}
What's weird is that it specifically states in the comment that this should not raise an exception but it clearly is.  The reason is that line 28 in close_all.rb sets the IE.attach_timeout to 0.  I tried commenting out this line but it still raises a Watir::Wait::TimeoutError.

-- 
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  Mon Nov  8 14:15:19 2010
From: watirjira at gmail.com (Alan Baird (JIRA))
Date: Mon, 8 Nov 2010 13:15:19 -0600 (CST)
Subject: [Wtr-development] [JIRA] Created: (WTR-464) uninstalling watir
 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
Message-ID: <25628117.550.1289243719870.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>

uninstalling watir 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
---------------------------------------------------------------------------------

                 Key: WTR-464
                 URL: http://jira.openqa.org/browse/WTR-464
             Project: Watir
          Issue Type: Bug
          Components: Gem installer
    Affects Versions: 1.6.7
         Environment: win xp ie7
            Reporter: Alan Baird
            Priority: Major


After uninstalling watir 1.6.7, and installing watir 1.6.6, Watir throws a LoadError trying to load watir/ie.  I looked at the versions that were installed and noticed that commonwatir and firewatir did not get uninstalled when Watir::IE was uninstalled.  The workaround is to manually uninstall commonwatir and firewatir.

N:\gauntlet>irb --noreadline
irb(main):001:0> require 'watir'
=> true
irb(main):002:0> br = Watir::IE.new
LoadError: no such file to load -- watir/ie
        from (irb):2
irb(main):003:0> br = Watir::Browser.new
Watir::Exception::UnableToStartJSShException: Unable to connect to machine : 127.0.0.1 on port 9997. Make sure that JSSh is properly installed and Fir
efox is running with '-jssh' option
        from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:156:in `set_defaults'
        from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:50:in `initialize'
        from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
        from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
        from (irb):3
irb(main):004:0> exit

# uninstall commonwatir and firewatir

N:\gauntlet>gem uninstall commonwatir -v 1.6.7

You have requested to uninstall the gem:
        commonwatir-1.6.7
firewatir-1.6.7 depends on [commonwatir (= 1.6.7)]
If you remove this gems, one or more dependencies will not be met.
Continue with Uninstall? [Yn]  y
Successfully uninstalled commonwatir-1.6.7

N:\gauntlet>gem uninstall firewatir -v 1.6.7
Successfully uninstalled firewatir-1.6.7

# test to see if Watir works

N:\gauntlet>irb --noreadline
irb(main):001:0> require 'watir'
=> true
irb(main):002:0> br = Watir::Browser.new
=> #<Watir::IE:0x40f7d88 url="about:blank" title="">
irb(main):003:0> br.close
=> nil
irb(main):004:0> br = Watir::IE.new
=> #<Watir::IE:0x40f0e84 url="about:blank" 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  Mon Nov  8 14:26:19 2010
From: watirjira at gmail.com (Charley Baker (JIRA))
Date: Mon, 8 Nov 2010 13:26:19 -0600 (CST)
Subject: [Wtr-development] [JIRA] Commented: (WTR-464) uninstalling watir
 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
In-Reply-To: <25628117.550.1289243719870.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <25650595.552.1289244379780.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Charley Baker commented on WTR-464:
-----------------------------------

True. Unless anyone has a better idea, this is the way gems work currently, dependent gems don't get uninstalled. My best fix for this would be document it on the wiki for people who want to roll back. 

This is not a bug, but a request for documentation which you've shown and needs to go on the wiki. 


> uninstalling watir 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
> ---------------------------------------------------------------------------------
>
>                 Key: WTR-464
>                 URL: http://jira.openqa.org/browse/WTR-464
>             Project: Watir
>          Issue Type: Bug
>          Components: Gem installer
>    Affects Versions: 1.6.7
>         Environment: win xp ie7
>            Reporter: Alan Baird
>            Priority: Major
>
> After uninstalling watir 1.6.7, and installing watir 1.6.6, Watir throws a LoadError trying to load watir/ie.  I looked at the versions that were installed and noticed that commonwatir and firewatir did not get uninstalled when Watir::IE was uninstalled.  The workaround is to manually uninstall commonwatir and firewatir.
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> LoadError: no such file to load -- watir/ie
>         from (irb):2
> irb(main):003:0> br = Watir::Browser.new
> Watir::Exception::UnableToStartJSShException: Unable to connect to machine : 127.0.0.1 on port 9997. Make sure that JSSh is properly installed and Fir
> efox is running with '-jssh' option
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:156:in `set_defaults'
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:50:in `initialize'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from (irb):3
> irb(main):004:0> exit
> # uninstall commonwatir and firewatir
> N:\gauntlet>gem uninstall commonwatir -v 1.6.7
> You have requested to uninstall the gem:
>         commonwatir-1.6.7
> firewatir-1.6.7 depends on [commonwatir (= 1.6.7)]
> If you remove this gems, one or more dependencies will not be met.
> Continue with Uninstall? [Yn]  y
> Successfully uninstalled commonwatir-1.6.7
> N:\gauntlet>gem uninstall firewatir -v 1.6.7
> Successfully uninstalled firewatir-1.6.7
> # test to see if Watir works
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::Browser.new
> => #<Watir::IE:0x40f7d88 url="about:blank" title="">
> irb(main):003:0> br.close
> => nil
> irb(main):004:0> br = Watir::IE.new
> => #<Watir::IE:0x40f0e84 url="about:blank" 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  Mon Nov  8 14:28:19 2010
From: watirjira at gmail.com (Jarmo Pertman (JIRA))
Date: Mon, 8 Nov 2010 13:28:19 -0600 (CST)
Subject: [Wtr-development] [JIRA] Commented: (WTR-464) uninstalling watir
 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
In-Reply-To: <25628117.550.1289243719870.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <8125971.554.1289244499897.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Jarmo Pertman commented on WTR-464:
-----------------------------------

I'm not sure that you can uninstall some gem and it's dependencies. And remember that commonwatir is a dependency for firewatir and watir and not vice versa.

Same thing is with RSpec 2 for example - you'd have to uninstall every component of RSpec separately if you'd like to do that.

By the way, you can load specific version of a gem if needed:
{noformat}
C:\Users\jarmo>gem list | grep watir
commonwatir (1.6.7, 1.6.6)
firewatir (1.6.7, 1.6.6)
watir (1.6.7, 1.6.6)

C:\Users\jarmo>irb
irb(main):001:0> gem "watir", "1.6.6"
=> true
irb(main):002:0> require "watir"
=> true
irb(main):003:0> Gem.loaded_specs["watir"].version.to_s
=> "1.6.6"
{noformat}

I think that this is more of a bug/feature request to RubyGems instead than Watir. In this light closing the issue.

> uninstalling watir 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
> ---------------------------------------------------------------------------------
>
>                 Key: WTR-464
>                 URL: http://jira.openqa.org/browse/WTR-464
>             Project: Watir
>          Issue Type: Bug
>          Components: Gem installer
>    Affects Versions: 1.6.7
>         Environment: win xp ie7
>            Reporter: Alan Baird
>            Priority: Major
>
> After uninstalling watir 1.6.7, and installing watir 1.6.6, Watir throws a LoadError trying to load watir/ie.  I looked at the versions that were installed and noticed that commonwatir and firewatir did not get uninstalled when Watir::IE was uninstalled.  The workaround is to manually uninstall commonwatir and firewatir.
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> LoadError: no such file to load -- watir/ie
>         from (irb):2
> irb(main):003:0> br = Watir::Browser.new
> Watir::Exception::UnableToStartJSShException: Unable to connect to machine : 127.0.0.1 on port 9997. Make sure that JSSh is properly installed and Fir
> efox is running with '-jssh' option
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:156:in `set_defaults'
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:50:in `initialize'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from (irb):3
> irb(main):004:0> exit
> # uninstall commonwatir and firewatir
> N:\gauntlet>gem uninstall commonwatir -v 1.6.7
> You have requested to uninstall the gem:
>         commonwatir-1.6.7
> firewatir-1.6.7 depends on [commonwatir (= 1.6.7)]
> If you remove this gems, one or more dependencies will not be met.
> Continue with Uninstall? [Yn]  y
> Successfully uninstalled commonwatir-1.6.7
> N:\gauntlet>gem uninstall firewatir -v 1.6.7
> Successfully uninstalled firewatir-1.6.7
> # test to see if Watir works
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::Browser.new
> => #<Watir::IE:0x40f7d88 url="about:blank" title="">
> irb(main):003:0> br.close
> => nil
> irb(main):004:0> br = Watir::IE.new
> => #<Watir::IE:0x40f0e84 url="about:blank" 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  Mon Nov  8 14:28:19 2010
From: watirjira at gmail.com (Jarmo Pertman (JIRA))
Date: Mon, 8 Nov 2010 13:28:19 -0600 (CST)
Subject: [Wtr-development] [JIRA] Closed: (WTR-464) uninstalling watir 1.6.7
 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
In-Reply-To: <25628117.550.1289243719870.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <23394360.556.1289244499927.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Jarmo Pertman closed WTR-464.
-----------------------------

    Resolution: Not a problem

> uninstalling watir 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
> ---------------------------------------------------------------------------------
>
>                 Key: WTR-464
>                 URL: http://jira.openqa.org/browse/WTR-464
>             Project: Watir
>          Issue Type: Bug
>          Components: Gem installer
>    Affects Versions: 1.6.7
>         Environment: win xp ie7
>            Reporter: Alan Baird
>            Priority: Major
>
> After uninstalling watir 1.6.7, and installing watir 1.6.6, Watir throws a LoadError trying to load watir/ie.  I looked at the versions that were installed and noticed that commonwatir and firewatir did not get uninstalled when Watir::IE was uninstalled.  The workaround is to manually uninstall commonwatir and firewatir.
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> LoadError: no such file to load -- watir/ie
>         from (irb):2
> irb(main):003:0> br = Watir::Browser.new
> Watir::Exception::UnableToStartJSShException: Unable to connect to machine : 127.0.0.1 on port 9997. Make sure that JSSh is properly installed and Fir
> efox is running with '-jssh' option
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:156:in `set_defaults'
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:50:in `initialize'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from (irb):3
> irb(main):004:0> exit
> # uninstall commonwatir and firewatir
> N:\gauntlet>gem uninstall commonwatir -v 1.6.7
> You have requested to uninstall the gem:
>         commonwatir-1.6.7
> firewatir-1.6.7 depends on [commonwatir (= 1.6.7)]
> If you remove this gems, one or more dependencies will not be met.
> Continue with Uninstall? [Yn]  y
> Successfully uninstalled commonwatir-1.6.7
> N:\gauntlet>gem uninstall firewatir -v 1.6.7
> Successfully uninstalled firewatir-1.6.7
> # test to see if Watir works
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::Browser.new
> => #<Watir::IE:0x40f7d88 url="about:blank" title="">
> irb(main):003:0> br.close
> => nil
> irb(main):004:0> br = Watir::IE.new
> => #<Watir::IE:0x40f0e84 url="about:blank" 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  Mon Nov  8 15:26:19 2010
From: watirjira at gmail.com (Alan Baird (JIRA))
Date: Mon, 8 Nov 2010 14:26:19 -0600 (CST)
Subject: [Wtr-development] [JIRA] Commented: (WTR-464) uninstalling watir
 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
In-Reply-To: <25628117.550.1289243719870.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <8587898.558.1289247979822.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Alan Baird commented on WTR-464:
--------------------------------

Ok, well, let me ask this question.  Would there ever be a reason why you would run different versions of commonwatir, firewatir and/or watir?  If there is not, maybe it would be a good idea to warn people by checking the different versions, and if they aren't the same, sending them a message like, "Your versions should be the same and they are not".

At any rate, I will put it on the wiki.

> uninstalling watir 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
> ---------------------------------------------------------------------------------
>
>                 Key: WTR-464
>                 URL: http://jira.openqa.org/browse/WTR-464
>             Project: Watir
>          Issue Type: Bug
>          Components: Gem installer
>    Affects Versions: 1.6.7
>         Environment: win xp ie7
>            Reporter: Alan Baird
>            Priority: Major
>
> After uninstalling watir 1.6.7, and installing watir 1.6.6, Watir throws a LoadError trying to load watir/ie.  I looked at the versions that were installed and noticed that commonwatir and firewatir did not get uninstalled when Watir::IE was uninstalled.  The workaround is to manually uninstall commonwatir and firewatir.
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> LoadError: no such file to load -- watir/ie
>         from (irb):2
> irb(main):003:0> br = Watir::Browser.new
> Watir::Exception::UnableToStartJSShException: Unable to connect to machine : 127.0.0.1 on port 9997. Make sure that JSSh is properly installed and Fir
> efox is running with '-jssh' option
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:156:in `set_defaults'
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:50:in `initialize'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from (irb):3
> irb(main):004:0> exit
> # uninstall commonwatir and firewatir
> N:\gauntlet>gem uninstall commonwatir -v 1.6.7
> You have requested to uninstall the gem:
>         commonwatir-1.6.7
> firewatir-1.6.7 depends on [commonwatir (= 1.6.7)]
> If you remove this gems, one or more dependencies will not be met.
> Continue with Uninstall? [Yn]  y
> Successfully uninstalled commonwatir-1.6.7
> N:\gauntlet>gem uninstall firewatir -v 1.6.7
> Successfully uninstalled firewatir-1.6.7
> # test to see if Watir works
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::Browser.new
> => #<Watir::IE:0x40f7d88 url="about:blank" title="">
> irb(main):003:0> br.close
> => nil
> irb(main):004:0> br = Watir::IE.new
> => #<Watir::IE:0x40f0e84 url="about:blank" 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  Mon Nov  8 16:03:20 2010
From: watirjira at gmail.com (Jarmo Pertman (JIRA))
Date: Mon, 8 Nov 2010 15:03:20 -0600 (CST)
Subject: [Wtr-development] [JIRA] Reopened: (WTR-464) uninstalling watir
 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
In-Reply-To: <25628117.550.1289243719870.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <10589389.561.1289250200617.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Jarmo Pertman reopened WTR-464:
-------------------------------

      Assignee: Jarmo Pertman

I've started to think about that problem a little more and now cannot see any reason why you're seeing the "no such file to load" error message if you have 1.6.6 installed since the autoloading code in commonwatir doesn't seem to care about the version (although it should)... reopening this issue in that light, dang this ruined the fastest close of an issue in the history :P

make commonwatir's autoload to try to load correct version of a library

but instead of writing this kind of thing into the wiki i'd be more interested to know why is someone downgrading in the first place - are there any critical problems or whatnot etc.

> uninstalling watir 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
> ---------------------------------------------------------------------------------
>
>                 Key: WTR-464
>                 URL: http://jira.openqa.org/browse/WTR-464
>             Project: Watir
>          Issue Type: Bug
>          Components: Gem installer
>    Affects Versions: 1.6.7
>         Environment: win xp ie7
>            Reporter: Alan Baird
>            Assignee: Jarmo Pertman
>            Priority: Major
>
> After uninstalling watir 1.6.7, and installing watir 1.6.6, Watir throws a LoadError trying to load watir/ie.  I looked at the versions that were installed and noticed that commonwatir and firewatir did not get uninstalled when Watir::IE was uninstalled.  The workaround is to manually uninstall commonwatir and firewatir.
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> LoadError: no such file to load -- watir/ie
>         from (irb):2
> irb(main):003:0> br = Watir::Browser.new
> Watir::Exception::UnableToStartJSShException: Unable to connect to machine : 127.0.0.1 on port 9997. Make sure that JSSh is properly installed and Fir
> efox is running with '-jssh' option
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:156:in `set_defaults'
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:50:in `initialize'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from (irb):3
> irb(main):004:0> exit
> # uninstall commonwatir and firewatir
> N:\gauntlet>gem uninstall commonwatir -v 1.6.7
> You have requested to uninstall the gem:
>         commonwatir-1.6.7
> firewatir-1.6.7 depends on [commonwatir (= 1.6.7)]
> If you remove this gems, one or more dependencies will not be met.
> Continue with Uninstall? [Yn]  y
> Successfully uninstalled commonwatir-1.6.7
> N:\gauntlet>gem uninstall firewatir -v 1.6.7
> Successfully uninstalled firewatir-1.6.7
> # test to see if Watir works
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::Browser.new
> => #<Watir::IE:0x40f7d88 url="about:blank" title="">
> irb(main):003:0> br.close
> => nil
> irb(main):004:0> br = Watir::IE.new
> => #<Watir::IE:0x40f0e84 url="about:blank" 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  Mon Nov  8 16:05:19 2010
From: watirjira at gmail.com (Jarmo Pertman (JIRA))
Date: Mon, 8 Nov 2010 15:05:19 -0600 (CST)
Subject: [Wtr-development] [JIRA] Assigned: (WTR-463) close_all throws
 exception in Watir 1.6.7
In-Reply-To: <5370673.548.1289240420022.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <31890528.564.1289250319868.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Jarmo Pertman reassigned WTR-463:
---------------------------------

    Assignee: Jarmo Pertman

> close_all throws exception in Watir 1.6.7
> -----------------------------------------
>
>                 Key: WTR-463
>                 URL: http://jira.openqa.org/browse/WTR-463
>             Project: Watir
>          Issue Type: Bug
>          Components: Wait
>    Affects Versions: 1.6.7
>         Environment: Windows XP, IE7
>            Reporter: Alan Baird
>            Assignee: Jarmo Pertman
>            Priority: Critical
>
> Watir::IE.close_all appears to be broken in 1.6.7 (it's possible it's broke in 1.6.6 but I don't think this was changed in 1.6.6).  Consider the following code.  I have addded a line in Watir::Exception.until_with_timeout to record the timeout that is being passed to Wait.until in line 10 of module.rb.  This clearly shows that 0 is being passed to Wait.until.  This causes the unexpected Watir::Wait::TimeoutError.
> {code}
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> => #<Watir::IE:0x4108a48 url="about:blank" title="">
> irb(main):003:0> br.close
> => false
> irb(main):004:0> br = Watir::IE.new
> => #<Watir::IE:0x40f6de8 url="about:blank" title="">
> irb(main):005:0> Watir::IE.close_all
> the attach timeout is 0
> Watir::Wait::TimeoutError: timed out after 0 seconds
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/wait.rb:23:in `until'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/module.rb:11:in `until_with_timeout'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:16:in `find_modal_from_window'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:36:in `locate'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:86:in `initialize'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/container.rb:188:in `new'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/container.rb:188:in `modal_dialog'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:29:in `close_modal'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:16:in `close_all_but'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/ie-class.rb:245:in `each'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/ie-class.rb:240:in `each'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:15:in `close_all_but'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:7:in `close_all'
>         from (irb):5
> irb(main):006:0> puts Watir::IE.attach_timeout
> 2.0
> => nil
> {code}
> The culprit, I believe, is Watir::IE#close_modal: 
> {code}
> # close modal dialog. unlike IE#modal_dialog.close, does not wait for dialog
> # to appear and does not raise exception if no window is found.
> # returns true if modal was found and close, otherwise false
> def close_modal
>   begin
>     original_attach_timeout = IE.attach_timeout
>     IE.attach_timeout = 0
>     self.modal_dialog.close
>     true
>   rescue NoMatchingWindowFoundException, TimeOutException
>     false
>   ensure
>     IE.attach_timeout = original_attach_timeout
>   end
> end
> {code}
> What's weird is that it specifically states in the comment that this should not raise an exception but it clearly is.  The reason is that line 28 in close_all.rb sets the IE.attach_timeout to 0.  I tried commenting out this line but it still raises a Watir::Wait::TimeoutError.

-- 
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  Mon Nov  8 17:51:20 2010
From: watirjira at gmail.com (Alan Baird (JIRA))
Date: Mon, 8 Nov 2010 16:51:20 -0600 (CST)
Subject: [Wtr-development] [JIRA] Commented: (WTR-464) uninstalling watir
 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
In-Reply-To: <25628117.550.1289243719870.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <18376196.567.1289256680563.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Alan Baird commented on WTR-464:
--------------------------------

Jarmo -

See WTR-462 for why I'm downgrading.  That's obviously a show stopper for me with respect to 1.6.7.

Alan

> uninstalling watir 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
> ---------------------------------------------------------------------------------
>
>                 Key: WTR-464
>                 URL: http://jira.openqa.org/browse/WTR-464
>             Project: Watir
>          Issue Type: Bug
>          Components: Gem installer
>    Affects Versions: 1.6.7
>         Environment: win xp ie7
>            Reporter: Alan Baird
>            Assignee: Jarmo Pertman
>            Priority: Major
>
> After uninstalling watir 1.6.7, and installing watir 1.6.6, Watir throws a LoadError trying to load watir/ie.  I looked at the versions that were installed and noticed that commonwatir and firewatir did not get uninstalled when Watir::IE was uninstalled.  The workaround is to manually uninstall commonwatir and firewatir.
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> LoadError: no such file to load -- watir/ie
>         from (irb):2
> irb(main):003:0> br = Watir::Browser.new
> Watir::Exception::UnableToStartJSShException: Unable to connect to machine : 127.0.0.1 on port 9997. Make sure that JSSh is properly installed and Fir
> efox is running with '-jssh' option
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:156:in `set_defaults'
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:50:in `initialize'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from (irb):3
> irb(main):004:0> exit
> # uninstall commonwatir and firewatir
> N:\gauntlet>gem uninstall commonwatir -v 1.6.7
> You have requested to uninstall the gem:
>         commonwatir-1.6.7
> firewatir-1.6.7 depends on [commonwatir (= 1.6.7)]
> If you remove this gems, one or more dependencies will not be met.
> Continue with Uninstall? [Yn]  y
> Successfully uninstalled commonwatir-1.6.7
> N:\gauntlet>gem uninstall firewatir -v 1.6.7
> Successfully uninstalled firewatir-1.6.7
> # test to see if Watir works
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::Browser.new
> => #<Watir::IE:0x40f7d88 url="about:blank" title="">
> irb(main):003:0> br.close
> => nil
> irb(main):004:0> br = Watir::IE.new
> => #<Watir::IE:0x40f0e84 url="about:blank" 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  Mon Nov  8 17:55:19 2010
From: watirjira at gmail.com (Jarmo Pertman (JIRA))
Date: Mon, 8 Nov 2010 16:55:19 -0600 (CST)
Subject: [Wtr-development] [JIRA] Commented: (WTR-464) uninstalling watir
 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
In-Reply-To: <25628117.550.1289243719870.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <7463167.570.1289256919814.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Jarmo Pertman commented on WTR-464:
-----------------------------------

But that's easily fixable with a small monkey-patch... and what version does set @closing to true anyway?

Jarmo

> uninstalling watir 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
> ---------------------------------------------------------------------------------
>
>                 Key: WTR-464
>                 URL: http://jira.openqa.org/browse/WTR-464
>             Project: Watir
>          Issue Type: Bug
>          Components: Gem installer
>    Affects Versions: 1.6.7
>         Environment: win xp ie7
>            Reporter: Alan Baird
>            Assignee: Jarmo Pertman
>            Priority: Major
>
> After uninstalling watir 1.6.7, and installing watir 1.6.6, Watir throws a LoadError trying to load watir/ie.  I looked at the versions that were installed and noticed that commonwatir and firewatir did not get uninstalled when Watir::IE was uninstalled.  The workaround is to manually uninstall commonwatir and firewatir.
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> LoadError: no such file to load -- watir/ie
>         from (irb):2
> irb(main):003:0> br = Watir::Browser.new
> Watir::Exception::UnableToStartJSShException: Unable to connect to machine : 127.0.0.1 on port 9997. Make sure that JSSh is properly installed and Fir
> efox is running with '-jssh' option
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:156:in `set_defaults'
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:50:in `initialize'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from (irb):3
> irb(main):004:0> exit
> # uninstall commonwatir and firewatir
> N:\gauntlet>gem uninstall commonwatir -v 1.6.7
> You have requested to uninstall the gem:
>         commonwatir-1.6.7
> firewatir-1.6.7 depends on [commonwatir (= 1.6.7)]
> If you remove this gems, one or more dependencies will not be met.
> Continue with Uninstall? [Yn]  y
> Successfully uninstalled commonwatir-1.6.7
> N:\gauntlet>gem uninstall firewatir -v 1.6.7
> Successfully uninstalled firewatir-1.6.7
> # test to see if Watir works
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::Browser.new
> => #<Watir::IE:0x40f7d88 url="about:blank" title="">
> irb(main):003:0> br.close
> => nil
> irb(main):004:0> br = Watir::IE.new
> => #<Watir::IE:0x40f0e84 url="about:blank" 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  Mon Nov  8 17:57:19 2010
From: watirjira at gmail.com (Alan Baird (JIRA))
Date: Mon, 8 Nov 2010 16:57:19 -0600 (CST)
Subject: [Wtr-development] [JIRA] Commented: (WTR-464) uninstalling watir
 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
In-Reply-To: <25628117.550.1289243719870.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <12863255.573.1289257039837.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Alan Baird commented on WTR-464:
--------------------------------

Oops...sorry, I've opened too many tickets lately.  WTR-463 is the one that's a show stopper.

> uninstalling watir 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
> ---------------------------------------------------------------------------------
>
>                 Key: WTR-464
>                 URL: http://jira.openqa.org/browse/WTR-464
>             Project: Watir
>          Issue Type: Bug
>          Components: Gem installer
>    Affects Versions: 1.6.7
>         Environment: win xp ie7
>            Reporter: Alan Baird
>            Assignee: Jarmo Pertman
>            Priority: Major
>
> After uninstalling watir 1.6.7, and installing watir 1.6.6, Watir throws a LoadError trying to load watir/ie.  I looked at the versions that were installed and noticed that commonwatir and firewatir did not get uninstalled when Watir::IE was uninstalled.  The workaround is to manually uninstall commonwatir and firewatir.
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> LoadError: no such file to load -- watir/ie
>         from (irb):2
> irb(main):003:0> br = Watir::Browser.new
> Watir::Exception::UnableToStartJSShException: Unable to connect to machine : 127.0.0.1 on port 9997. Make sure that JSSh is properly installed and Fir
> efox is running with '-jssh' option
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:156:in `set_defaults'
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:50:in `initialize'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from (irb):3
> irb(main):004:0> exit
> # uninstall commonwatir and firewatir
> N:\gauntlet>gem uninstall commonwatir -v 1.6.7
> You have requested to uninstall the gem:
>         commonwatir-1.6.7
> firewatir-1.6.7 depends on [commonwatir (= 1.6.7)]
> If you remove this gems, one or more dependencies will not be met.
> Continue with Uninstall? [Yn]  y
> Successfully uninstalled commonwatir-1.6.7
> N:\gauntlet>gem uninstall firewatir -v 1.6.7
> Successfully uninstalled firewatir-1.6.7
> # test to see if Watir works
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::Browser.new
> => #<Watir::IE:0x40f7d88 url="about:blank" title="">
> irb(main):003:0> br.close
> => nil
> irb(main):004:0> br = Watir::IE.new
> => #<Watir::IE:0x40f0e84 url="about:blank" 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  Tue Nov  9 07:44:47 2010
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Tue, 9 Nov 2010 13:44:47 +0100
Subject: [Wtr-development] What Gems Are Using Watir?
Message-ID: <AANLkTimPY2cnbUuYSLiRdagDPU_C5aOj8tjCwFhRnbBu@mail.gmail.com>

If you want to know the answer visit
http://zeljkofilipin.com/2010/11/09/what-gems-are-using-watir/

?eljko
--
watir.com - community manager
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/20101109/82671be7/attachment.html>

From bret at pettichord.com  Thu Nov 11 11:53:36 2010
From: bret at pettichord.com (Bret Pettichord)
Date: Thu, 11 Nov 2010 10:53:36 -0600
Subject: [Wtr-development] Watir Wiki on Stack Overflow
Message-ID: <AANLkTimhF-hFG=NU7P8Leocf3hpZMbLMuQxXTtJJEv=p@mail.gmail.com>

Zeljko,

Have you considered creating a Watir Wiki at stack overflow? Do you have the
reputation to create it? I don't.
http://stackoverflow.com/tags/watir/info

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/20101111/c0ea2baa/attachment.html>

From zeljko.filipin at wa-research.ch  Thu Nov 11 12:01:20 2010
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Thu, 11 Nov 2010 18:01:20 +0100
Subject: [Wtr-development] Watir Wiki on Stack Overflow
In-Reply-To: <AANLkTimhF-hFG=NU7P8Leocf3hpZMbLMuQxXTtJJEv=p@mail.gmail.com>
References: <AANLkTimhF-hFG=NU7P8Leocf3hpZMbLMuQxXTtJJEv=p@mail.gmail.com>
Message-ID: <AANLkTik6yHAC=NyuS_ZPWetX6648Vxwffxjvd7-=-4T-@mail.gmail.com>

On Thu, Nov 11, 2010 at 5:53 PM, Bret Pettichord <bret at pettichord.com>
wrote:
> Have you considered creating a Watir Wiki at stack overflow? Do you have
the reputation to create it? I don't.
> http://stackoverflow.com/tags/watir/info

I have noticed a few days ago that I have that superpower now, but I did not
have the time. It is on my list of things to do in the near future.

Do you have an idea what to put there?

By the way, I am at 1,989 Stack Overflow reputation, just 11 points away
from "edit any question and answer" superpower. :)

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

From watirjira at gmail.com  Thu Nov 11 18:27:20 2010
From: watirjira at gmail.com (Bret Pettichord (JIRA))
Date: Thu, 11 Nov 2010 17:27:20 -0600 (CST)
Subject: [Wtr-development] [JIRA] Updated: (WTR-463) close_all throws
	exception in Watir 1.6.7
In-Reply-To: <5370673.548.1289240420022.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <30151134.590.1289518040871.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Bret Pettichord updated WTR-463:
--------------------------------


Looks like the exception raised by wait_until was changed. This needs to be changed back, as this could cause other compatibility issues as well.

> close_all throws exception in Watir 1.6.7
> -----------------------------------------
>
>                 Key: WTR-463
>                 URL: http://jira.openqa.org/browse/WTR-463
>             Project: Watir
>          Issue Type: Bug
>          Components: Wait
>    Affects Versions: 1.6.7
>         Environment: Windows XP, IE7
>            Reporter: Alan Baird
>            Assignee: Jarmo Pertman
>            Priority: Critical
>             Fix For: Soon
>
>
> Watir::IE.close_all appears to be broken in 1.6.7 (it's possible it's broke in 1.6.6 but I don't think this was changed in 1.6.6).  Consider the following code.  I have addded a line in Watir::Exception.until_with_timeout to record the timeout that is being passed to Wait.until in line 10 of module.rb.  This clearly shows that 0 is being passed to Wait.until.  This causes the unexpected Watir::Wait::TimeoutError.
> {code}
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> => #<Watir::IE:0x4108a48 url="about:blank" title="">
> irb(main):003:0> br.close
> => false
> irb(main):004:0> br = Watir::IE.new
> => #<Watir::IE:0x40f6de8 url="about:blank" title="">
> irb(main):005:0> Watir::IE.close_all
> the attach timeout is 0
> Watir::Wait::TimeoutError: timed out after 0 seconds
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/wait.rb:23:in `until'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/module.rb:11:in `until_with_timeout'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:16:in `find_modal_from_window'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:36:in `locate'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:86:in `initialize'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/container.rb:188:in `new'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/container.rb:188:in `modal_dialog'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:29:in `close_modal'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:16:in `close_all_but'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/ie-class.rb:245:in `each'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/ie-class.rb:240:in `each'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:15:in `close_all_but'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:7:in `close_all'
>         from (irb):5
> irb(main):006:0> puts Watir::IE.attach_timeout
> 2.0
> => nil
> {code}
> The culprit, I believe, is Watir::IE#close_modal: 
> {code}
> # close modal dialog. unlike IE#modal_dialog.close, does not wait for dialog
> # to appear and does not raise exception if no window is found.
> # returns true if modal was found and close, otherwise false
> def close_modal
>   begin
>     original_attach_timeout = IE.attach_timeout
>     IE.attach_timeout = 0
>     self.modal_dialog.close
>     true
>   rescue NoMatchingWindowFoundException, TimeOutException
>     false
>   ensure
>     IE.attach_timeout = original_attach_timeout
>   end
> end
> {code}
> What's weird is that it specifically states in the comment that this should not raise an exception but it clearly is.  The reason is that line 28 in close_all.rb sets the IE.attach_timeout to 0.  I tried commenting out this line but it still raises a Watir::Wait::TimeoutError.

-- 
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 Nov 11 18:27:20 2010
From: watirjira at gmail.com (Bret Pettichord (JIRA))
Date: Thu, 11 Nov 2010 17:27:20 -0600 (CST)
Subject: [Wtr-development] [JIRA] Updated: (WTR-463) close_all throws
	exception in Watir 1.6.7
In-Reply-To: <5370673.548.1289240420022.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <9227638.593.1289518040935.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Bret Pettichord updated WTR-463:
--------------------------------

    Fix Version/s: Soon

> close_all throws exception in Watir 1.6.7
> -----------------------------------------
>
>                 Key: WTR-463
>                 URL: http://jira.openqa.org/browse/WTR-463
>             Project: Watir
>          Issue Type: Bug
>          Components: Wait
>    Affects Versions: 1.6.7
>         Environment: Windows XP, IE7
>            Reporter: Alan Baird
>            Assignee: Jarmo Pertman
>            Priority: Critical
>             Fix For: Soon
>
>
> Watir::IE.close_all appears to be broken in 1.6.7 (it's possible it's broke in 1.6.6 but I don't think this was changed in 1.6.6).  Consider the following code.  I have addded a line in Watir::Exception.until_with_timeout to record the timeout that is being passed to Wait.until in line 10 of module.rb.  This clearly shows that 0 is being passed to Wait.until.  This causes the unexpected Watir::Wait::TimeoutError.
> {code}
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> => #<Watir::IE:0x4108a48 url="about:blank" title="">
> irb(main):003:0> br.close
> => false
> irb(main):004:0> br = Watir::IE.new
> => #<Watir::IE:0x40f6de8 url="about:blank" title="">
> irb(main):005:0> Watir::IE.close_all
> the attach timeout is 0
> Watir::Wait::TimeoutError: timed out after 0 seconds
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/wait.rb:23:in `until'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/module.rb:11:in `until_with_timeout'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:16:in `find_modal_from_window'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:36:in `locate'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:86:in `initialize'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/container.rb:188:in `new'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/container.rb:188:in `modal_dialog'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:29:in `close_modal'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:16:in `close_all_but'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/ie-class.rb:245:in `each'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/ie-class.rb:240:in `each'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:15:in `close_all_but'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:7:in `close_all'
>         from (irb):5
> irb(main):006:0> puts Watir::IE.attach_timeout
> 2.0
> => nil
> {code}
> The culprit, I believe, is Watir::IE#close_modal: 
> {code}
> # close modal dialog. unlike IE#modal_dialog.close, does not wait for dialog
> # to appear and does not raise exception if no window is found.
> # returns true if modal was found and close, otherwise false
> def close_modal
>   begin
>     original_attach_timeout = IE.attach_timeout
>     IE.attach_timeout = 0
>     self.modal_dialog.close
>     true
>   rescue NoMatchingWindowFoundException, TimeOutException
>     false
>   ensure
>     IE.attach_timeout = original_attach_timeout
>   end
> end
> {code}
> What's weird is that it specifically states in the comment that this should not raise an exception but it clearly is.  The reason is that line 28 in close_all.rb sets the IE.attach_timeout to 0.  I tried commenting out this line but it still raises a Watir::Wait::TimeoutError.

-- 
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 Nov 14 09:03:20 2010
From: watirjira at gmail.com (Jarmo Pertman (JIRA))
Date: Sun, 14 Nov 2010 08:03:20 -0600 (CST)
Subject: [Wtr-development] [JIRA] Closed: (WTR-463) close_all throws
	exception in Watir 1.6.7
In-Reply-To: <5370673.548.1289240420022.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <12836428.601.1289743400887.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Jarmo Pertman closed WTR-463.
-----------------------------

    Resolution: Fixed

Fixed in commit https://github.com/bret/watir/commit/d4bc06257ddda98594fa87081915083d3182b904

> close_all throws exception in Watir 1.6.7
> -----------------------------------------
>
>                 Key: WTR-463
>                 URL: http://jira.openqa.org/browse/WTR-463
>             Project: Watir
>          Issue Type: Bug
>          Components: Wait
>    Affects Versions: 1.6.7
>         Environment: Windows XP, IE7
>            Reporter: Alan Baird
>            Assignee: Jarmo Pertman
>            Priority: Critical
>             Fix For: Soon
>
>
> Watir::IE.close_all appears to be broken in 1.6.7 (it's possible it's broke in 1.6.6 but I don't think this was changed in 1.6.6).  Consider the following code.  I have addded a line in Watir::Exception.until_with_timeout to record the timeout that is being passed to Wait.until in line 10 of module.rb.  This clearly shows that 0 is being passed to Wait.until.  This causes the unexpected Watir::Wait::TimeoutError.
> {code}
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> => #<Watir::IE:0x4108a48 url="about:blank" title="">
> irb(main):003:0> br.close
> => false
> irb(main):004:0> br = Watir::IE.new
> => #<Watir::IE:0x40f6de8 url="about:blank" title="">
> irb(main):005:0> Watir::IE.close_all
> the attach timeout is 0
> Watir::Wait::TimeoutError: timed out after 0 seconds
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/wait.rb:23:in `until'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/module.rb:11:in `until_with_timeout'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:16:in `find_modal_from_window'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:36:in `locate'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:86:in `initialize'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/container.rb:188:in `new'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/container.rb:188:in `modal_dialog'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:29:in `close_modal'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:16:in `close_all_but'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/ie-class.rb:245:in `each'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/ie-class.rb:240:in `each'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:15:in `close_all_but'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:7:in `close_all'
>         from (irb):5
> irb(main):006:0> puts Watir::IE.attach_timeout
> 2.0
> => nil
> {code}
> The culprit, I believe, is Watir::IE#close_modal: 
> {code}
> # close modal dialog. unlike IE#modal_dialog.close, does not wait for dialog
> # to appear and does not raise exception if no window is found.
> # returns true if modal was found and close, otherwise false
> def close_modal
>   begin
>     original_attach_timeout = IE.attach_timeout
>     IE.attach_timeout = 0
>     self.modal_dialog.close
>     true
>   rescue NoMatchingWindowFoundException, TimeOutException
>     false
>   ensure
>     IE.attach_timeout = original_attach_timeout
>   end
> end
> {code}
> What's weird is that it specifically states in the comment that this should not raise an exception but it clearly is.  The reason is that line 28 in close_all.rb sets the IE.attach_timeout to 0.  I tried commenting out this line but it still raises a Watir::Wait::TimeoutError.

-- 
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 Nov 14 09:08:19 2010
From: watirjira at gmail.com (Jarmo Pertman (JIRA))
Date: Sun, 14 Nov 2010 08:08:19 -0600 (CST)
Subject: [Wtr-development] [JIRA] Reopened: (WTR-463) close_all throws
 exception in Watir 1.6.7
In-Reply-To: <5370673.548.1289240420022.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <20154927.604.1289743699988.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Jarmo Pertman reopened WTR-463:
-------------------------------


Forgot to comment at Bret statement - this does not to be changed back since the old deprecated version of Watir::Waiter still exists. As long as everything inside Watir/Firewatir rescue the correct exception class (i thought i did it already...) then we're fine. The same exact Exception class and module is also used in Watir-Webdriver wait extension so that makes it future compliant.

> close_all throws exception in Watir 1.6.7
> -----------------------------------------
>
>                 Key: WTR-463
>                 URL: http://jira.openqa.org/browse/WTR-463
>             Project: Watir
>          Issue Type: Bug
>          Components: Wait
>    Affects Versions: 1.6.7
>         Environment: Windows XP, IE7
>            Reporter: Alan Baird
>            Assignee: Jarmo Pertman
>            Priority: Critical
>             Fix For: Soon
>
>
> Watir::IE.close_all appears to be broken in 1.6.7 (it's possible it's broke in 1.6.6 but I don't think this was changed in 1.6.6).  Consider the following code.  I have addded a line in Watir::Exception.until_with_timeout to record the timeout that is being passed to Wait.until in line 10 of module.rb.  This clearly shows that 0 is being passed to Wait.until.  This causes the unexpected Watir::Wait::TimeoutError.
> {code}
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> => #<Watir::IE:0x4108a48 url="about:blank" title="">
> irb(main):003:0> br.close
> => false
> irb(main):004:0> br = Watir::IE.new
> => #<Watir::IE:0x40f6de8 url="about:blank" title="">
> irb(main):005:0> Watir::IE.close_all
> the attach timeout is 0
> Watir::Wait::TimeoutError: timed out after 0 seconds
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/wait.rb:23:in `until'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/module.rb:11:in `until_with_timeout'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:16:in `find_modal_from_window'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:36:in `locate'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:86:in `initialize'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/container.rb:188:in `new'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/container.rb:188:in `modal_dialog'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:29:in `close_modal'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:16:in `close_all_but'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/ie-class.rb:245:in `each'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/ie-class.rb:240:in `each'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:15:in `close_all_but'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:7:in `close_all'
>         from (irb):5
> irb(main):006:0> puts Watir::IE.attach_timeout
> 2.0
> => nil
> {code}
> The culprit, I believe, is Watir::IE#close_modal: 
> {code}
> # close modal dialog. unlike IE#modal_dialog.close, does not wait for dialog
> # to appear and does not raise exception if no window is found.
> # returns true if modal was found and close, otherwise false
> def close_modal
>   begin
>     original_attach_timeout = IE.attach_timeout
>     IE.attach_timeout = 0
>     self.modal_dialog.close
>     true
>   rescue NoMatchingWindowFoundException, TimeOutException
>     false
>   ensure
>     IE.attach_timeout = original_attach_timeout
>   end
> end
> {code}
> What's weird is that it specifically states in the comment that this should not raise an exception but it clearly is.  The reason is that line 28 in close_all.rb sets the IE.attach_timeout to 0.  I tried commenting out this line but it still raises a Watir::Wait::TimeoutError.

-- 
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 Nov 14 09:08:20 2010
From: watirjira at gmail.com (Jarmo Pertman (JIRA))
Date: Sun, 14 Nov 2010 08:08:20 -0600 (CST)
Subject: [Wtr-development] [JIRA] Closed: (WTR-463) close_all throws
	exception in Watir 1.6.7
In-Reply-To: <5370673.548.1289240420022.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <13169236.607.1289743700101.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Jarmo Pertman closed WTR-463.
-----------------------------

    Resolution: Fixed

> close_all throws exception in Watir 1.6.7
> -----------------------------------------
>
>                 Key: WTR-463
>                 URL: http://jira.openqa.org/browse/WTR-463
>             Project: Watir
>          Issue Type: Bug
>          Components: Wait
>    Affects Versions: 1.6.7
>         Environment: Windows XP, IE7
>            Reporter: Alan Baird
>            Assignee: Jarmo Pertman
>            Priority: Critical
>             Fix For: Soon
>
>
> Watir::IE.close_all appears to be broken in 1.6.7 (it's possible it's broke in 1.6.6 but I don't think this was changed in 1.6.6).  Consider the following code.  I have addded a line in Watir::Exception.until_with_timeout to record the timeout that is being passed to Wait.until in line 10 of module.rb.  This clearly shows that 0 is being passed to Wait.until.  This causes the unexpected Watir::Wait::TimeoutError.
> {code}
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> => #<Watir::IE:0x4108a48 url="about:blank" title="">
> irb(main):003:0> br.close
> => false
> irb(main):004:0> br = Watir::IE.new
> => #<Watir::IE:0x40f6de8 url="about:blank" title="">
> irb(main):005:0> Watir::IE.close_all
> the attach timeout is 0
> Watir::Wait::TimeoutError: timed out after 0 seconds
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/wait.rb:23:in `until'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/module.rb:11:in `until_with_timeout'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:16:in `find_modal_from_window'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:36:in `locate'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/modal_dialog.rb:86:in `initialize'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/container.rb:188:in `new'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/container.rb:188:in `modal_dialog'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:29:in `close_modal'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:16:in `close_all_but'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/ie-class.rb:245:in `each'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/ie-class.rb:240:in `each'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:15:in `close_all_but'
>         from c:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/close_all.rb:7:in `close_all'
>         from (irb):5
> irb(main):006:0> puts Watir::IE.attach_timeout
> 2.0
> => nil
> {code}
> The culprit, I believe, is Watir::IE#close_modal: 
> {code}
> # close modal dialog. unlike IE#modal_dialog.close, does not wait for dialog
> # to appear and does not raise exception if no window is found.
> # returns true if modal was found and close, otherwise false
> def close_modal
>   begin
>     original_attach_timeout = IE.attach_timeout
>     IE.attach_timeout = 0
>     self.modal_dialog.close
>     true
>   rescue NoMatchingWindowFoundException, TimeOutException
>     false
>   ensure
>     IE.attach_timeout = original_attach_timeout
>   end
> end
> {code}
> What's weird is that it specifically states in the comment that this should not raise an exception but it clearly is.  The reason is that line 28 in close_all.rb sets the IE.attach_timeout to 0.  I tried commenting out this line but it still raises a Watir::Wait::TimeoutError.

-- 
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  Tue Nov 16 04:11:21 2010
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Tue, 16 Nov 2010 10:11:21 +0100
Subject: [Wtr-development] Selenium Conference
Message-ID: <AANLkTik2t=u9Bzg1mBd5xkh5Cmw7k+5zE5R_eMSn+XQA@mail.gmail.com>

Anybody going to Selenium Conference?

http://groups.google.com/group/selenium-developers/browse_thread/thread/963c0f2efef224f3
http://groups.google.com/group/seconf

?eljko
--
watir.com - community manager
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/20101116/668118c3/attachment.html>

From jari.bakken at gmail.com  Tue Nov 16 04:38:50 2010
From: jari.bakken at gmail.com (Jari Bakken)
Date: Tue, 16 Nov 2010 10:38:50 +0100
Subject: [Wtr-development] Selenium Conference
In-Reply-To: <AANLkTik2t=u9Bzg1mBd5xkh5Cmw7k+5zE5R_eMSn+XQA@mail.gmail.com>
References: <AANLkTik2t=u9Bzg1mBd5xkh5Cmw7k+5zE5R_eMSn+XQA@mail.gmail.com>
Message-ID: <AANLkTinwfabP83yaGF1cBaeR=SpgBqVfgf6GGscOrnh2@mail.gmail.com>

On Tue, Nov 16, 2010 at 10:11 AM, ?eljko Filipin
<zeljko.filipin at wa-research.ch> wrote:
> Anybody going to Selenium Conference?
>
> http://groups.google.com/group/selenium-developers/browse_thread/thread/963c0f2efef224f3
> http://groups.google.com/group/seconf
>

I'll try to go if I can get the finances in place :)

From bret at pettichord.com  Tue Nov 16 10:38:10 2010
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 16 Nov 2010 09:38:10 -0600
Subject: [Wtr-development] Selenium Conference
In-Reply-To: <AANLkTik2t=u9Bzg1mBd5xkh5Cmw7k+5zE5R_eMSn+XQA@mail.gmail.com>
References: <AANLkTik2t=u9Bzg1mBd5xkh5Cmw7k+5zE5R_eMSn+XQA@mail.gmail.com>
Message-ID: <AANLkTimL6Uob6YUpqdj6DWDa9ggCiGVsJ-+PsBk4Z7O_@mail.gmail.com>

Well it looks like they have yet to decide a location and exact date. But I
am very interested in attending. Please let us know if you hear about
decisions on these details.

Bret

On Tue, Nov 16, 2010 at 3:11 AM, ?eljko Filipin <
zeljko.filipin at wa-research.ch> wrote:

> Anybody going to Selenium Conference?
>
>
> http://groups.google.com/group/selenium-developers/browse_thread/thread/963c0f2efef224f3
> http://groups.google.com/group/seconf
>
> ?eljko
> --
> watir.com - community manager
> watirpodcast.com - host
> testingpodcast.com - audio podcasts on software testing. all of them
>
>
> _______________________________________________
> 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/20101116/623e43f2/attachment-0001.html>

From watirjira at gmail.com  Tue Nov 16 18:05:20 2010
From: watirjira at gmail.com (Mark Wieder (JIRA))
Date: Tue, 16 Nov 2010 17:05:20 -0600 (CST)
Subject: [Wtr-development] [JIRA] Created: (WTR-465) improved speed of
	filling text fields
Message-ID: <14796054.632.1289948720475.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>

improved speed of filling text fields
-------------------------------------

                 Key: WTR-465
                 URL: http://jira.openqa.org/browse/WTR-465
             Project: Watir
          Issue Type: Improvement
          Components: FireWatir
    Affects Versions: 1.6.7
         Environment: Fedora Core 13, Firefox 3.6.12
            Reporter: Mark Wieder


The set method for filling text fields was operating at about one char per second, so I rewrote doKeyPress. It now works much faster for both append and set.

      begin
        #...existing test for max length
      end
      # get existing text
      oldvalue = "#{(o.value.to_s)}"
      # append new text
      oldvalue += value
      @o.value = oldvalue
      @o.fireEvent("onKeyDown")
      @o.fireEvent("onKeyPress")
      @o.fireEvent("onKeyUp")

Tried and failed to create a diff file for you...

-- 
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  Wed Nov 17 04:17:29 2010
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Wed, 17 Nov 2010 10:17:29 +0100
Subject: [Wtr-development] Welcome message for watir-general
Message-ID: <AANLkTike6hxj4YtwnDb9O7zMiddeE0aDNW9JcngFU+Th@mail.gmail.com>

I have just opened http://groups.google.com/group/watir-general and saw:

"Google Groups will no longer be supporting the Welcome Message feature.
Starting January 13, you won't be able to edit your welcome messages, but
you will still be able to view and download the existing content. See this
announcement
<http://groups-announcements.blogspot.com/2010/09/notice-about-pages-and-files.html?hl=en>for
more information and other options for storing your content. [Download
Welcome Message Content
<http://groups.google.com/group/watir-general/download?s=welcome>]"

At the moment we have this:

"Welcome to Watir General. This list is for general discussions of using
Watir <http://watir.com/> for testing.

If you have a minute or two, take a look at Watir
Support<http://watir.com/support/>page. To sum it up:

   - Search<http://www.google.com/cse/home?cx=007267089725385613265%3Agmydx5gtw6u>before
you ask.
   - Be nice."

Should we change anything, while we still can?

?eljko
--
watir.com - community manager
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/20101117/e6a099f3/attachment.html>

From zeljko.filipin at wa-research.ch  Wed Nov 17 07:36:27 2010
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Wed, 17 Nov 2010 13:36:27 +0100
Subject: [Wtr-development] Selenium Conference
In-Reply-To: <AANLkTimL6Uob6YUpqdj6DWDa9ggCiGVsJ-+PsBk4Z7O_@mail.gmail.com>
References: <AANLkTik2t=u9Bzg1mBd5xkh5Cmw7k+5zE5R_eMSn+XQA@mail.gmail.com>
	<AANLkTimL6Uob6YUpqdj6DWDa9ggCiGVsJ-+PsBk4Z7O_@mail.gmail.com>
Message-ID: <AANLkTimOXmbo3C7bHNxH7fT23F2_P5tr1jXmgBT2isx8@mail.gmail.com>

On Tue, Nov 16, 2010 at 4:38 PM, Bret Pettichord <bret at pettichord.com>
wrote:
> But I am very interested in attending. Please let us know if you hear
about decisions on these details.

Sure.

Are you thinking about AWTA 2011? If it is too much work for you to
organize, maybe Watir community could meet at Selenium conference.

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

From bret at pettichord.com  Wed Nov 17 11:22:45 2010
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 17 Nov 2010 10:22:45 -0600
Subject: [Wtr-development] Selenium Conference
In-Reply-To: <AANLkTimOXmbo3C7bHNxH7fT23F2_P5tr1jXmgBT2isx8@mail.gmail.com>
References: <AANLkTik2t=u9Bzg1mBd5xkh5Cmw7k+5zE5R_eMSn+XQA@mail.gmail.com>
	<AANLkTimL6Uob6YUpqdj6DWDa9ggCiGVsJ-+PsBk4Z7O_@mail.gmail.com>
	<AANLkTimOXmbo3C7bHNxH7fT23F2_P5tr1jXmgBT2isx8@mail.gmail.com>
Message-ID: <AANLkTi=XhYZKRbioK3Np+CUpqghLofMCdN0Wd5+2aB8V@mail.gmail.com>

I am not planning an AWTA 2011 at this time.

On Wed, Nov 17, 2010 at 6:36 AM, ?eljko Filipin <
zeljko.filipin at wa-research.ch> wrote:

> On Tue, Nov 16, 2010 at 4:38 PM, Bret Pettichord <bret at pettichord.com>
> wrote:
> > But I am very interested in attending. Please let us know if you hear
> about decisions on these details.
>
> Sure.
>
> Are you thinking about AWTA 2011? If it is too much work for you to
> organize, maybe Watir community could meet at Selenium conference.
>
> ?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/20101117/cdf053f7/attachment.html>

From bret at pettichord.com  Wed Nov 17 21:34:08 2010
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 17 Nov 2010 20:34:08 -0600
Subject: [Wtr-development] Selenium Conference
In-Reply-To: <AANLkTi=XhYZKRbioK3Np+CUpqghLofMCdN0Wd5+2aB8V@mail.gmail.com>
References: <AANLkTik2t=u9Bzg1mBd5xkh5Cmw7k+5zE5R_eMSn+XQA@mail.gmail.com>
	<AANLkTimL6Uob6YUpqdj6DWDa9ggCiGVsJ-+PsBk4Z7O_@mail.gmail.com>
	<AANLkTimOXmbo3C7bHNxH7fT23F2_P5tr1jXmgBT2isx8@mail.gmail.com>
	<AANLkTi=XhYZKRbioK3Np+CUpqghLofMCdN0Wd5+2aB8V@mail.gmail.com>
Message-ID: <AANLkTinJ=fwgtdUUOoV2=fTv=jvfju6s=niV2h6POans@mail.gmail.com>

However, I have been thinking a lot about travelling to Europe this summer
and maybe organizing some kind of watir-event at that time. It could be a
meetup or conference or AWTA-style workshop. I haven't really had a chance
to discuss it with my family yet. Anyway, I was thinking Oslo might be a
good location if we could find someone to help find us space.

But first, let's find out more about this Selenium conference.

Bret

On Wed, Nov 17, 2010 at 10:22 AM, Bret Pettichord <bret at pettichord.com>wrote:

> I am not planning an AWTA 2011 at this time.
>
> On Wed, Nov 17, 2010 at 6:36 AM, ?eljko Filipin <
> zeljko.filipin at wa-research.ch> wrote:
>
>> On Tue, Nov 16, 2010 at 4:38 PM, Bret Pettichord <bret at pettichord.com>
>> wrote:
>> > But I am very interested in attending. Please let us know if you hear
>> about decisions on these details.
>>
>> Sure.
>>
>> Are you thinking about AWTA 2011? If it is too much work for you to
>> organize, maybe Watir community could meet at Selenium conference.
>>
>> ?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 <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/20101117/5529a698/attachment.html>

From andreastt at opera.com  Wed Nov 17 23:38:28 2010
From: andreastt at opera.com (Andreas Tolf Tolfsen)
Date: Thu, 18 Nov 2010 05:38:28 +0100
Subject: [Wtr-development] Selenium Conference
In-Reply-To: <AANLkTinJ=fwgtdUUOoV2=fTv=jvfju6s=niV2h6POans@mail.gmail.com>
References: <AANLkTik2t=u9Bzg1mBd5xkh5Cmw7k+5zE5R_eMSn+XQA@mail.gmail.com>
	<AANLkTimL6Uob6YUpqdj6DWDa9ggCiGVsJ-+PsBk4Z7O_@mail.gmail.com>
	<AANLkTimOXmbo3C7bHNxH7fT23F2_P5tr1jXmgBT2isx8@mail.gmail.com>
	<AANLkTi=XhYZKRbioK3Np+CUpqghLofMCdN0Wd5+2aB8V@mail.gmail.com>
	<AANLkTinJ=fwgtdUUOoV2=fTv=jvfju6s=niV2h6POans@mail.gmail.com>
Message-ID: <20101118043828.GI28283@e-tjenesten.org>

* Also sprach Bret Pettichord <bret at pettichord.com>:
> However, I have been thinking a lot about travelling to Europe this
> summer and maybe organizing some kind of watir-event at that time. It
> could be a meetup or conference or AWTA-style workshop. I haven't
> really had a chance to discuss it with my family yet. Anyway, I was
> thinking Oslo might be a good location if we could find someone to
> help find us space.

It would obviously be very easy for us at Opera Software and Finn.no to
attend if the conference were to be held in Oslo.

I'm sure that finding space in Oslo will not be a problem at all.
Without having spoken with my employer, I'm sure we can figure something
out. (-;

-- 
Andreas Tolf Tolfsen
Core Systems
<andreastt at opera.com>


From alister.scott at gmail.com  Thu Nov 18 01:00:18 2010
From: alister.scott at gmail.com (Alister Scott)
Date: Thu, 18 Nov 2010 16:00:18 +1000
Subject: [Wtr-development] Selenium Conference
In-Reply-To: <20101118043828.GI28283@e-tjenesten.org>
References: <AANLkTik2t=u9Bzg1mBd5xkh5Cmw7k+5zE5R_eMSn+XQA@mail.gmail.com>
	<AANLkTimL6Uob6YUpqdj6DWDa9ggCiGVsJ-+PsBk4Z7O_@mail.gmail.com>
	<AANLkTimOXmbo3C7bHNxH7fT23F2_P5tr1jXmgBT2isx8@mail.gmail.com>
	<AANLkTi=XhYZKRbioK3Np+CUpqghLofMCdN0Wd5+2aB8V@mail.gmail.com>
	<AANLkTinJ=fwgtdUUOoV2=fTv=jvfju6s=niV2h6POans@mail.gmail.com>
	<20101118043828.GI28283@e-tjenesten.org>
Message-ID: <AANLkTim2w19iEGSbFCJArj024TkjLUVAOA8CUjy8kVDB@mail.gmail.com>

I was looking forward to another trip to Austin for AWTA in the new year,
but it seems like that's no longer planned.
Oh well.

~ Alister
**

On Thu, Nov 18, 2010 at 2:38 PM, Andreas Tolf Tolfsen
<andreastt at opera.com>wrote:

> * Also sprach Bret Pettichord <bret at pettichord.com>:
> > However, I have been thinking a lot about travelling to Europe this
> > summer and maybe organizing some kind of watir-event at that time. It
> > could be a meetup or conference or AWTA-style workshop. I haven't
> > really had a chance to discuss it with my family yet. Anyway, I was
> > thinking Oslo might be a good location if we could find someone to
> > help find us space.
>
> It would obviously be very easy for us at Opera Software and Finn.no to
> attend if the conference were to be held in Oslo.
>
> I'm sure that finding space in Oslo will not be a problem at all.
> Without having spoken with my employer, I'm sure we can figure something
> out. (-;
>
> --
> Andreas Tolf Tolfsen
> Core Systems
> <andreastt at opera.com>
>
> _______________________________________________
> 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/20101118/d230a353/attachment-0001.html>

From zeljko.filipin at wa-research.ch  Thu Nov 18 08:58:04 2010
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Thu, 18 Nov 2010 14:58:04 +0100
Subject: [Wtr-development] Watir Podcast #39: Jeff Lusenhop on Janova 3/3
Message-ID: <AANLkTikZcWXyHCi66ZJq1ovRiJi1AXyysyROBO5ReOV6@mail.gmail.com>

The final part of Watir podcast on Janova:

http://watirpodcast.com/39-jeff-lusenhop-on-janova-3-3/

?eljko
--
watir.com - community manager
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/20101118/0881f81e/attachment.html>

From zeljko.filipin at wa-research.ch  Thu Nov 18 09:30:44 2010
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Thu, 18 Nov 2010 15:30:44 +0100
Subject: [Wtr-development] Selenium Conference
In-Reply-To: <AANLkTinJ=fwgtdUUOoV2=fTv=jvfju6s=niV2h6POans@mail.gmail.com>
References: <AANLkTik2t=u9Bzg1mBd5xkh5Cmw7k+5zE5R_eMSn+XQA@mail.gmail.com>
	<AANLkTimL6Uob6YUpqdj6DWDa9ggCiGVsJ-+PsBk4Z7O_@mail.gmail.com>
	<AANLkTimOXmbo3C7bHNxH7fT23F2_P5tr1jXmgBT2isx8@mail.gmail.com>
	<AANLkTi=XhYZKRbioK3Np+CUpqghLofMCdN0Wd5+2aB8V@mail.gmail.com>
	<AANLkTinJ=fwgtdUUOoV2=fTv=jvfju6s=niV2h6POans@mail.gmail.com>
Message-ID: <AANLkTikUGK8gbysx+aAUx3FR_vc-_FUGCXTrhmJ0EReB@mail.gmail.com>

On Thu, Nov 18, 2010 at 3:34 AM, Bret Pettichord <bret at pettichord.com>
wrote:
> I was thinking Oslo might be a good location if we could find someone to
help find us space.
> But first, let's find out more about this Selenium conference.

I could probably go to either Selenium conference or to a Watir meetup next
year. I doubt that I could go to both. Except if Watir meetup was somewhere
near Croatia (driving distance). Google maps says Zagreb-Oslo is about 2000
km (about 1200 miles) or 21 hours by car. :)

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

From zeljko.filipin at wa-research.ch  Thu Nov 18 09:42:58 2010
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Thu, 18 Nov 2010 15:42:58 +0100
Subject: [Wtr-development] Watir Podcast #40: Dave McNulla
Message-ID: <AANLkTi=XLA6WNosCv5-8rYV1ivjWHQyd-c0Tj3NsCH3W@mail.gmail.com>

I am recording the next podcast with Dave McNulla[1] this Saturday, November
20th, 2pm UTC.

If you have a question or two for Dave, post it here.

Dave, do not answer to questions here, but on the podcast. :)

[1] http://twitter.com/#!/dmcnulla

?eljko
--
watir.com - community manager
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/20101118/c94114bd/attachment.html>

From jarmo.p at gmail.com  Thu Nov 18 10:16:35 2010
From: jarmo.p at gmail.com (Jarmo)
Date: Thu, 18 Nov 2010 17:16:35 +0200
Subject: [Wtr-development] Selenium Conference
In-Reply-To: <AANLkTikUGK8gbysx+aAUx3FR_vc-_FUGCXTrhmJ0EReB@mail.gmail.com>
References: <AANLkTik2t=u9Bzg1mBd5xkh5Cmw7k+5zE5R_eMSn+XQA@mail.gmail.com>
	<AANLkTimL6Uob6YUpqdj6DWDa9ggCiGVsJ-+PsBk4Z7O_@mail.gmail.com>
	<AANLkTimOXmbo3C7bHNxH7fT23F2_P5tr1jXmgBT2isx8@mail.gmail.com>
	<AANLkTi=XhYZKRbioK3Np+CUpqghLofMCdN0Wd5+2aB8V@mail.gmail.com>
	<AANLkTinJ=fwgtdUUOoV2=fTv=jvfju6s=niV2h6POans@mail.gmail.com>
	<AANLkTikUGK8gbysx+aAUx3FR_vc-_FUGCXTrhmJ0EReB@mail.gmail.com>
Message-ID: <AANLkTimpos=kCo=B0XTAAQbx_FX6q4mg2Z1NL0y5-WWZ@mail.gmail.com>

Don't forget that Oslo (Norway) is one of the most expensive places to be in
the world :P Maybe Jari can confirm or contradict.

Jarmo

On Thu, Nov 18, 2010 at 4:30 PM, ?eljko Filipin <
zeljko.filipin at wa-research.ch> wrote:

> On Thu, Nov 18, 2010 at 3:34 AM, Bret Pettichord <bret at pettichord.com>
> wrote:
> > I was thinking Oslo might be a good location if we could find someone to
> help find us space.
> > But first, let's find out more about this Selenium conference.
>
> I could probably go to either Selenium conference or to a Watir meetup next
> year. I doubt that I could go to both. Except if Watir meetup was somewhere
> near Croatia (driving distance). Google maps says Zagreb-Oslo is about 2000
> km (about 1200 miles) or 21 hours by car. :)
>
> ?eljko
>
> _______________________________________________
> 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/20101118/fb1f5de8/attachment.html>

From jari.bakken at gmail.com  Thu Nov 18 10:52:44 2010
From: jari.bakken at gmail.com (Jari Bakken)
Date: Thu, 18 Nov 2010 16:52:44 +0100
Subject: [Wtr-development] Selenium Conference
In-Reply-To: <AANLkTimpos=kCo=B0XTAAQbx_FX6q4mg2Z1NL0y5-WWZ@mail.gmail.com>
References: <AANLkTik2t=u9Bzg1mBd5xkh5Cmw7k+5zE5R_eMSn+XQA@mail.gmail.com>
	<AANLkTimL6Uob6YUpqdj6DWDa9ggCiGVsJ-+PsBk4Z7O_@mail.gmail.com>
	<AANLkTimOXmbo3C7bHNxH7fT23F2_P5tr1jXmgBT2isx8@mail.gmail.com>
	<AANLkTi=XhYZKRbioK3Np+CUpqghLofMCdN0Wd5+2aB8V@mail.gmail.com>
	<AANLkTinJ=fwgtdUUOoV2=fTv=jvfju6s=niV2h6POans@mail.gmail.com>
	<AANLkTikUGK8gbysx+aAUx3FR_vc-_FUGCXTrhmJ0EReB@mail.gmail.com>
	<AANLkTimpos=kCo=B0XTAAQbx_FX6q4mg2Z1NL0y5-WWZ@mail.gmail.com>
Message-ID: <AANLkTikugFbnh-pTbFs=wLkBHYkfGJW2z+kR10XKSyKz@mail.gmail.com>

On Thu, Nov 18, 2010 at 4:16 PM, Jarmo <jarmo.p at gmail.com> wrote:
> Don't forget that Oslo (Norway) is one of the most expensive places to be in
> the world :P Maybe Jari can confirm or contradict.
> Jarmo
>

That's true - it's a tie with Tokyo I think. Andreas is right that
finding a space in Oslo wouldn't be a problem. I'd definitely go if it
was in any European city though.

I also like the idea of meeting up at the Selenium conference - makes
sense to me since it looks like a lot of tools are converging on
WebDriver/Se2 as the core technology.

From simon.m.stewart at gmail.com  Thu Nov 18 12:06:31 2010
From: simon.m.stewart at gmail.com (Simon Stewart)
Date: Thu, 18 Nov 2010 17:06:31 +0000
Subject: [Wtr-development] Selenium Conference
In-Reply-To: <AANLkTikugFbnh-pTbFs=wLkBHYkfGJW2z+kR10XKSyKz@mail.gmail.com>
References: <AANLkTik2t=u9Bzg1mBd5xkh5Cmw7k+5zE5R_eMSn+XQA@mail.gmail.com>
	<AANLkTimL6Uob6YUpqdj6DWDa9ggCiGVsJ-+PsBk4Z7O_@mail.gmail.com>
	<AANLkTimOXmbo3C7bHNxH7fT23F2_P5tr1jXmgBT2isx8@mail.gmail.com>
	<AANLkTi=XhYZKRbioK3Np+CUpqghLofMCdN0Wd5+2aB8V@mail.gmail.com>
	<AANLkTinJ=fwgtdUUOoV2=fTv=jvfju6s=niV2h6POans@mail.gmail.com>
	<AANLkTikUGK8gbysx+aAUx3FR_vc-_FUGCXTrhmJ0EReB@mail.gmail.com>
	<AANLkTimpos=kCo=B0XTAAQbx_FX6q4mg2Z1NL0y5-WWZ@mail.gmail.com>
	<AANLkTikugFbnh-pTbFs=wLkBHYkfGJW2z+kR10XKSyKz@mail.gmail.com>
Message-ID: <AANLkTim7v6YatRB6g+zrrOU=hCJDvCLLHBxb4n2pW0mN@mail.gmail.com>

On Thu, Nov 18, 2010 at 3:52 PM, Jari Bakken <jari.bakken at gmail.com> wrote:
> On Thu, Nov 18, 2010 at 4:16 PM, Jarmo <jarmo.p at gmail.com> wrote:
>> Don't forget that Oslo (Norway) is one of the most expensive places to be in
>> the world :P Maybe Jari can confirm or contradict.
>> Jarmo
>>
>
> That's true - it's a tie with Tokyo I think. Andreas is right that
> finding a space in Oslo wouldn't be a problem. I'd definitely go if it
> was in any European city though.
>
> I also like the idea of meeting up at the Selenium conference - makes
> sense to me since it looks like a lot of tools are converging on
> WebDriver/Se2 as the core technology.

I'll suggest it to the group organizing SeConf.

Simon

From watirjira at gmail.com  Sun Nov 21 16:48:19 2010
From: watirjira at gmail.com (Charley Baker (JIRA))
Date: Sun, 21 Nov 2010 15:48:19 -0600 (CST)
Subject: [Wtr-development] [JIRA] Assigned: (WTR-465) improved speed of
	filling text fields
In-Reply-To: <14796054.632.1289948720475.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <4332056.658.1290376099856.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Charley Baker reassigned WTR-465:
---------------------------------

    Assignee: Angrez

Assigning to Angrez.

> improved speed of filling text fields
> -------------------------------------
>
>                 Key: WTR-465
>                 URL: http://jira.openqa.org/browse/WTR-465
>             Project: Watir
>          Issue Type: Improvement
>          Components: FireWatir
>    Affects Versions: 1.6.7
>         Environment: Fedora Core 13, Firefox 3.6.12
>            Reporter: Mark Wieder
>            Assignee: Angrez
>
> The set method for filling text fields was operating at about one char per second, so I rewrote doKeyPress. It now works much faster for both append and set.
>       begin
>         #...existing test for max length
>       end
>       # get existing text
>       oldvalue = "#{(o.value.to_s)}"
>       # append new text
>       oldvalue += value
>       @o.value = oldvalue
>       @o.fireEvent("onKeyDown")
>       @o.fireEvent("onKeyPress")
>       @o.fireEvent("onKeyUp")
> Tried and failed to create a diff file for you...

-- 
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 alister.scott at gmail.com  Wed Nov 24 17:53:30 2010
From: alister.scott at gmail.com (Alister Scott)
Date: Thu, 25 Nov 2010 08:53:30 +1000
Subject: [Wtr-development] A solution to avoiding basic authentication
	dialogs
Message-ID: <AANLkTik19mkq14i5JZKThLXAJb9qhYMex8Fa8-sZ9bJ=@mail.gmail.com>

Hi,

I've just written about a way to avoid the 'basic authentication' dialog
boxes when using Watir.
It's on the wiki: http://wiki.openqa.org/display/WTR/Basic+Authentication
and my blog:
http://watirmelon.com/2010/11/24/elegantly-handling-basic-browser-authentication-with-watir/

Cheers,
Alister

Alister Scott
Brisbane, Australia
Watir Web Master: http://watir.com
Blog: http://watirmelon.com
LinkedIn: http://www.linkedin.com/in/alisterscott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20101125/c094a5d7/attachment-0001.html>

From tim.koops at gmail.com  Wed Nov 24 18:46:44 2010
From: tim.koops at gmail.com (Tim Koopmans)
Date: Thu, 25 Nov 2010 10:46:44 +1100
Subject: [Wtr-development] A solution to avoiding basic authentication
	dialogs
In-Reply-To: <AANLkTik19mkq14i5JZKThLXAJb9qhYMex8Fa8-sZ9bJ=@mail.gmail.com>
References: <AANLkTik19mkq14i5JZKThLXAJb9qhYMex8Fa8-sZ9bJ=@mail.gmail.com>
Message-ID: <AANLkTikCsrMykuDz_ZvV95TJROfXEhD3E-BVPTDvGtmH@mail.gmail.com>

Cool! A simple but elegant solution, thanks for sharing.

Cheers,
Tim


On Thu, Nov 25, 2010 at 9:53 AM, Alister Scott <alister.scott at gmail.com>wrote:

> Hi,
>
> I've just written about a way to avoid the 'basic authentication' dialog
> boxes when using Watir.
> It's on the wiki: http://wiki.openqa.org/display/WTR/Basic+Authentication
> and my blog:
> http://watirmelon.com/2010/11/24/elegantly-handling-basic-browser-authentication-with-watir/
>
> Cheers,
> Alister
>
> Alister Scott
> Brisbane, Australia
> Watir Web Master: http://watir.com
> Blog: http://watirmelon.com
> LinkedIn: http://www.linkedin.com/in/alisterscott
>
> _______________________________________________
> 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/20101125/04fa7317/attachment.html>

From abaird at bairdsnet.net  Thu Nov 25 00:59:46 2010
From: abaird at bairdsnet.net (Alan Baird)
Date: Wed, 24 Nov 2010 23:59:46 -0600
Subject: [Wtr-development] A solution to avoiding basic authentication
	dialogs
In-Reply-To: <AANLkTikCsrMykuDz_ZvV95TJROfXEhD3E-BVPTDvGtmH@mail.gmail.com>
References: <AANLkTik19mkq14i5JZKThLXAJb9qhYMex8Fa8-sZ9bJ=@mail.gmail.com>
	<AANLkTikCsrMykuDz_ZvV95TJROfXEhD3E-BVPTDvGtmH@mail.gmail.com>
Message-ID: <AANLkTim04FPkBB3-0_xbdeL9n=xqUevh3TbFXr8GiM4-@mail.gmail.com>

Alister -

Did you get this to work with IE7?  This article (
http://support.microsoft.com/kb/834489) seems to indicate it doesn't work
past IE6.

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

From jarmo.p at gmail.com  Thu Nov 25 06:02:07 2010
From: jarmo.p at gmail.com (Jarmo)
Date: Thu, 25 Nov 2010 13:02:07 +0200
Subject: [Wtr-development] A solution to avoiding basic authentication
	dialogs
In-Reply-To: <AANLkTim04FPkBB3-0_xbdeL9n=xqUevh3TbFXr8GiM4-@mail.gmail.com>
References: <AANLkTik19mkq14i5JZKThLXAJb9qhYMex8Fa8-sZ9bJ=@mail.gmail.com>
	<AANLkTikCsrMykuDz_ZvV95TJROfXEhD3E-BVPTDvGtmH@mail.gmail.com>
	<AANLkTim04FPkBB3-0_xbdeL9n=xqUevh3TbFXr8GiM4-@mail.gmail.com>
Message-ID: <AANLkTikorQYcq5MFnaeeUSZeQj12Qu_ym4ddc6b1vwMQ@mail.gmail.com>

Didn't this section help you either?

How to disable the new default behavior for handling user information in
HTTP or HTTPS URLsTo disable the new default behavior in Windows Explorer
and Internet Explorer, create*iexplore.exe* and *explorer.exe* DWORD values
in one of the following registry keys and set their value data to *0*.

   - For all users of the program, set the value in the following registry
   key:
   HKEY_LOCAL_MACHINE\Software\Microsoft\Internet
   Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE
   - For the current user of the program only, set the value in the
   following registry key:
   HKEY_CURRENT_USER\Software\Microsoft\Internet
   Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE

   Jarmo


On Thu, Nov 25, 2010 at 7:59 AM, Alan Baird <abaird at bairdsnet.net> wrote:

> Alister -
>
> Did you get this to work with IE7?  This article (
> http://support.microsoft.com/kb/834489) seems to indicate it doesn't work
> past IE6.
>
> 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/20101125/76715fae/attachment.html>

From simon.m.stewart at gmail.com  Thu Nov 25 06:24:54 2010
From: simon.m.stewart at gmail.com (Simon Stewart)
Date: Thu, 25 Nov 2010 11:24:54 +0000
Subject: [Wtr-development] Selenium Conference
In-Reply-To: <AANLkTim7v6YatRB6g+zrrOU=hCJDvCLLHBxb4n2pW0mN@mail.gmail.com>
References: <AANLkTik2t=u9Bzg1mBd5xkh5Cmw7k+5zE5R_eMSn+XQA@mail.gmail.com>
	<AANLkTimL6Uob6YUpqdj6DWDa9ggCiGVsJ-+PsBk4Z7O_@mail.gmail.com>
	<AANLkTimOXmbo3C7bHNxH7fT23F2_P5tr1jXmgBT2isx8@mail.gmail.com>
	<AANLkTi=XhYZKRbioK3Np+CUpqghLofMCdN0Wd5+2aB8V@mail.gmail.com>
	<AANLkTinJ=fwgtdUUOoV2=fTv=jvfju6s=niV2h6POans@mail.gmail.com>
	<AANLkTikUGK8gbysx+aAUx3FR_vc-_FUGCXTrhmJ0EReB@mail.gmail.com>
	<AANLkTimpos=kCo=B0XTAAQbx_FX6q4mg2Z1NL0y5-WWZ@mail.gmail.com>
	<AANLkTikugFbnh-pTbFs=wLkBHYkfGJW2z+kR10XKSyKz@mail.gmail.com>
	<AANLkTim7v6YatRB6g+zrrOU=hCJDvCLLHBxb4n2pW0mN@mail.gmail.com>
Message-ID: <AANLkTi=ND78qRB_kw01LLhZsEJ=qzyyWquAEe0ytWqOg@mail.gmail.com>

On Thu, Nov 18, 2010 at 5:06 PM, Simon Stewart
<simon.m.stewart at gmail.com> wrote:
> On Thu, Nov 18, 2010 at 3:52 PM, Jari Bakken <jari.bakken at gmail.com> wrote:
>> On Thu, Nov 18, 2010 at 4:16 PM, Jarmo <jarmo.p at gmail.com> wrote:
>>> Don't forget that Oslo (Norway) is one of the most expensive places to be in
>>> the world :P Maybe Jari can confirm or contradict.
>>> Jarmo
>>>
>>
>> That's true - it's a tie with Tokyo I think. Andreas is right that
>> finding a space in Oslo wouldn't be a problem. I'd definitely go if it
>> was in any European city though.
>>
>> I also like the idea of meeting up at the Selenium conference - makes
>> sense to me since it looks like a lot of tools are converging on
>> WebDriver/Se2 as the core technology.
>
> I'll suggest it to the group organizing SeConf.

If anyone here wants to join the mailing list where this is all being
planned and have their say, head over to
http://groups.google.com/group/seconf It'd be great to have you join
in :)

Cheers,

Simon

From zeljko.filipin at wa-research.ch  Thu Nov 25 09:21:14 2010
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Thu, 25 Nov 2010 15:21:14 +0100
Subject: [Wtr-development] Watir Conference
Message-ID: <AANLkTinReHU+f_9uPyXBzufND=gdDfgr5y78j_N_Q=K_@mail.gmail.com>

I have exchanged a few e-mails with Bret recently about his plan to visit
Europe in summer of 2011. He said he would like us to organize a small
conference where we could meet up.

About early June 2011 he will visit Zagreb (Croatia, where I live). I have
offered to organize a small conference here. I would find a venue, suggest
hotels, pick people at the airport, arrange sightseeing, brew some beer for
the event...

We would probably give presentations during the mornings and then pair in
the afternoon.

I can arrange sightseeing for people that arrive a few days earlier or stay
a few days after the conference. There are a few places to visit here.

For the people that would pay for the trip themselves, Zagreb is cheaper
than most European capitals.

What do you think?

?eljko
--
watir.com - community manager
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/20101125/38eaa663/attachment.html>

From watirjira at gmail.com  Thu Nov 25 10:53:20 2010
From: watirjira at gmail.com (Aliaksandr (JIRA))
Date: Thu, 25 Nov 2010 09:53:20 -0600 (CST)
Subject: [Wtr-development] [JIRA] Created: (WTR-466) Issues to sync
 correctly with page load in watir1.6.7
Message-ID: <21450679.700.1290700400264.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>

Issues to sync correctly with page load in watir1.6.7
-----------------------------------------------------

                 Key: WTR-466
                 URL: http://jira.openqa.org/browse/WTR-466
             Project: Watir
          Issue Type: Bug
          Components: Wait
    Affects Versions: 1.6.7
         Environment: Win XP IE6, IE7
            Reporter: Aliaksandr
            Priority: Major


Hi, 

We have recently updated our test environments to watir1.6.7 and our 
scripts start to fail waiting for page to be fully loaded. Failures 
happen when a script tries to access certain html elements on the page 
while it is actually still loading. 

We were able to figure out the cause of this behaviour. It is due to the 
READYSTATE_INTERACTIVE state was added as the state to determine 
browser load is complete: 

ie-process.rb: 
# Used internally to determine when IE has finished loading a page 
READYSTATE_INTERACTIVE = 3 

Wondering, what was the reason to include it? 

This is an urgent issue for us (we have quite a few physical and virtual client boxes for automation execution, which need a fix), so very appreciate your help. For now we have to downgrade to watir1.6.5 throughout our test environment.


Best Regards,
Alex

-- 
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 Nov 25 10:53:20 2010
From: watirjira at gmail.com (Aliaksandr (JIRA))
Date: Thu, 25 Nov 2010 09:53:20 -0600 (CST)
Subject: [Wtr-development] [JIRA] Commented: (WTR-466) Issues to sync
 correctly with page load in watir1.6.7
In-Reply-To: <21450679.700.1290700400264.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <24152427.702.1290700400425.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Aliaksandr commented on WTR-466:
--------------------------------

I have also raised it at: http://groups.google.com/group/watir-general/browse_thread/thread/61dd51ad33c55200

> Issues to sync correctly with page load in watir1.6.7
> -----------------------------------------------------
>
>                 Key: WTR-466
>                 URL: http://jira.openqa.org/browse/WTR-466
>             Project: Watir
>          Issue Type: Bug
>          Components: Wait
>    Affects Versions: 1.6.7
>         Environment: Win XP IE6, IE7
>            Reporter: Aliaksandr
>            Priority: Major
>
> Hi, 
> We have recently updated our test environments to watir1.6.7 and our 
> scripts start to fail waiting for page to be fully loaded. Failures 
> happen when a script tries to access certain html elements on the page 
> while it is actually still loading. 
> We were able to figure out the cause of this behaviour. It is due to the 
> READYSTATE_INTERACTIVE state was added as the state to determine 
> browser load is complete: 
> ie-process.rb: 
> # Used internally to determine when IE has finished loading a page 
> READYSTATE_INTERACTIVE = 3 
> Wondering, what was the reason to include it? 
> This is an urgent issue for us (we have quite a few physical and virtual client boxes for automation execution, which need a fix), so very appreciate your help. For now we have to downgrade to watir1.6.5 throughout our test environment.
> Best Regards,
> Alex

-- 
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 Nov 25 10:55:19 2010
From: watirjira at gmail.com (Aliaksandr (JIRA))
Date: Thu, 25 Nov 2010 09:55:19 -0600 (CST)
Subject: [Wtr-development] [JIRA] Commented: (WTR-464) uninstalling watir
 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
In-Reply-To: <25628117.550.1289243719870.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <4990822.705.1290700519846.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Aliaksandr commented on WTR-464:
--------------------------------

Hi Jarmo, 

We also have to downgrade due to this issue: WTR-466

> uninstalling watir 1.6.7 does not uninstall commonwatir 1.6.7 and firewatir 1.6.7
> ---------------------------------------------------------------------------------
>
>                 Key: WTR-464
>                 URL: http://jira.openqa.org/browse/WTR-464
>             Project: Watir
>          Issue Type: Bug
>          Components: Gem installer
>    Affects Versions: 1.6.7
>         Environment: win xp ie7
>            Reporter: Alan Baird
>            Assignee: Jarmo Pertman
>            Priority: Major
>
> After uninstalling watir 1.6.7, and installing watir 1.6.6, Watir throws a LoadError trying to load watir/ie.  I looked at the versions that were installed and noticed that commonwatir and firewatir did not get uninstalled when Watir::IE was uninstalled.  The workaround is to manually uninstall commonwatir and firewatir.
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::IE.new
> LoadError: no such file to load -- watir/ie
>         from (irb):2
> irb(main):003:0> br = Watir::Browser.new
> Watir::Exception::UnableToStartJSShException: Unable to connect to machine : 127.0.0.1 on port 9997. Make sure that JSSh is properly installed and Fir
> efox is running with '-jssh' option
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:156:in `set_defaults'
>         from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.7/lib/firewatir/firefox.rb:50:in `initialize'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from c:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.7/lib/watir/browser.rb:65:in `new'
>         from (irb):3
> irb(main):004:0> exit
> # uninstall commonwatir and firewatir
> N:\gauntlet>gem uninstall commonwatir -v 1.6.7
> You have requested to uninstall the gem:
>         commonwatir-1.6.7
> firewatir-1.6.7 depends on [commonwatir (= 1.6.7)]
> If you remove this gems, one or more dependencies will not be met.
> Continue with Uninstall? [Yn]  y
> Successfully uninstalled commonwatir-1.6.7
> N:\gauntlet>gem uninstall firewatir -v 1.6.7
> Successfully uninstalled firewatir-1.6.7
> # test to see if Watir works
> N:\gauntlet>irb --noreadline
> irb(main):001:0> require 'watir'
> => true
> irb(main):002:0> br = Watir::Browser.new
> => #<Watir::IE:0x40f7d88 url="about:blank" title="">
> irb(main):003:0> br.close
> => nil
> irb(main):004:0> br = Watir::IE.new
> => #<Watir::IE:0x40f0e84 url="about:blank" 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  Thu Nov 25 11:56:20 2010
From: watirjira at gmail.com (Jarmo Pertman (JIRA))
Date: Thu, 25 Nov 2010 10:56:20 -0600 (CST)
Subject: [Wtr-development] [JIRA] Commented: (WTR-466) Issues to sync
 correctly with page load in watir1.6.7
In-Reply-To: <21450679.700.1290700400264.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <13466058.707.1290704180443.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Jarmo Pertman commented on WTR-466:
-----------------------------------

The reason to include it was WTR-446. I'm using 1.6.7 at my workplace with tests running 24/7 and don't see this kind of issues. I'm wondering if there's something really specific which might cause that. It would be great if someone could make some reproducable case.

Also, what kind of an application are you using? Do you have frames? What kind of things fail? Are they related with JavaScript and/or Ajax?

Can you try with IE8 (maybe it's an older browsers problem, since i'm using IE8) and see if that happens then also?

Of course it would be also great if there's some ideas as to why browser won't be READYSTATE_COMPLETE as described in WTR-446 - maybe there's some better solution for that problem afterall?

> Issues to sync correctly with page load in watir1.6.7
> -----------------------------------------------------
>
>                 Key: WTR-466
>                 URL: http://jira.openqa.org/browse/WTR-466
>             Project: Watir
>          Issue Type: Bug
>          Components: Wait
>    Affects Versions: 1.6.7
>         Environment: Win XP IE6, IE7
>            Reporter: Aliaksandr
>            Priority: Major
>
> Hi, 
> We have recently updated our test environments to watir1.6.7 and our 
> scripts start to fail waiting for page to be fully loaded. Failures 
> happen when a script tries to access certain html elements on the page 
> while it is actually still loading. 
> We were able to figure out the cause of this behaviour. It is due to the 
> READYSTATE_INTERACTIVE state was added as the state to determine 
> browser load is complete: 
> ie-process.rb: 
> # Used internally to determine when IE has finished loading a page 
> READYSTATE_INTERACTIVE = 3 
> Wondering, what was the reason to include it? 
> This is an urgent issue for us (we have quite a few physical and virtual client boxes for automation execution, which need a fix), so very appreciate your help. For now we have to downgrade to watir1.6.5 throughout our test environment.
> Best Regards,
> Alex

-- 
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 alister.scott at gmail.com  Fri Nov 26 17:18:40 2010
From: alister.scott at gmail.com (Alister Scott)
Date: Sat, 27 Nov 2010 08:18:40 +1000
Subject: [Wtr-development] A solution to avoiding basic authentication
	dialogs
In-Reply-To: <AANLkTim04FPkBB3-0_xbdeL9n=xqUevh3TbFXr8GiM4-@mail.gmail.com>
References: <AANLkTik19mkq14i5JZKThLXAJb9qhYMex8Fa8-sZ9bJ=@mail.gmail.com>
	<AANLkTikCsrMykuDz_ZvV95TJROfXEhD3E-BVPTDvGtmH@mail.gmail.com>
	<AANLkTim04FPkBB3-0_xbdeL9n=xqUevh3TbFXr8GiM4-@mail.gmail.com>
Message-ID: <-4456738819617039631@unknownmsgid>

It is disabled by default from IE6+, so you need to set the reg keys to
enable it. The it's all fine for IE6, IE7 and IE8.

Cheers,


Alister Scott
Brisbane, Australia
Watir Wiki Master: http://watir.com
Blog: http://watirmelon.com
Google: http://www.google.com/profiles/alister.scott
LinkedIn: http://www.linkedin.com/in/alisterscott

On 25/11/2010, at 4:19 PM, Alan Baird <abaird at bairdsnet.net> wrote:

Alister -

Did you get this to work with IE7?  This article (
http://support.microsoft.com/kb/834489) seems to indicate it doesn't work
past IE6.

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/20101127/fe72d1ea/attachment.html>

From abaird at bairdsnet.net  Sat Nov 27 12:12:31 2010
From: abaird at bairdsnet.net (Alan Baird)
Date: Sat, 27 Nov 2010 11:12:31 -0600
Subject: [Wtr-development] A solution to avoiding basic authentication
	dialogs
In-Reply-To: <-4456738819617039631@unknownmsgid>
References: <AANLkTik19mkq14i5JZKThLXAJb9qhYMex8Fa8-sZ9bJ=@mail.gmail.com>
	<AANLkTikCsrMykuDz_ZvV95TJROfXEhD3E-BVPTDvGtmH@mail.gmail.com>
	<AANLkTim04FPkBB3-0_xbdeL9n=xqUevh3TbFXr8GiM4-@mail.gmail.com>
	<-4456738819617039631@unknownmsgid>
Message-ID: <AANLkTimuMe_uCArv200P=w+=MOAUkvFVYdngS41sQWUE@mail.gmail.com>

huh...guess I didn't read down far enough  :(  thanks for pointing it out.

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

From watirjira at gmail.com  Mon Nov 29 00:03:20 2010
From: watirjira at gmail.com (Bret Pettichord (JIRA))
Date: Sun, 28 Nov 2010 23:03:20 -0600 (CST)
Subject: [Wtr-development] [JIRA] Assigned: (WTR-466) Issues to sync
 correctly with page load in watir1.6.7
In-Reply-To: <21450679.700.1290700400264.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <12650390.730.1291007000558.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Bret Pettichord reassigned WTR-466:
-----------------------------------

    Assignee: Bret Pettichord

> Issues to sync correctly with page load in watir1.6.7
> -----------------------------------------------------
>
>                 Key: WTR-466
>                 URL: http://jira.openqa.org/browse/WTR-466
>             Project: Watir
>          Issue Type: Bug
>          Components: Wait
>    Affects Versions: 1.6.7
>         Environment: Win XP IE6, IE7
>            Reporter: Aliaksandr
>            Assignee: Bret Pettichord
>            Priority: Major
>
> Hi, 
> We have recently updated our test environments to watir1.6.7 and our 
> scripts start to fail waiting for page to be fully loaded. Failures 
> happen when a script tries to access certain html elements on the page 
> while it is actually still loading. 
> We were able to figure out the cause of this behaviour. It is due to the 
> READYSTATE_INTERACTIVE state was added as the state to determine 
> browser load is complete: 
> ie-process.rb: 
> # Used internally to determine when IE has finished loading a page 
> READYSTATE_INTERACTIVE = 3 
> Wondering, what was the reason to include it? 
> This is an urgent issue for us (we have quite a few physical and virtual client boxes for automation execution, which need a fix), so very appreciate your help. For now we have to downgrade to watir1.6.5 throughout our test environment.
> Best Regards,
> Alex

-- 
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  Mon Nov 29 00:05:19 2010
From: watirjira at gmail.com (Bret Pettichord (JIRA))
Date: Sun, 28 Nov 2010 23:05:19 -0600 (CST)
Subject: [Wtr-development] [JIRA] Commented: (WTR-466) Issues to sync
 correctly with page load in watir1.6.7
In-Reply-To: <21450679.700.1290700400264.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>
Message-ID: <8669615.733.1291007119807.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>


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

Bret Pettichord commented on WTR-466:
-------------------------------------

I will take a look at this.

> Issues to sync correctly with page load in watir1.6.7
> -----------------------------------------------------
>
>                 Key: WTR-466
>                 URL: http://jira.openqa.org/browse/WTR-466
>             Project: Watir
>          Issue Type: Bug
>          Components: Wait
>    Affects Versions: 1.6.7
>         Environment: Win XP IE6, IE7
>            Reporter: Aliaksandr
>            Assignee: Bret Pettichord
>            Priority: Major
>
> Hi, 
> We have recently updated our test environments to watir1.6.7 and our 
> scripts start to fail waiting for page to be fully loaded. Failures 
> happen when a script tries to access certain html elements on the page 
> while it is actually still loading. 
> We were able to figure out the cause of this behaviour. It is due to the 
> READYSTATE_INTERACTIVE state was added as the state to determine 
> browser load is complete: 
> ie-process.rb: 
> # Used internally to determine when IE has finished loading a page 
> READYSTATE_INTERACTIVE = 3 
> Wondering, what was the reason to include it? 
> This is an urgent issue for us (we have quite a few physical and virtual client boxes for automation execution, which need a fix), so very appreciate your help. For now we have to downgrade to watir1.6.5 throughout our test environment.
> Best Regards,
> Alex

-- 
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 lyfi2003 at sina.com  Sat Nov 27 06:12:58 2010
From: lyfi2003 at sina.com (=?gbk?B?wO7Rx7fJ?=)
Date: Sat, 27 Nov 2010 19:12:58 +0800
Subject: [Wtr-development] Wtr-development Digest, Vol 43, Issue 10
In-Reply-To: <mailman.67.1290700402.28199.wtr-development@rubyforge.org>
References: <mailman.67.1290700402.28199.wtr-development@rubyforge.org>
Message-ID: <op.vmttfwva3ehsck@www-58312e89556>

I also get the same problem to sync page loading.

Then i think i have a good way to avoid it .

like this:

in watir_ext.rb

require 'watir'
module Watir
  class Element
     def assert_exists
       # here is the code to solve , aslo can solve the problem about ajax  
sync load.
       Watir::Waiter::wait_until(15) { exist? }
       locate if respond_to?(:locate)
       unless ole_object
         raise UnknownObjectException.new(
                 Watir::Exception.message_for_unable_to_locate(@how, @what))
       end
     end
  end
end

someone can tell me better method if have.
hope can help you.


? Thu, 25 Nov 2010 23:53:22  
+0800?<wtr-development-request at rubyforge.org> ??:

> Send Wtr-development mailing list submissions to
> 	wtr-development at rubyforge.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://rubyforge.org/mailman/listinfo/wtr-development
> or, via email, send a message with subject or body 'help' to
> 	wtr-development-request at rubyforge.org
>
> You can reach the person managing the list at
> 	wtr-development-owner at rubyforge.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Wtr-development digest..."
>
>
> Today's Topics:
>
>    1. Re: A solution to avoiding basic authentication	dialogs
>       (Tim Koopmans)
>    2. Re: A solution to avoiding basic authentication	dialogs
>       (Alan Baird)
>    3. Re: A solution to avoiding basic authentication	dialogs (Jarmo)
>    4. Re: Selenium Conference (Simon Stewart)
>    5. Watir Conference (?eljko Filipin)
>    6. [JIRA] Created: (WTR-466) Issues to sync correctly with page
>       load in watir1.6.7 (Aliaksandr (JIRA))
>    7. [JIRA] Commented: (WTR-466) Issues to sync correctly with
>       page load in watir1.6.7 (Aliaksandr (JIRA))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 25 Nov 2010 10:46:44 +1100
> From: Tim Koopmans <tim.koops at gmail.com>
> To: Watir development <wtr-development at rubyforge.org>
> Subject: Re: [Wtr-development] A solution to avoiding basic
> 	authentication	dialogs
> Message-ID:
> 	<AANLkTikCsrMykuDz_ZvV95TJROfXEhD3E-BVPTDvGtmH at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Cool! A simple but elegant solution, thanks for sharing.
>
> Cheers,
> Tim
>
>
> On Thu, Nov 25, 2010 at 9:53 AM, Alister Scott  
> <alister.scott at gmail.com>wrote:
>
>> Hi,
>>
>> I've just written about a way to avoid the 'basic authentication' dialog
>> boxes when using Watir.
>> It's on the wiki:  
>> http://wiki.openqa.org/display/WTR/Basic+Authentication
>> and my blog:
>> http://watirmelon.com/2010/11/24/elegantly-handling-basic-browser-authentication-with-watir/
>>
>> Cheers,
>> Alister
>>
>> Alister Scott
>> Brisbane, Australia
>> Watir Web Master: http://watir.com
>> Blog: http://watirmelon.com
>> LinkedIn: http://www.linkedin.com/in/alisterscott
>>
>> _______________________________________________
>> 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/20101125/04fa7317/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 24 Nov 2010 23:59:46 -0600
> From: Alan Baird <abaird at bairdsnet.net>
> To: Watir development <wtr-development at rubyforge.org>
> Subject: Re: [Wtr-development] A solution to avoiding basic
> 	authentication	dialogs
> Message-ID:
> 	<AANLkTim04FPkBB3-0_xbdeL9n=xqUevh3TbFXr8GiM4- at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Alister -
>
> Did you get this to work with IE7?  This article (
> http://support.microsoft.com/kb/834489) seems to indicate it doesn't work
> past IE6.
>
> Alan
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:  
> <http://rubyforge.org/pipermail/wtr-development/attachments/20101124/64ae6733/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 25 Nov 2010 13:02:07 +0200
> From: Jarmo <jarmo.p at gmail.com>
> To: Watir development <wtr-development at rubyforge.org>
> Subject: Re: [Wtr-development] A solution to avoiding basic
> 	authentication	dialogs
> Message-ID:
> 	<AANLkTikorQYcq5MFnaeeUSZeQj12Qu_ym4ddc6b1vwMQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Didn't this section help you either?
>
> How to disable the new default behavior for handling user information in
> HTTP or HTTPS URLsTo disable the new default behavior in Windows Explorer
> and Internet Explorer, create*iexplore.exe* and *explorer.exe* DWORD  
> values
> in one of the following registry keys and set their value data to *0*.
>
>    - For all users of the program, set the value in the following  
> registry
>    key:
>    HKEY_LOCAL_MACHINE\Software\Microsoft\Internet
>    Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE
>    - For the current user of the program only, set the value in the
>    following registry key:
>    HKEY_CURRENT_USER\Software\Microsoft\Internet
>    Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE
>
>    Jarmo
>
>
> On Thu, Nov 25, 2010 at 7:59 AM, Alan Baird <abaird at bairdsnet.net> wrote:
>
>> Alister -
>>
>> Did you get this to work with IE7?  This article (
>> http://support.microsoft.com/kb/834489) seems to indicate it doesn't  
>> work
>> past IE6.
>>
>> 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/20101125/76715fae/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 25 Nov 2010 11:24:54 +0000
> From: Simon Stewart <simon.m.stewart at gmail.com>
> To: Watir development <wtr-development at rubyforge.org>
> Subject: Re: [Wtr-development] Selenium Conference
> Message-ID:
> 	<AANLkTi=ND78qRB_kw01LLhZsEJ=qzyyWquAEe0ytWqOg at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Thu, Nov 18, 2010 at 5:06 PM, Simon Stewart
> <simon.m.stewart at gmail.com> wrote:
>> On Thu, Nov 18, 2010 at 3:52 PM, Jari Bakken <jari.bakken at gmail.com>  
>> wrote:
>>> On Thu, Nov 18, 2010 at 4:16 PM, Jarmo <jarmo.p at gmail.com> wrote:
>>>> Don't forget that Oslo (Norway) is one of the most expensive places  
>>>> to be in
>>>> the world :P Maybe Jari can confirm or contradict.
>>>> Jarmo
>>>>
>>>
>>> That's true - it's a tie with Tokyo I think. Andreas is right that
>>> finding a space in Oslo wouldn't be a problem. I'd definitely go if it
>>> was in any European city though.
>>>
>>> I also like the idea of meeting up at the Selenium conference - makes
>>> sense to me since it looks like a lot of tools are converging on
>>> WebDriver/Se2 as the core technology.
>>
>> I'll suggest it to the group organizing SeConf.
>
> If anyone here wants to join the mailing list where this is all being
> planned and have their say, head over to
> http://groups.google.com/group/seconf It'd be great to have you join
> in :)
>
> Cheers,
>
> Simon
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 25 Nov 2010 15:21:14 +0100
> From: ?eljko Filipin <zeljko.filipin at wa-research.ch>
> To: watir <wtr-development at rubyforge.org>
> Subject: [Wtr-development] Watir Conference
> Message-ID:
> 	<AANLkTinReHU+f_9uPyXBzufND=gdDfgr5y78j_N_Q=K_ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I have exchanged a few e-mails with Bret recently about his plan to visit
> Europe in summer of 2011. He said he would like us to organize a small
> conference where we could meet up.
>
> About early June 2011 he will visit Zagreb (Croatia, where I live). I  
> have
> offered to organize a small conference here. I would find a venue,  
> suggest
> hotels, pick people at the airport, arrange sightseeing, brew some beer  
> for
> the event...
>
> We would probably give presentations during the mornings and then pair in
> the afternoon.
>
> I can arrange sightseeing for people that arrive a few days earlier or  
> stay
> a few days after the conference. There are a few places to visit here.
>
> For the people that would pay for the trip themselves, Zagreb is cheaper
> than most European capitals.
>
> What do you think?
>
> ?eljko
> --
> watir.com - community manager
> 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/20101125/38eaa663/attachment-0001.html>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 25 Nov 2010 09:53:20 -0600 (CST)
> From: "Aliaksandr (JIRA)" <watirjira at gmail.com>
> To: wtr-development at rubyforge.org
> Subject: [Wtr-development] [JIRA] Created: (WTR-466) Issues to sync
> 	correctly with page load in watir1.6.7
> Message-ID:
> 	<21450679.700.1290700400264.JavaMail.oqa-j2ee at openqa01.managed.contegix.com>
> 	
> Content-Type: text/plain; charset=UTF-8
>
> Issues to sync correctly with page load in watir1.6.7
> -----------------------------------------------------
>
>                  Key: WTR-466
>                  URL: http://jira.openqa.org/browse/WTR-466
>              Project: Watir
>           Issue Type: Bug
>           Components: Wait
>     Affects Versions: 1.6.7
>          Environment: Win XP IE6, IE7
>             Reporter: Aliaksandr
>             Priority: Major
>
>
> Hi,
>
> We have recently updated our test environments to watir1.6.7 and our
> scripts start to fail waiting for page to be fully loaded. Failures
> happen when a script tries to access certain html elements on the page
> while it is actually still loading.
>
> We were able to figure out the cause of this behaviour. It is due to the
> READYSTATE_INTERACTIVE state was added as the state to determine
> browser load is complete:
>
> ie-process.rb:
> # Used internally to determine when IE has finished loading a page
> READYSTATE_INTERACTIVE = 3
>
> Wondering, what was the reason to include it?
>
> This is an urgent issue for us (we have quite a few physical and virtual  
> client boxes for automation execution, which need a fix), so very  
> appreciate your help. For now we have to downgrade to watir1.6.5  
> throughout our test environment.
>
>
> Best Regards,
> Alex

From zeljko.filipin at wa-research.ch  Mon Nov 29 06:34:31 2010
From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Mon, 29 Nov 2010 12:34:31 +0100
Subject: [Wtr-development] Watir Conference
In-Reply-To: <AANLkTinReHU+f_9uPyXBzufND=gdDfgr5y78j_N_Q=K_@mail.gmail.com>
References: <AANLkTinReHU+f_9uPyXBzufND=gdDfgr5y78j_N_Q=K_@mail.gmail.com>
Message-ID: <AANLkTi=byBF9bkkLw2sLYXP7ec+sg2JqY7dmJfHg3Npc@mail.gmail.com>

I guess nobody is interested in coming to Zagreb.

?eljko

On Thu, Nov 25, 2010 at 3:21 PM, ?eljko Filipin <
zeljko.filipin at wa-research.ch> wrote:

> I have exchanged a few e-mails with Bret recently about his plan to visit
> Europe in summer of 2011. He said he would like us to organize a small
> conference where we could meet up.
>
> About early June 2011 he will visit Zagreb (Croatia, where I live). I have
> offered to organize a small conference here. I would find a venue, suggest
> hotels, pick people at the airport, arrange sightseeing, brew some beer for
> the event...
>
> We would probably give presentations during the mornings and then pair in
> the afternoon.
>
> I can arrange sightseeing for people that arrive a few days earlier or stay
> a few days after the conference. There are a few places to visit here.
>
> For the people that would pay for the trip themselves, Zagreb is cheaper
> than most European capitals.
>
> What do you think?
>
> ?eljko
> --
> watir.com - community manager
> 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/20101129/862c8001/attachment.html>

From andreastt at opera.com  Mon Nov 29 07:03:06 2010
From: andreastt at opera.com (Andreas Tolf Tolfsen)
Date: Mon, 29 Nov 2010 13:03:06 +0100
Subject: [Wtr-development] Watir Conference
In-Reply-To: <AANLkTi=byBF9bkkLw2sLYXP7ec+sg2JqY7dmJfHg3Npc@mail.gmail.com>
References: <AANLkTinReHU+f_9uPyXBzufND=gdDfgr5y78j_N_Q=K_@mail.gmail.com>
	<AANLkTi=byBF9bkkLw2sLYXP7ec+sg2JqY7dmJfHg3Npc@mail.gmail.com>
Message-ID: <20101129120306.GB22497@e-tjenesten.org>

* Also sprach ?eljko Filipin <zeljko.filipin at wa-research.ch>:
> I guess nobody is interested in coming to Zagreb.

I will travel to Zagreb for the conference if it is held there.  The
same pretty much applies to anywhere in Europe.

What I need confirmed as soon as possible is _when_, however.


From jari.bakken at gmail.com  Mon Nov 29 07:09:21 2010
From: jari.bakken at gmail.com (Jari Bakken)
Date: Mon, 29 Nov 2010 13:09:21 +0100
Subject: [Wtr-development] Watir Conference
In-Reply-To: <AANLkTi=byBF9bkkLw2sLYXP7ec+sg2JqY7dmJfHg3Npc@mail.gmail.com>
References: <AANLkTinReHU+f_9uPyXBzufND=gdDfgr5y78j_N_Q=K_@mail.gmail.com>
	<AANLkTi=byBF9bkkLw2sLYXP7ec+sg2JqY7dmJfHg3Npc@mail.gmail.com>
Message-ID: <AANLkTimbdc81NCf3NbdKN6fRA3uV-fFhQu0w3x4ZuhAZ@mail.gmail.com>

I'd probably come :)

On Mon, Nov 29, 2010 at 12:34 PM, ?eljko Filipin
<zeljko.filipin at wa-research.ch> wrote:
> I guess nobody is interested in coming to Zagreb.
>
> ?eljko
>
> On Thu, Nov 25, 2010 at 3:21 PM, ?eljko Filipin
> <zeljko.filipin at wa-research.ch> wrote:
>>
>> I have exchanged a few e-mails with Bret recently about his plan to visit
>> Europe in summer of 2011. He said he would like us to organize a small
>> conference where we could meet up.
>>
>> About early June 2011 he will visit Zagreb (Croatia, where I live). I have
>> offered to organize a small conference here. I would find a venue, suggest
>> hotels, pick people at the airport, arrange sightseeing, brew some beer for
>> the event...
>>
>> We would probably give presentations during the mornings and then pair in
>> the afternoon.
>>
>> I can arrange sightseeing for people that arrive a few days earlier or
>> stay a few days after the conference. There are a few places to visit here.
>>
>> For the people that would pay for the trip themselves, Zagreb is cheaper
>> than most European capitals.
>>
>> What do you think?
>>
>> ?eljko
>> --
>> watir.com - community manager
>> watirpodcast.com - host
>> testingpodcast.com - audio podcasts on software testing. all of them
>>
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>

From watirjira at gmail.com  Mon Nov 29 09:32:20 2010
From: watirjira at gmail.com (Alan Baird (JIRA))
Date: Mon, 29 Nov 2010 08:32:20 -0600 (CST)
Subject: [Wtr-development] [JIRA] Created: (WTR-467) watir-console broken on
	Ruby 1.8.7
Message-ID: <25337206.737.1291041140188.JavaMail.oqa-j2ee@openqa01.managed.contegix.com>

watir-console broken on Ruby 1.8.7
----------------------------------

                 Key: WTR-467
                 URL: http://jira.openqa.org/browse/WTR-467
             Project: Watir
          Issue Type: Bug
          Components: Other
    Affects Versions: 1.6.7
         Environment: win 7 running ruby 1.8.7
            Reporter: Alan Baird


When running watir-console with Ruby 1.8.7, I get the following error message:
{code}
C:\Users\Alan>watir-console
C:/ruby/Ruby-187-p302/lib/ruby/gems/1.8/gems/watir-1.6.7/lib/watir/irb-history.rb:3:TypeError: History is not a module
{code}

For some reason, it seems that in 1.8.7, the Readline module has a class History inserted in it which is throwing the error message you see (in ruby you can't define a Module with the same name as an existing class).  I tried to see if I could fix this.  One fix seemed to be to change line 3 in irb-history.rb to use a Class instead of a Module.  This doesn't give me the error message, but the functionality suggests that it should write my commands to 'console.log' - which it doesn't.

Oddly enough, I couldn't get output to console.log to work at all in 1.8.6. 

I've mainly tested this with Watir 1.6.7 and ruby 1.8.7 (2010-08-16 patchlevel 302) [i386-mingw32].  I have no reason to believe that this would be any different for previous versions of Watir since the conflict is in irb-history.

WORKAROUND: A very simple/hacky fix is to remove "-r watir/irb-history" from the last line (line 7) of watir-console, however, this will disable sending irb commands to 'console.log'.

BTW - I've found Pik to be really useful in testing this behavior on Windows.

Alan

-- 
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  Mon Nov 29 10:05:23 2010
From: jarmo.p at gmail.com (Jarmo)
Date: Mon, 29 Nov 2010 17:05:23 +0200
Subject: [Wtr-development] Watir Conference
In-Reply-To: <AANLkTimbdc81NCf3NbdKN6fRA3uV-fFhQu0w3x4ZuhAZ@mail.gmail.com>
References: <AANLkTinReHU+f_9uPyXBzufND=gdDfgr5y78j_N_Q=K_@mail.gmail.com>
	<AANLkTi=byBF9bkkLw2sLYXP7ec+sg2JqY7dmJfHg3Npc@mail.gmail.com>
	<AANLkTimbdc81NCf3NbdKN6fRA3uV-fFhQu0w3x4ZuhAZ@mail.gmail.com>
Message-ID: <AANLkTinTHh+FtORAUhYggajUHmJtRpAv_s3noO7N5Zr=@mail.gmail.com>

Depending of my financial situation at that time i might come also.

Jarmo

On Mon, Nov 29, 2010 at 2:09 PM, Jari Bakken <jari.bakken at gmail.com> wrote:

> I'd probably come :)
>
> On Mon, Nov 29, 2010 at 12:34 PM, ?eljko Filipin
> <zeljko.filipin at wa-research.ch> wrote:
> > I guess nobody is interested in coming to Zagreb.
> >
> > ?eljko
> >
> > On Thu, Nov 25, 2010 at 3:21 PM, ?eljko Filipin
> > <zeljko.filipin at wa-research.ch> wrote:
> >>
> >> I have exchanged a few e-mails with Bret recently about his plan to
> visit
> >> Europe in summer of 2011. He said he would like us to organize a small
> >> conference where we could meet up.
> >>
> >> About early June 2011 he will visit Zagreb (Croatia, where I live). I
> have
> >> offered to organize a small conference here. I would find a venue,
> suggest
> >> hotels, pick people at the airport, arrange sightseeing, brew some beer
> for
> >> the event...
> >>
> >> We would probably give presentations during the mornings and then pair
> in
> >> the afternoon.
> >>
> >> I can arrange sightseeing for people that arrive a few days earlier or
> >> stay a few days after the conference. There are a few places to visit
> here.
> >>
> >> For the people that would pay for the trip themselves, Zagreb is cheaper
> >> than most European capitals.
> >>
> >> What do you think?
> >>
> >> ?eljko
> >> --
> >> watir.com - community manager
> >> watirpodcast.com - host
> >> testingpodcast.com - audio podcasts on software testing. all of them
> >>
> >
> >
> > _______________________________________________
> > 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/20101129/a258296e/attachment.html>

From alister.scott at gmail.com  Mon Nov 29 13:50:28 2010
From: alister.scott at gmail.com (Alister Scott)
Date: Tue, 30 Nov 2010 04:50:28 +1000
Subject: [Wtr-development] Watir Conference
In-Reply-To: <AANLkTi=byBF9bkkLw2sLYXP7ec+sg2JqY7dmJfHg3Npc@mail.gmail.com>
References: <AANLkTinReHU+f_9uPyXBzufND=gdDfgr5y78j_N_Q=K_@mail.gmail.com>
	<AANLkTi=byBF9bkkLw2sLYXP7ec+sg2JqY7dmJfHg3Npc@mail.gmail.com>
Message-ID: <-4928791524353988205@unknownmsgid>

Sorry but it's too far for me. It's 30 hours flying time for me minimum, if
I get good flights.
San Francisco is 16 hours flying time and a third of the ticket price.
So, I am looking at going to the Selenium Conference in April in SF
instead.

Cheers,

Alister Scott
Brisbane, Australia
Watir Wiki Master: http://watir.com
Blog: http://watirmelon.com
Google: http://www.google.com/profiles/alister.scott
LinkedIn: http://www.linkedin.com/in/alisterscott

On 29/11/2010, at 9:54 PM, "?eljko Filipin" <zeljko.filipin at wa-research.ch>
wrote:

I guess nobody is interested in coming to Zagreb.

?eljko

On Thu, Nov 25, 2010 at 3:21 PM, ?eljko Filipin <
zeljko.filipin at wa-research.ch> wrote:

> I have exchanged a few e-mails with Bret recently about his plan to visit
> Europe in summer of 2011. He said he would like us to organize a small
> conference where we could meet up.
>
> About early June 2011 he will visit Zagreb (Croatia, where I live). I have
> offered to organize a small conference here. I would find a venue, suggest
> hotels, pick people at the airport, arrange sightseeing, brew some beer for
> the event...
>
> We would probably give presentations during the mornings and then pair in
> the afternoon.
>
> I can arrange sightseeing for people that arrive a few days earlier or stay
> a few days after the conference. There are a few places to visit here.
>
> For the people that would pay for the trip themselves, Zagreb is cheaper
> than most European capitals.
>
> What do you think?
>
> ?eljko
> --
> watir.com - community manager
> watirpodcast.com - host
> testingpodcast.com - audio podcasts on software testing. all of them
>
>
_______________________________________________
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/20101130/01acaccc/attachment-0001.html>

From charley.baker at gmail.com  Mon Nov 29 14:39:17 2010
From: charley.baker at gmail.com (Charley Baker)
Date: Mon, 29 Nov 2010 12:39:17 -0700
Subject: [Wtr-development] Watir Conference
In-Reply-To: <-4928791524353988205@unknownmsgid>
References: <AANLkTinReHU+f_9uPyXBzufND=gdDfgr5y78j_N_Q=K_@mail.gmail.com>
	<AANLkTi=byBF9bkkLw2sLYXP7ec+sg2JqY7dmJfHg3Npc@mail.gmail.com>
	<-4928791524353988205@unknownmsgid>
Message-ID: <AANLkTim+S_Foooz9+CGxBfw2TnwSU6ngQZVXU5tVpTqp@mail.gmail.com>

I'd love to go out, but dependent on job and funds, that may or may
not happen. Alister, is the Se meeting on the calendar now?

Cheers,

Charley Baker
Lead Developer, Watir, http://watir.com



2010/11/29 Alister Scott <alister.scott at gmail.com>:
> Sorry but it's too far for me. It's 30 hours flying time for me minimum, if
> I get good flights.
> San Francisco is 16 hours flying time and a third of the ticket price.
> So, I am looking at going to the Selenium Conference in April in SF
> instead.
> Cheers,
> Alister Scott
> Brisbane, Australia
> Watir Wiki Master: http://watir.com
> Blog: http://watirmelon.com
> Google: http://www.google.com/profiles/alister.scott
> LinkedIn: http://www.linkedin.com/in/alisterscott
> On 29/11/2010, at 9:54 PM, "?eljko Filipin" <zeljko.filipin at wa-research.ch>
> wrote:
>
> I guess nobody is interested in coming to Zagreb.
>
> ?eljko
>
> On Thu, Nov 25, 2010 at 3:21 PM, ?eljko Filipin
> <zeljko.filipin at wa-research.ch> wrote:
>>
>> I have exchanged a few e-mails with Bret recently about his plan to visit
>> Europe in summer of 2011. He said he would like us to organize a small
>> conference where we could meet up.
>>
>> About early June 2011 he will visit Zagreb (Croatia, where I live). I have
>> offered to organize a small conference here. I would find a venue, suggest
>> hotels, pick people at the airport, arrange sightseeing, brew some beer for
>> the event...
>>
>> We would probably give presentations during the mornings and then pair in
>> the afternoon.
>>
>> I can arrange sightseeing for people that arrive a few days earlier or
>> stay a few days after the conference. There are a few places to visit here.
>>
>> For the people that would pay for the trip themselves, Zagreb is cheaper
>> than most European capitals.
>>
>> What do you think?
>>
>> ?eljko
>> --
>> watir.com - community manager
>> watirpodcast.com - host
>> testingpodcast.com - audio podcasts on software testing. all of them
>>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>

From bret at pettichord.com  Mon Nov 29 16:27:41 2010
From: bret at pettichord.com (Bret Pettichord)
Date: Mon, 29 Nov 2010 15:27:41 -0600
Subject: [Wtr-development] Watir Conference
In-Reply-To: <AANLkTim+S_Foooz9+CGxBfw2TnwSU6ngQZVXU5tVpTqp@mail.gmail.com>
References: <AANLkTinReHU+f_9uPyXBzufND=gdDfgr5y78j_N_Q=K_@mail.gmail.com>
	<AANLkTi=byBF9bkkLw2sLYXP7ec+sg2JqY7dmJfHg3Npc@mail.gmail.com>
	<-4928791524353988205@unknownmsgid>
	<AANLkTim+S_Foooz9+CGxBfw2TnwSU6ngQZVXU5tVpTqp@mail.gmail.com>
Message-ID: <AANLkTi=Cc-Gphmx+9=FTZ2aBF0hCWgj_8pX4EyshDVqn@mail.gmail.com>

The Selenium meeting is April 1-3 in San Francisco. I would like to see if
we can do a Watir meetup there too. It sounds like a big announcement will
be made about this conference this week.

I think we are 90% on for some kind of Watir meeting in Zagreb this summer.
We have not yet decided a date and need to work on this. I just spoke with
Marek J about this. He will be in Bremen this summer and likes the idea of
taking the train to Zagreb. My sense is that it will be 10 - 25 people.

I'm not used to planning this kind of thing this far out ahead, but I have
heard that the planning horizon is someone longer in Europe than it
typically is in North America.

The next step would be put together a planning committee to decide on final
details and then make an announcement. I usually like to have three or four
people, with a preference for people who have attended similar workshops
(AWTA or otherwise) in the past.

Bret

On Mon, Nov 29, 2010 at 1:39 PM, Charley Baker <charley.baker at gmail.com>wrote:

> I'd love to go out, but dependent on job and funds, that may or may
> not happen. Alister, is the Se meeting on the calendar now?
>
> Cheers,
>
> Charley Baker
> Lead Developer, Watir, http://watir.com
>
>
>
> 2010/11/29 Alister Scott <alister.scott at gmail.com>:
> > Sorry but it's too far for me. It's 30 hours flying time for me minimum,
> if
> > I get good flights.
> > San Francisco is 16 hours flying time and a third of the ticket price.
> > So, I am looking at going to the Selenium Conference in April in SF
> > instead.
> > Cheers,
> > Alister Scott
> > Brisbane, Australia
> > Watir Wiki Master: http://watir.com
> > Blog: http://watirmelon.com
> > Google: http://www.google.com/profiles/alister.scott
> > LinkedIn: http://www.linkedin.com/in/alisterscott
> > On 29/11/2010, at 9:54 PM, "?eljko Filipin" <
> zeljko.filipin at wa-research.ch>
> > wrote:
> >
> > I guess nobody is interested in coming to Zagreb.
> >
> > ?eljko
> >
> > On Thu, Nov 25, 2010 at 3:21 PM, ?eljko Filipin
> > <zeljko.filipin at wa-research.ch> wrote:
> >>
> >> I have exchanged a few e-mails with Bret recently about his plan to
> visit
> >> Europe in summer of 2011. He said he would like us to organize a small
> >> conference where we could meet up.
> >>
> >> About early June 2011 he will visit Zagreb (Croatia, where I live). I
> have
> >> offered to organize a small conference here. I would find a venue,
> suggest
> >> hotels, pick people at the airport, arrange sightseeing, brew some beer
> for
> >> the event...
> >>
> >> We would probably give presentations during the mornings and then pair
> in
> >> the afternoon.
> >>
> >> I can arrange sightseeing for people that arrive a few days earlier or
> >> stay a few days after the conference. There are a few places to visit
> here.
> >>
> >> For the people that would pay for the trip themselves, Zagreb is cheaper
> >> than most European capitals.
> >>
> >> What do you think?
> >>
> >> ?eljko
> >> --
> >> watir.com - community manager
> >> watirpodcast.com - host
> >> testingpodcast.com - audio podcasts on software testing. all of them
> >>
> >
> > _______________________________________________
> > Wtr-development mailing list
> > Wtr-development at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/wtr-development
> >
> > _______________________________________________
> > Wtr-development mailing list
> > Wtr-development at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/wtr-development
> >
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>



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

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