From bret at pettichord.com Thu Jun 2 18:10:05 2011 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 2 Jun 2011 17:10:05 -0500 Subject: [Wtr-development] Next release of Watir Message-ID: Hugh McGowan is finishing up work on a new release of watir. This version (1.9) will include: * Support for IE9 * Full support for Ruby 1.8.7 * Remove Autoit (replaced with Rautomation) * Remove WinClicker (RIP) I have asked him to put out a release candidate when he is ready. This version has already been in use with a couple of our teams at Convio. Could you all work with Hugh to help him with this? He'll need access to Rubygems.org. I will be on vacation for the next two weeks, and mostly offline during that time. Bret -- Bret Pettichord Director, Watir Project, www.watir.com Blog, www.testingwithvision.com Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Fri Jun 3 00:51:15 2011 From: jarmo.p at gmail.com (Jarmo) Date: Fri, 3 Jun 2011 07:51:15 +0300 Subject: [Wtr-development] Next release of Watir In-Reply-To: References: Message-ID: I have already reviewed his code related with RAutomation and given some suggestions how to improve some things. I'd like to review all the current pull requests in the next couple of days before RC if it's ok. Good job again, Hugh! Sent from my non-iPhone. On Jun 3, 2011 1:47 AM, "Bret Pettichord" wrote: > Hugh McGowan is finishing up work on a new release of watir. This version > (1.9) will include: > > * Support for IE9 > * Full support for Ruby 1.8.7 > * Remove Autoit (replaced with Rautomation) > * Remove WinClicker (RIP) > > I have asked him to put out a release candidate when he is ready. This > version has already been in use with a couple of our teams at Convio. > > Could you all work with Hugh to help him with this? He'll need access to > Rubygems.org. > > I will be on vacation for the next two weeks, and mostly offline during that > time. > > Bret > > -- > Bret Pettichord > Director, Watir Project, www.watir.com > > Blog, www.testingwithvision.com > Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Fri Jun 3 03:42:11 2011 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Fri, 3 Jun 2011 09:42:11 +0200 Subject: [Wtr-development] Next release of Watir In-Reply-To: References: Message-ID: On Fri, Jun 3, 2011 at 6:51 AM, Jarmo wrote: > Sent from my non-iPhone. Did not see this one so far. :) ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Fri Jun 3 08:18:44 2011 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Fri, 3 Jun 2011 14:18:44 +0200 Subject: [Wtr-development] Next release of Watir In-Reply-To: References: Message-ID: On Fri, Jun 3, 2011 at 12:10 AM, Bret Pettichord wrote: > He'll need access to Rubygems.org. Hugh, I have added you to commonwatir, watir and firewatir gem owners at rubygems.org. I have used your yahoo e-mail, I saw you have used it for roo and rasta gems. https://rubygems.org/profiles/hmcgowan Let me know if anything should be fixed. ?eljko -- watir.com - community manager watir.com/book - author watirpodcast.com - host viaqa.mobi conference on software testing - organizer -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinsdaddy at gmail.com Fri Jun 3 09:11:38 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Fri, 3 Jun 2011 08:11:38 -0500 Subject: [Wtr-development] Next release of Watir In-Reply-To: References: Message-ID: Thanks everyone! I'll pull the IE9 changes into master this weekend. I've gotten everything to work so far except for modal dialogs - those may take a bit of work, but I can tackle that in a future release. I'll let y'all know when those changes are in. Hugh On Fri, Jun 3, 2011 at 7:18 AM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Fri, Jun 3, 2011 at 12:10 AM, Bret Pettichord > wrote: > > He'll need access to Rubygems.org. > > Hugh, I have added you to commonwatir, watir and firewatir gem owners at > rubygems.org. I have used your yahoo e-mail, I saw you have used it for > roo and rasta gems. > > https://rubygems.org/profiles/hmcgowan > > Let me know if anything should be fixed. > > ?eljko > -- > watir.com - community manager > watir.com/book - author > watirpodcast.com - host > viaqa.mobi conference on software testing - organizer > > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charley.baker at gmail.com Fri Jun 3 15:12:29 2011 From: charley.baker at gmail.com (Charley Baker) Date: Fri, 3 Jun 2011 14:12:29 -0500 Subject: [Wtr-development] Next release of Watir In-Reply-To: References: Message-ID: Awesome, I've been busy with my new job for the past several weeks, so haven't had a chance to keep up with your branch since we looked at it a month or so ago, but look forward to taking a look at it soon in master. Cheers, Charley On Fri, Jun 3, 2011 at 8:11 AM, Hugh McGowan wrote: > Thanks everyone! > > I'll pull the IE9 changes into master this weekend. I've gotten everything > to work so far except for modal dialogs - those may take a bit of work, but > I can tackle that in a future release. I'll let y'all know when those > changes are in. > > Hugh > > On Fri, Jun 3, 2011 at 7:18 AM, ?eljko Filipin < > zeljko.filipin at wa-research.ch> wrote: > >> On Fri, Jun 3, 2011 at 12:10 AM, Bret Pettichord >> wrote: >> > He'll need access to Rubygems.org. >> >> Hugh, I have added you to commonwatir, watir and firewatir gem owners at >> rubygems.org. I have used your yahoo e-mail, I saw you have used it for >> roo and rasta gems. >> >> https://rubygems.org/profiles/hmcgowan >> >> Let me know if anything should be fixed. >> >> ?eljko >> -- >> watir.com - community manager >> watir.com/book - author >> watirpodcast.com - host >> viaqa.mobi conference on software testing - organizer >> >> >> >> _______________________________________________ >> 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: From watirjira at gmail.com Sat Jun 4 10:15:56 2011 From: watirjira at gmail.com (Sokolov Ilya (JIRA)) Date: Sat, 4 Jun 2011 09:15:56 -0500 (CDT) Subject: [Wtr-development] [JIRA] Created: (WTR-479) UTF-8 Error Message-ID: <24535166.19.1307196956306.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> UTF-8 Error ----------- Key: WTR-479 URL: http://jira.openqa.org/browse/WTR-479 Project: Watir Issue Type: Bug Components: FireWatir Affects Versions: 1.8.0 Environment: ruby 1.9.2p136 (2010-12-25 revision 30365) [x86_64-darwin10.6.0] Reporter: Sokolov Ilya Priority: Major Fix For: Soon {quote} # encoding: UTF-8 require "watir" b = Watir::Browser.new() b.goto("http://ya.ru") t = b.text_field(:id, "text") t.set "??????" {quote} Create error {quote} Encoding::CompatibilityError: incompatible character encodings: ASCII-8BIT and UTF-8 method block in doKeyPress in text_field.rb method each in text_field.rb method doKeyPress in text_field.rb method set in text_field.rb method
in test.rb {quote} -- 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 colinsdaddy at gmail.com Sat Jun 4 18:11:31 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Sat, 4 Jun 2011 17:11:31 -0500 Subject: [Wtr-development] Next release of Watir In-Reply-To: References: Message-ID: Hi all, I've checked in the changes for IE9. The unit tests are passing for me on IE8 and IE9 on Win7. I'll check WinXP/IE8 in the next few days. The highlights are: * send a parameter in with ole_object.click because otherwise buttons/links would not actually get clicked in IE9 Document Standards Mode (Quirks mode worked but if the webpage changes the DOCTYPE it would fail). There's a new unit test for this case * use dispatchEvent instead of ole_object.fireEvent (if the browser version is IE9). IE9 is more compliant with the accepted standards so works a lot like firewatir...which is in fact, where I stole the code from :) * support should be there for everything except modal_dialogs which I'll try to fix in a future release. I think it's going to take some hacking in the win32ole code, so it doesn't appear to be a trivial change. If someone else could take a look at what I did for IE9, that would be great. We've been using this internally at Convio and so far so good, but extra eyes are always appreciated. Jarmo wanted to add some fixes in from pull requests. Once he gives the thumbs-up, I'll spin a RC gem. Thanks to Jarmo for wading through my changes and giving feedback! Thanks! Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Sun Jun 5 06:23:05 2011 From: jarmo.p at gmail.com (Jarmo) Date: Sun, 5 Jun 2011 13:23:05 +0300 Subject: [Wtr-development] Next release of Watir In-Reply-To: References: Message-ID: All pull requests, which didn't have any problems, got already pulled in yesterday. All watir tests are passing for me under xp ie8. Firewatir tests are having some failures, but it could be related with my vm. So it's thumbs up from me - go with the rc :) Don't forget to git pull before doing that and creating a correct git tag (using similar name as previous tags). J. On Sun, Jun 5, 2011 at 1:11 AM, Hugh McGowan wrote: > Hi all, > > I've checked in the changes for IE9. The unit tests are passing for me on > IE8 and IE9 on Win7. I'll check WinXP/IE8 in the next few days. The > highlights are: > ?? * send a parameter in with ole_object.click because otherwise > buttons/links would not actually get clicked in IE9 Document Standards Mode > (Quirks mode worked but if the webpage changes the DOCTYPE it would fail). > There's a new unit test for this case > ?? * use dispatchEvent instead of ole_object.fireEvent (if the browser > version is IE9). IE9 is more compliant with the accepted standards so works > a lot like firewatir...which is in fact, where I stole the code from :) > ?? * support should be there for everything except modal_dialogs which I'll > try to fix in a future release. I think it's going to take some hacking in > the win32ole code, so it doesn't appear to be a trivial change. > > If someone else could take a look at what I did for IE9, that would be > great. We've been using this internally at Convio and so far so good, but > extra eyes are always appreciated. > > Jarmo wanted to add some fixes in from pull requests. Once he gives the > thumbs-up, I'll spin a RC gem. > > Thanks to Jarmo for wading through my changes and giving feedback! > > Thanks! > Hugh > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From colinsdaddy at gmail.com Sun Jun 5 10:13:08 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Sun, 5 Jun 2011 09:13:08 -0500 Subject: [Wtr-development] Watir 1.9.0.rc1 Message-ID: Hi all, I've tagged 1.9.0.rc1 and added the gems to gemcutter. Take a look and let me know if you run into any issues. Thanks! Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Sun Jun 5 17:21:16 2011 From: jarmo.p at gmail.com (Jarmo) Date: Mon, 6 Jun 2011 00:21:16 +0300 Subject: [Wtr-development] Watir 1.9.0.rc1 In-Reply-To: References: Message-ID: I tried it in the context of WatirSplash and it was almost working, except FileUpload didn't change the file path to valid Windows path with "\" separators. Why did you change the class from FileField to FileUpload anyway? It is still representing FileField element, doesn't it? Jarmo On Sun, Jun 5, 2011 at 5:13 PM, Hugh McGowan wrote: > Hi all, > > I've tagged 1.9.0.rc1 and added the gems to gemcutter. Take a look and let > me know if you run into any issues. > > Thanks! > Hugh > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From colinsdaddy at gmail.com Sun Jun 5 20:20:19 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Sun, 5 Jun 2011 19:20:19 -0500 Subject: [Wtr-development] Watir 1.9.0.rc1 In-Reply-To: References: Message-ID: I changed it to distinguish between file upload and file download but Im happy to change it back if you like. For the windows path I didn't want to change the existing behavior because so much changed underneath. The current file_field in watir 1.8.1 does not do anything to the path so I felt it was safer not to touch it just yet. Thanks! Hugh Message sent from iPhone On Jun 5, 2011, at 4:21 PM, Jarmo wrote: > I tried it in the context of WatirSplash and it was almost working, > except FileUpload didn't change the file path to valid Windows path > with "\" separators. Why did you change the class from FileField to > FileUpload anyway? It is still representing FileField element, doesn't > it? > > Jarmo > > On Sun, Jun 5, 2011 at 5:13 PM, Hugh McGowan wrote: >> Hi all, >> >> I've tagged 1.9.0.rc1 and added the gems to gemcutter. Take a look and let >> me know if you run into any issues. >> >> Thanks! >> Hugh >> >> _______________________________________________ >> 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 colinsdaddy at gmail.com Sun Jun 5 21:38:05 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Sun, 5 Jun 2011 20:38:05 -0500 Subject: [Wtr-development] Watir 1.9.0.rc1 In-Reply-To: References: Message-ID: Actually thinking about it I should change the class name back otherwise I break people changing the class like you had done and there's no real good reason quite yet to make that change. Thanks! Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinsdaddy at gmail.com Mon Jun 6 08:35:22 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Mon, 6 Jun 2011 07:35:22 -0500 Subject: [Wtr-development] Watir 1.9.0.rc1 In-Reply-To: References: Message-ID: I just pushed 1.9.0.rc2. The only change is to rename the class FileUpload back to FileField. Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinsdaddy at gmail.com Mon Jun 6 16:41:05 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Mon, 6 Jun 2011 15:41:05 -0500 Subject: [Wtr-development] Watir 1.9.0.rc1 In-Reply-To: References: Message-ID: Pushed 1.9.0.rc3 to correct an issue in the javascript dialogs. It's a one-line change where an instance variable was not getting set Thanks! Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinsdaddy at gmail.com Tue Jun 7 11:06:16 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Tue, 7 Jun 2011 10:06:16 -0500 Subject: [Wtr-development] Watir 1.9.0.rc1 In-Reply-To: References: Message-ID: Pushed 1.9.0.rc4. The timeout for javascript_dialogs was not working well so I pulled this feature. Rautomation persists the timeout you set across all windows but with it being lazy you can't really set the timeout when you initialize the class and then reset it to it's original value because it won't get used until you try to do something (like find a button). Instead the user can change the timeout directly in rautomation if needed and in most uses the default behavior should be just fine. Currently the default timeout is 60s but of course the code will continue whenever the window is located. Thanks! Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Tue Jun 7 12:18:40 2011 From: jarmo.p at gmail.com (Jarmo) Date: Tue, 7 Jun 2011 19:18:40 +0300 Subject: [Wtr-development] Watir 1.9.0.rc1 In-Reply-To: References: Message-ID: Any suggestions to improve the current behavior are welcome. Maybe having a :timeout attribute would be a better solution? Jarmo On Tue, Jun 7, 2011 at 6:06 PM, Hugh McGowan wrote: > Pushed 1.9.0.rc4. The timeout for javascript_dialogs was not working well so > I pulled this feature. Rautomation persists the timeout you set across all > windows but with it being lazy you can't really set the timeout when you > initialize the class and then reset it to it's original value because it > won't get used until you try to do something (like find a button). Instead > the user can change the timeout directly in rautomation if needed and in > most uses the default behavior should be just fine. Currently the default > timeout is 60s but of course the code will continue whenever the window is > located. > > Thanks! > Hugh > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From colinsdaddy at gmail.com Tue Jun 7 14:58:46 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Tue, 7 Jun 2011 13:58:46 -0500 Subject: [Wtr-development] Watir 1.9.0.rc1 In-Reply-To: References: Message-ID: I think that would be great to have. We have a few cases, for example, where a js dialog may or may not show so we want to handle it but don't want to wait around for the whole time because it may never fire. If you decide to implement it let me know and I can roll back in the timeout - I don't think it's necessary for this release, though, so no rush :) Thanks! Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinsdaddy at gmail.com Wed Jun 8 21:43:43 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Wed, 8 Jun 2011 20:43:43 -0500 Subject: [Wtr-development] Watir 1.9.0.rc1 In-Reply-To: References: Message-ID: Hi all, I've figured out how to get full access to the IE9 modal dialogs. I've got it working pretty well and will be testing it over the next few days in IE8 and IE9 - if I can get everything running smoothly then I would like to pull this feature in. Let me know if there's a reason not to do this, but I think full IE9 support is pretty compelling. Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Thu Jun 9 12:18:56 2011 From: watirjira at gmail.com (bhavesh (JIRA)) Date: Thu, 9 Jun 2011 11:18:56 -0500 (CDT) Subject: [Wtr-development] [JIRA] Created: (WTR-480) Not able to open new IE after it is closed. Message-ID: <32779885.36.1307636336364.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Not able to open new IE after it is closed. ------------------------------------------- Key: WTR-480 URL: http://jira.openqa.org/browse/WTR-480 Project: Watir Issue Type: Bug Components: Unit Tests Affects Versions: Soon Environment: Windows XP running IE7 Reporter: bhavesh Priority: Major Fix For: Soon Hi, I have to close IE and open new IE again in every testcase. I written an routine like this : def setupnew(current_component="") $ie.close if $ie sleep(10) $ie = Watir::IE.new() sleep(10) case current_component when "WEB_ADMIN" $ie.goto($adminLink) when "WEB_REPORT" $ie.goto($reportLink) when "WEB_SEARCH" $ie.goto($searchLink) else #puts "Setup case does not match" end end This works well in Ruby 1.8 Recently i upgrade to Ruby 1.9.2 and this routine start failing. It closes the IE if it is open but then not opening the new IE it just came out of script throwing error. Error coming out as : TestCaseNum: I18N_0001 Description: Add AD Authentication from Webadmin, for FIGS. E Finished in 0.468750 seconds. 1) Error: test_0001(TC_I18N): NoMethodError: unknown property or method: `name' HRESULT error code:0x800706ba The RPC server is unavailable. C:/Ruby192/lib/ruby/gems/1.9.1/gems/watir-1.8.1/lib/watir/ie- class.rb:319:in `method_missing' C:/Ruby192/lib/ruby/gems/1.9.1/gems/watir-1.8.1/lib/watir/ie- class.rb:319:in `exists?' C:/Ruby192/lib/ruby/gems/1.9.1/gems/watir-1.8.1/lib/watir/ie- class.rb:406:in `close' C:/IE_AUTOMATION/kazeon/qa/watir-v1_4-TIP/KazModules/I18N/ I18N_Regression.rb :47:in `setupnew' C:/IE_AUTOMATION/kazeon/qa/watir-v1_4-TIP/KazModules/I18N/ I18N_Regression.rb :102:in `test_0001' I got the problem but not the solution. In watir 1.6.7 which i use previously, code for ie.close is like this : #C:\ruby\lib\ruby\gems\1.8\gems\watir-1.6.7\lib\watir # 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 In watir 1.8.1 which i use now, code for ie.close is like this : C:\Ruby192\lib\ruby\gems\1.9.1\gems\watir-1.8.1\lib\watir # Closes the Browser def close return unless exists? @ie.stop wait rescue nil chwnd = @ie.hwnd.to_i @ie.quit t = Time.now while exists? # just in case to avoid possible endless loop if failing to close some # window or tab break if Time.now - t > 10 sleep 0.3 end end There is an change in code in 1.8.1. If i replace the piece of code for ie.close of version 1.6.7 in 1.8.1 file, the same routine starts working fine. So what needs to be done now to have this working with 1.8.1 code? Bhavesh -- 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 Jun 9 12:20:56 2011 From: watirjira at gmail.com (bhavesh (JIRA)) Date: Thu, 9 Jun 2011 11:20:56 -0500 (CDT) Subject: [Wtr-development] [JIRA] Created: (WTR-481) Not able to open new IE after it is closed. Message-ID: <31083542.38.1307636456038.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Not able to open new IE after it is closed. ------------------------------------------- Key: WTR-481 URL: http://jira.openqa.org/browse/WTR-481 Project: Watir Issue Type: Bug Components: Unit Tests Affects Versions: Soon Environment: Windows XP running IE7 Reporter: bhavesh Priority: Critical Fix For: Soon Hi, I have to close IE and open new IE again in every testcase. I written an routine like this : def setupnew(current_component="") $ie.close if $ie sleep(10) $ie = Watir::IE.new() sleep(10) case current_component when "WEB_ADMIN" $ie.goto($adminLink) when "WEB_REPORT" $ie.goto($reportLink) when "WEB_SEARCH" $ie.goto($searchLink) else #puts "Setup case does not match" end end This works well in Ruby 1.8 Recently i upgrade to Ruby 1.9.2 and this routine start failing. It closes the IE if it is open but then not opening the new IE it just came out of script throwing error. Error coming out as : TestCaseNum: I18N_0001 Description: Add AD Authentication from Webadmin, for FIGS. E Finished in 0.468750 seconds. 1) Error: test_0001(TC_I18N): NoMethodError: unknown property or method: `name' HRESULT error code:0x800706ba The RPC server is unavailable. C:/Ruby192/lib/ruby/gems/1.9.1/gems/watir-1.8.1/lib/watir/ie- class.rb:319:in `method_missing' C:/Ruby192/lib/ruby/gems/1.9.1/gems/watir-1.8.1/lib/watir/ie- class.rb:319:in `exists?' C:/Ruby192/lib/ruby/gems/1.9.1/gems/watir-1.8.1/lib/watir/ie- class.rb:406:in `close' C:/IE_AUTOMATION/kazeon/qa/watir-v1_4-TIP/KazModules/I18N/ I18N_Regression.rb :47:in `setupnew' C:/IE_AUTOMATION/kazeon/qa/watir-v1_4-TIP/KazModules/I18N/ I18N_Regression.rb :102:in `test_0001' got the problem but not the solution. In watir 1.6.7 which i use previously, code for ie.close is like this : #C:\ruby\lib\ruby\gems\1.8\gems\watir-1.6.7\lib\watir # 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 In watir 1.8.1 which i use now, code for ie.close is like this : C:\Ruby192\lib\ruby\gems\1.9.1\gems\watir-1.8.1\lib\watir # Closes the Browser def close return unless exists? @ie.stop wait rescue nil chwnd = @ie.hwnd.to_i @ie.quit t = Time.now while exists? # just in case to avoid possible endless loop if failing to close some # window or tab break if Time.now - t > 10 sleep 0.3 end end There is an change in code in 1.8.1. If i replace the piece of code for ie.close of version 1.6.7 in 1.8.1 file, the same routine starts working fine. So what needs to be done now to have this working with 1.8.1 code? Bhavesh -- 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 Jun 9 12:25:56 2011 From: watirjira at gmail.com (bhavesh (JIRA)) Date: Thu, 9 Jun 2011 11:25:56 -0500 (CDT) Subject: [Wtr-development] [JIRA] Created: (WTR-482) Not able to send command to remote computer. Message-ID: <17326055.40.1307636756875.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Not able to send command to remote computer. -------------------------------------------- Key: WTR-482 URL: http://jira.openqa.org/browse/WTR-482 Project: Watir Issue Type: Bug Components: Unit Tests Affects Versions: Soon Environment: Windows XP running IE7 Reporter: bhavesh Priority: Critical Fix For: Soon Hi Earlier i have Ruby 1.8.* and my code to send command to linux box is working fine. But now i upgraded to Ruby 1.9.2. So i upgraded needle, setsftp and netssh too. Now same piece of code is not working, it throws error for on_success. This is the code in my script : ################ def issueCommandInKazBox(okMachine="", command="", matchLog="", user="admin", passwd="kazeon") puts " issueCommandInKazMachine=#{okMachine}" puts " issueCommandInKazcommand=#{command}" puts " issueCommandInKazstatus=#{matchLog}" puts " issueCommandInKazuser=#{user}" puts " issueCommandInKazpasswd=#{passwd}" tempString = "" Net::SSH.start(okMachine, user, :password => passwd, :paranoid => false ) do |session| session.open_channel do |channel| channel.on_success do puts "shell was started successfully!" puts "Adding command - #{command}..." channel.send_data "#{command}\n" channel.send_data "exit\n" # tell the shell to exit end channel.on_failure do puts "shell could not be started!" end channel.on_data do |ch,data| puts "recieved the following from shell" puts "#{data}" tempString = tempString + "\n" + data end channel.on_close do puts "shell terminated" end channel.send_request "shell", nil, true end session.loop end ############# Are libraries are changed? did we change the syntax for the command? Im stuck because of this change, my first step is to do send files to remote computer and execute few commands and then only i can start the regression suite. Can you please update me Bhavesh -- 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 Jun 9 13:59:56 2011 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Thu, 9 Jun 2011 12:59:56 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-482) Not able to send command to remote computer. In-Reply-To: <17326055.40.1307636756875.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <27065840.42.1307642396305.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarmo Pertman closed WTR-482. ----------------------------- Resolution: Not a problem I don't see how it's related with Watir. Going to close this issue. Please send your problem to ruby mailing list or the appropriate lists for the libraries you're using. > Not able to send command to remote computer. > -------------------------------------------- > > Key: WTR-482 > URL: http://jira.openqa.org/browse/WTR-482 > Project: Watir > Issue Type: Bug > Components: Unit Tests > Affects Versions: Soon > Environment: Windows XP running IE7 > Reporter: bhavesh > Priority: Critical > Fix For: Soon > > > Hi > Earlier i have Ruby 1.8.* and my code to send command to linux box is > working fine. > But now i upgraded to Ruby 1.9.2. So i upgraded needle, setsftp and > netssh too. > Now same piece of code is not working, it throws error for on_success. > This is the code in my script : > ################ > def issueCommandInKazBox(okMachine="", command="", matchLog="", > user="admin", passwd="kazeon") > puts " issueCommandInKazMachine=#{okMachine}" > puts " issueCommandInKazcommand=#{command}" > puts " issueCommandInKazstatus=#{matchLog}" > puts " issueCommandInKazuser=#{user}" > puts " issueCommandInKazpasswd=#{passwd}" > tempString = "" > Net::SSH.start(okMachine, user, :password => passwd, :paranoid => > false ) do |session| > session.open_channel do |channel| > channel.on_success do > puts "shell was started successfully!" > puts "Adding command - #{command}..." > channel.send_data "#{command}\n" > channel.send_data "exit\n" # tell the shell to exit > end > channel.on_failure do > puts "shell could not be started!" > end > channel.on_data do |ch,data| > puts "recieved the following from shell" > puts "#{data}" > tempString = tempString + "\n" + data > end > channel.on_close do > puts "shell terminated" > end > channel.send_request "shell", nil, true > end > session.loop > end > ############# > Are libraries are changed? did we change the syntax for the command? > Im stuck because of this change, my first step is to do send files to remote computer and execute few commands and then only i can start the regression suite. > Can you please update me > Bhavesh -- 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 Jun 9 17:12:56 2011 From: watirjira at gmail.com (bhavesh (JIRA)) Date: Thu, 9 Jun 2011 16:12:56 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-481) Not able to open new IE after it is closed. In-Reply-To: <31083542.38.1307636456038.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <33013931.44.1307653976523.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20181#action_20181 ] bhavesh commented on WTR-481: ----------------------------- I use watir 1.8.1 on Ruby 1.9.2. > Not able to open new IE after it is closed. > ------------------------------------------- > > Key: WTR-481 > URL: http://jira.openqa.org/browse/WTR-481 > Project: Watir > Issue Type: Bug > Components: Unit Tests > Affects Versions: Soon > Environment: Windows XP running IE7 > Reporter: bhavesh > Priority: Critical > Fix For: Soon > > > Hi, > I have to close IE and open new IE again in every testcase. > I written an routine like this : > def setupnew(current_component="") > $ie.close if $ie > sleep(10) > $ie = Watir::IE.new() > sleep(10) > case current_component > when "WEB_ADMIN" > $ie.goto($adminLink) > when "WEB_REPORT" > $ie.goto($reportLink) > when "WEB_SEARCH" > $ie.goto($searchLink) > else > #puts "Setup case does not match" > end > end > This works well in Ruby 1.8 > Recently i upgrade to Ruby 1.9.2 and this routine start failing. > It closes the IE if it is open but then not opening the new IE it > just came out of script throwing error. > Error coming out as : > TestCaseNum: I18N_0001 > Description: Add AD Authentication from Webadmin, for FIGS. > E > Finished in 0.468750 seconds. > 1) Error: > test_0001(TC_I18N): > NoMethodError: unknown property or method: `name' > HRESULT error code:0x800706ba > The RPC server is unavailable. > C:/Ruby192/lib/ruby/gems/1.9.1/gems/watir-1.8.1/lib/watir/ie- > class.rb:319:in > `method_missing' > C:/Ruby192/lib/ruby/gems/1.9.1/gems/watir-1.8.1/lib/watir/ie- > class.rb:319:in > `exists?' > C:/Ruby192/lib/ruby/gems/1.9.1/gems/watir-1.8.1/lib/watir/ie- > class.rb:406:in > `close' > C:/IE_AUTOMATION/kazeon/qa/watir-v1_4-TIP/KazModules/I18N/ > I18N_Regression.rb > :47:in `setupnew' > C:/IE_AUTOMATION/kazeon/qa/watir-v1_4-TIP/KazModules/I18N/ > I18N_Regression.rb > :102:in `test_0001' > got the problem but not the solution. > In watir 1.6.7 which i use previously, code for ie.close is like > this : > #C:\ruby\lib\ruby\gems\1.8\gems\watir-1.6.7\lib\watir > # 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 > In watir 1.8.1 which i use now, code for ie.close is like this : > C:\Ruby192\lib\ruby\gems\1.9.1\gems\watir-1.8.1\lib\watir > # Closes the Browser > def close > return unless exists? > @ie.stop > wait rescue nil > chwnd = @ie.hwnd.to_i > @ie.quit > t = Time.now > while exists? > # just in case to avoid possible endless loop if failing to > close some > # window or tab > break if Time.now - t > 10 > sleep 0.3 > end > end > There is an change in code in 1.8.1. > If i replace the piece of code for ie.close of version 1.6.7 in 1.8.1 > file, the same routine starts working fine. > So what needs to be done now to have this working with 1.8.1 code? > Bhavesh -- 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 Jun 9 17:32:56 2011 From: watirjira at gmail.com (Ethan (JIRA)) Date: Thu, 9 Jun 2011 16:32:56 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-481) Not able to open new IE after it is closed. In-Reply-To: <31083542.38.1307636456038.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <15431207.46.1307655176877.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20182#action_20182 ] Ethan commented on WTR-481: --------------------------- this is a valid bug - I encountered this when testing ruby 1.9. WIN32OLE has changed and now raises NoMethodError in some cases where it used to raise WIN32OLERuntimeError, so Watir's code that currently expects WIN32OLERuntimeError (which gets raised from WIN32OLE fairly frequently) should be changed to also rescue from NoMethodError. > Not able to open new IE after it is closed. > ------------------------------------------- > > Key: WTR-481 > URL: http://jira.openqa.org/browse/WTR-481 > Project: Watir > Issue Type: Bug > Components: Unit Tests > Affects Versions: Soon > Environment: Windows XP running IE7 > Reporter: bhavesh > Priority: Critical > Fix For: Soon > > > Hi, > I have to close IE and open new IE again in every testcase. > I written an routine like this : > def setupnew(current_component="") > $ie.close if $ie > sleep(10) > $ie = Watir::IE.new() > sleep(10) > case current_component > when "WEB_ADMIN" > $ie.goto($adminLink) > when "WEB_REPORT" > $ie.goto($reportLink) > when "WEB_SEARCH" > $ie.goto($searchLink) > else > #puts "Setup case does not match" > end > end > This works well in Ruby 1.8 > Recently i upgrade to Ruby 1.9.2 and this routine start failing. > It closes the IE if it is open but then not opening the new IE it > just came out of script throwing error. > Error coming out as : > TestCaseNum: I18N_0001 > Description: Add AD Authentication from Webadmin, for FIGS. > E > Finished in 0.468750 seconds. > 1) Error: > test_0001(TC_I18N): > NoMethodError: unknown property or method: `name' > HRESULT error code:0x800706ba > The RPC server is unavailable. > C:/Ruby192/lib/ruby/gems/1.9.1/gems/watir-1.8.1/lib/watir/ie- > class.rb:319:in > `method_missing' > C:/Ruby192/lib/ruby/gems/1.9.1/gems/watir-1.8.1/lib/watir/ie- > class.rb:319:in > `exists?' > C:/Ruby192/lib/ruby/gems/1.9.1/gems/watir-1.8.1/lib/watir/ie- > class.rb:406:in > `close' > C:/IE_AUTOMATION/kazeon/qa/watir-v1_4-TIP/KazModules/I18N/ > I18N_Regression.rb > :47:in `setupnew' > C:/IE_AUTOMATION/kazeon/qa/watir-v1_4-TIP/KazModules/I18N/ > I18N_Regression.rb > :102:in `test_0001' > got the problem but not the solution. > In watir 1.6.7 which i use previously, code for ie.close is like > this : > #C:\ruby\lib\ruby\gems\1.8\gems\watir-1.6.7\lib\watir > # 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 > In watir 1.8.1 which i use now, code for ie.close is like this : > C:\Ruby192\lib\ruby\gems\1.9.1\gems\watir-1.8.1\lib\watir > # Closes the Browser > def close > return unless exists? > @ie.stop > wait rescue nil > chwnd = @ie.hwnd.to_i > @ie.quit > t = Time.now > while exists? > # just in case to avoid possible endless loop if failing to > close some > # window or tab > break if Time.now - t > 10 > sleep 0.3 > end > end > There is an change in code in 1.8.1. > If i replace the piece of code for ie.close of version 1.6.7 in 1.8.1 > file, the same routine starts working fine. > So what needs to be done now to have this working with 1.8.1 code? > Bhavesh -- 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 Jun 10 10:35:56 2011 From: watirjira at gmail.com (Jack Desert (JIRA)) Date: Fri, 10 Jun 2011 09:35:56 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-397) How to speed up text field data entry Message-ID: <1074054.52.1307716556387.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20183#action_20183 ] Jack Desert commented on WTR-397: --------------------------------- Woah Nellie this is like molasses! It's like typing in an office that's below the freezing point. Is there something I can do? I'm running Firefox 3.6.17 on Ubuntu 10.10 Are there any candidate releases that are better? Jack > How to speed up text field data entry > ------------------------------------- > > Key: WTR-397 > URL: http://jira.openqa.org/browse/WTR-397 > Project: Watir > Issue Type: Bug > Components: FireWatir > Affects Versions: Open QA Migration > Environment: windows > Reporter: Zeljko > > - moved from http://code.google.com/p/firewatir/issues/detail?id=78 > Issue 78: How to speed up text field data entry > 4 people starred this issue and may be notified of changes. > Status: New > Owner: ---- > Type-Defect > Priority-Medium > Reported by restagner, Aug 11, 2008 > What steps will reproduce the problem? > 1. Create identical scripts for Watir/Firewatir that use data entry into > text fields > 2. Execute scripts > What is the expected output? What do you see instead? > I'd like to see the same speed/performance that Watir provides. > What version of the product are you using? On what operating system? > firewatir-1.2.0, Windows XP > Please provide any additional information below. > I'm using both Watir and FireWatir. I've developed a script that > works well with both APIs. However, it seems that when the script is > executed in FireWatir, the speed with which data is entered into text > fields is *really* slow. Anybody out there know how I can speed up > data entry into text fields for FireWatir. I've tried using > text_field.value='my value' > instead of > text_field.set 'my value' > However, it appears that using .value= results in the script missing > some of the web app's triggering events. Any help on this would be > greatly appreciated. > Regards, > Robert > --- > Comment 1 by robblovell, Aug 25, 2008 > I have noticed VERY slow text entry on a windows Server 2003 box with firefox > 2.0.0.16 and firewatir 1.2.1 (it also ran slow with 1.1.1) and jssh-WINNT-2.x.xpi. > The code runs from a ruby-rails application. The same code works fast on os/x with > the same firefox/firewatir versions. I have a linux install as well, with a self > built version of firefox 3.0 with jssh following the instructions here: > (http://ubuntu-snippets.blogspot.com/2008/07/build-firefox-3-web-browser-with-jssh.html). > This setup also runs very slowly at times for text entry with firewatir 1.2.0. > The behavior isn't consistent, sometimes it runs at normal speed, sometimes in super > slow-mo. > Any help or clues would be appreciated as to why firewatir-jssh/firefox may run super > slow. > --- > Comment 2 by robblovell, Aug 25, 2008 > here is another person who experienced a slow down: > http://www.io.com/~wazmo/blog/archives/2007_11.html > --- > Comment 3 by talksense101, May 12, 2009 > I use ruby 1.8.7 on Windows with Firefox 3.0.10 and the current version of Firewatir > as on May 12,2009. Same issue with text_field.set "xyz". It is too slow. > --- > Comment 4 by juliomonteiro, Sep 17, 2009 > Really slow. My SafariWatir (Mac OS X 10.6 + Safari) needs 50 seconds to run a bunch of tests, which FireWatir (at > Ubuntu 9.04 + Firefox 3) needs 5 minutes. -- 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 colinsdaddy at gmail.com Fri Jun 10 15:54:34 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Fri, 10 Jun 2011 14:54:34 -0500 Subject: [Wtr-development] Watir 1.9.0.rc1 In-Reply-To: References: Message-ID: I've released 1.9.0.rc5 with support for modal dialogs in IE9. This required some rework of the modal_dialog class and it's working for me on Win7 IE8 and IE9. I removed one part of the modal_dialog code, locating modal dialogs by title. This doesn't really make sense because modals don't act the same way that windows do - there can only be one active modal at any given time. In the case of modals calling modals, there's still only one that is accessible. If someone tries to pass in a title, the code will not fail and just ignore it, returning the active modal. Let me know if these changes make sense and if there's a use case I'm missing that this change could break Thanks! Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinsdaddy at gmail.com Mon Jun 13 18:40:14 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Mon, 13 Jun 2011 17:40:14 -0500 Subject: [Wtr-development] Watir 1.9.0.rc1 In-Reply-To: References: Message-ID: 1.9.0.rc6 fixes a broken implementation in fire_event. Getting further through our test suite and I'll still run for a few more days before I feel comfortable with this release :). Thanks! Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinsdaddy at gmail.com Tue Jun 14 13:53:24 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Tue, 14 Jun 2011 12:53:24 -0500 Subject: [Wtr-development] Watir 1.9.0.rc1 In-Reply-To: References: Message-ID: 1.9.0.rc7 makes highlighting work - in IE9, changing currentstyle has no effect and in some cases will throw a DOM access denied js error. Now style is used to toggle the background color. I left all other references to style as they were. Thanks! Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Tue Jun 14 14:10:34 2011 From: jarmo.p at gmail.com (Jarmo) Date: Tue, 14 Jun 2011 21:10:34 +0300 Subject: [Wtr-development] Watir 1.9.0.rc1 In-Reply-To: References: Message-ID: I have a suggestion just go with the release after you've fixed some critical bugs (it seems that happens few rc-s ago already) or otherwise you will end up releasin rc-s after rc meaning that there's even more changes, which makes it more dangerous to upgrade. Small steps are the win to success, so just go with the release. I'd suggest that you could even go with the release right now since highlighting was broke already and couldn't get any worse :) J. On Tue, Jun 14, 2011 at 8:53 PM, Hugh McGowan wrote: > 1.9.0.rc7 makes highlighting work - in IE9, changing currentstyle has no > effect and in some cases will throw a DOM access denied js error. Now style > is used to toggle the background color. I left all other references to style > as they were. > > Thanks! > Hugh > > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From colinsdaddy at gmail.com Tue Jun 14 19:33:02 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Tue, 14 Jun 2011 18:33:02 -0500 Subject: [Wtr-development] Watir 1.9.0.rc1 In-Reply-To: References: Message-ID: Yeah I think that was the last one and I was hoping to release tonight. Is there anything I need to do other than what I've done for the RCs? Thanks! Hugh Message sent from iPhone On Jun 14, 2011, at 1:10 PM, Jarmo wrote: > I have a suggestion just go with the release after you've fixed some > critical bugs (it seems that happens few rc-s ago already) or > otherwise you will end up releasin rc-s after rc meaning that there's > even more changes, which makes it more dangerous to upgrade. Small > steps are the win to success, so just go with the release. I'd suggest > that you could even go with the release right now since highlighting > was broke already and couldn't get any worse :) > > J. > > On Tue, Jun 14, 2011 at 8:53 PM, Hugh McGowan wrote: >> 1.9.0.rc7 makes highlighting work - in IE9, changing currentstyle has no >> effect and in some cases will throw a DOM access denied js error. Now style >> is used to toggle the background color. I left all other references to style >> as they were. >> >> Thanks! >> Hugh >> >> >> >> _______________________________________________ >> 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 charley.baker at gmail.com Tue Jun 14 19:42:35 2011 From: charley.baker at gmail.com (Charley Baker) Date: Tue, 14 Jun 2011 17:42:35 -0600 Subject: [Wtr-development] Watir 1.9.0.rc1 In-Reply-To: References: Message-ID: Everything looks good. Make sure to update versions, tag and release, otherwise you're golden. Interesting work on the IE9 changes, they've been surprisingly backward compatible aside from minor nits until this version. -c On Tue, Jun 14, 2011 at 5:33 PM, Hugh McGowan wrote: > Yeah I think that was the last one and I was hoping to release tonight. Is > there anything I need to do other than what I've done for the RCs? > > Thanks! > Hugh > > Message sent from iPhone > > On Jun 14, 2011, at 1:10 PM, Jarmo wrote: > > > I have a suggestion just go with the release after you've fixed some > > critical bugs (it seems that happens few rc-s ago already) or > > otherwise you will end up releasin rc-s after rc meaning that there's > > even more changes, which makes it more dangerous to upgrade. Small > > steps are the win to success, so just go with the release. I'd suggest > > that you could even go with the release right now since highlighting > > was broke already and couldn't get any worse :) > > > > J. > > > > On Tue, Jun 14, 2011 at 8:53 PM, Hugh McGowan > wrote: > >> 1.9.0.rc7 makes highlighting work - in IE9, changing currentstyle has no > >> effect and in some cases will throw a DOM access denied js error. Now > style > >> is used to toggle the background color. I left all other references to > style > >> as they were. > >> > >> Thanks! > >> Hugh > >> > >> > >> > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > >> > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinsdaddy at gmail.com Tue Jun 14 21:31:10 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Tue, 14 Jun 2011 20:31:10 -0500 Subject: [Wtr-development] Watir 1.9.0 Released Message-ID: HI all, I've released Watir 1.9.0. Thanks to Jarmo for all of his help and writing a great RAutomation gem that was easy to use and integrate into Watir. Viva RAutomation! Viva IE9! It also may be worth updating some of the help pages on Watir. The biggest thing that comes to mind is the section on javascript dialogs - these are now pretty easy to deal with now, but it differs from many of the existing examples. Thanks! Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Tue Jun 21 08:32:37 2011 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 21 Jun 2011 14:32:37 +0200 Subject: [Wtr-development] Donate to Watir In-Reply-To: References: Message-ID: We have just payed $12 for mapping watir.com to a wordpress.com hosted blog. I would like to thank everybody that already donated to Watir project, and to those that will donate in the future. :) There is donate button at http://watir.com/. We've raised $815 since January 2010. We spend it on hosting and stuff like that. You can see list of donors and Bret's thank you note: http://pledgie.com/campaigns/2982 We have also raised ?44,28 via Flattr: https://flattr.com/thing/141470/Watir ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From xgas at hot.ee Tue Jun 21 09:39:26 2011 From: xgas at hot.ee (Rain Kolk) Date: Tue, 21 Jun 2011 16:39:26 +0300 Subject: [Wtr-development] watir ie9 statusbar text Message-ID: <002101cc3018$a36b2c40$ea4184c0$@hot.ee> Hi, There seems to be bug with IE9 statusbar text. I modified ie_class.rb status method to following: def status if not @ie.StatusBar @ie.StatusBar = true end return @ie.StatusText end This resolved ole error wich was mentioned here http://www.mail-archive.com/wtr-development[at]rubyforge.org/msg00918.html Raino -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Tue Jun 21 11:13:18 2011 From: jarmo.p at gmail.com (Jarmo) Date: Tue, 21 Jun 2011 18:13:18 +0300 Subject: [Wtr-development] watir ie9 statusbar text In-Reply-To: <002101cc3018$a36b2c40$ea4184c0$@hot.ee> References: <002101cc3018$a36b2c40$ea4184c0$@hot.ee> Message-ID: This change makes the @ie.StatusText to return statusbar text correctly on IE9? Jarmo On Tue, Jun 21, 2011 at 4:39 PM, Rain Kolk wrote: > Hi, > > > > There seems to be bug with IE9 statusbar text. > > > > I modified ie_class.rb status method to following: > > def status > > ??????????????? ??? if not @ie.StatusBar > > ?????????????????????????????? @ie.StatusBar = true > > ??????????????? ??? end > > ????? return @ie.StatusText > > ??? end > > > > This resolved ole error wich was mentioned here > http://www.mail-archive.com/wtr-development[at]rubyforge.org/msg00918.html > > > > Raino > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From colinsdaddy at gmail.com Tue Jun 21 12:09:21 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Tue, 21 Jun 2011 11:09:21 -0500 Subject: [Wtr-development] watir ie9 statusbar text In-Reply-To: References: <002101cc3018$a36b2c40$ea4184c0$@hot.ee> Message-ID: I don't think that is going to work. The problem here is that if you run the code above, while won't throw an exception, you also won't really get the browser text. When you enable the status bar, it *always* resets the status to '' on IE9 irb(main):093:0> ie.ie.StatusBar=false => false irb(main):094:0> ie.ie.statusText = 'test' => "test" irb(main):095:0> ie.ie.StatusBar=true => true irb(main):096:0> ie.ie.statusText => "" I think the right thing to do is if people are relying on the status bar, they just need to know to enable it. If they do this, then when the status bar text is set, IE will retain the value. def status if @ie.StatusBar @ie.statusText else raise RuntimeError, "The status bar in IE is currently disabled. Please enable it if you would like to use this feature" end end Does this seem like a reasonable approach? Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From xgas at hot.ee Wed Jun 22 03:38:56 2011 From: xgas at hot.ee (Rain Kolk) Date: Wed, 22 Jun 2011 10:38:56 +0300 Subject: [Wtr-development] watir ie9 statusbar text Message-ID: <003b01cc30af$7160c880$54225980$@hot.ee> Hi, There seems to be bug with IE9 statusbar text. I modified ie_class.rb status method to following: def status if not @ie.StatusBar @ie.StatusBar = true end return @ie.StatusText end This resolved ole error wich was mentioned here http://www.mail-archive.com/wtr-development[at]rubyforge.org/msg00918.html Raino -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Fri Jun 24 07:39:22 2011 From: jarmo.p at gmail.com (Jarmo) Date: Fri, 24 Jun 2011 14:39:22 +0300 Subject: [Wtr-development] watir ie9 statusbar text In-Reply-To: References: <002101cc3018$a36b2c40$ea4184c0$@hot.ee> Message-ID: If you can enable/disable statusbar in IE9 then this seems to be a reasonable approach :) On Tue, Jun 21, 2011 at 7:09 PM, Hugh McGowan wrote: > I don't think that is going to work. > > The problem here is that if you run the code above, while won't throw an > exception, you also won't really get the browser text. When you enable the > status bar, it *always* resets the status to '' on IE9 > > irb(main):093:0> ie.ie.StatusBar=false > => false > irb(main):094:0> ie.ie.statusText = 'test' > => "test" > irb(main):095:0> ie.ie.StatusBar=true > => true > irb(main):096:0> ie.ie.statusText > => "" > > I think the right thing to do is if people are relying on the status bar, > they just need to know to enable it. If they do this, then when the status > bar text is set, IE will retain the value. > > def status > ??? if @ie.StatusBar > ??????? @ie.statusText > ??? else > ??????? raise RuntimeError, "The status bar in IE is currently disabled. > Please enable it if you would like to use this feature" > ??? end > end > > Does this seem like a reasonable approach? > > Hugh > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From colinsdaddy at gmail.com Sun Jun 26 00:49:05 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Sat, 25 Jun 2011 23:49:05 -0500 Subject: [Wtr-development] Watir 1.9.1 RC1 Message-ID: Hi all, I've made a release candidate for Watir 1.9.1. This release includes *only* IE9-specific changes: * fix event handling for keyboard and mouse events in fire_event and add missing mouse events * add !doctype to all html tags in the test cases. This makes IE8 use IE8 Document Standards and IE9 use IE9 Document Standards. A lot of bugs were then exposed by this change (and detected the xpath issue we missed, reported on Watir General) * xpath matching on text values was broken cases because IE9 adds lots of additional #text nodes. IE9 also changed ole_object.toString (silently failed). Further, toString was not returning the actual text in IE9 so in that case we're now using ole_object.wholeText * fixed forms from blowing up if the name was not an attribute of the html * non-control elements stopped displaying the name in ole_object.name so using the getAttribute('name') instead. Made this the case for all elements to avoid putting an ugly corner case in locator.rb * fast location using getElementById works differently in IE9 so added check to make sure the type of the object was what we expected or we fall back to standard locators I think things are pretty good now - I ran tests on IE8 and IE9 in Win7 and they all look great and will use the RC for a day or two before releasing. I don't anticipate any other changes at this time, so hopefully this will be the only RC this time :). Thanks! Hugh IE9, why do you silently fail? why? -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Sun Jun 26 11:16:44 2011 From: watirjira at gmail.com (Venugopal S Shenoy (JIRA)) Date: Sun, 26 Jun 2011 10:16:44 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-481) Not able to open new IE after it is closed. In-Reply-To: <31083542.38.1307636456038.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <22522700.22.1309101404834.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20192#action_20192 ] Venugopal S Shenoy commented on WTR-481: ---------------------------------------- Please fix this bug on priority. All the tests, involving close function when run with version beyond Watir 1.6.7 is raising NoMethodError. Hence right now, I am using Watir 1.6.7 > Not able to open new IE after it is closed. > ------------------------------------------- > > Key: WTR-481 > URL: http://jira.openqa.org/browse/WTR-481 > Project: Watir > Issue Type: Bug > Components: Unit Tests > Affects Versions: Soon > Environment: Windows XP running IE7 > Reporter: bhavesh > Priority: Critical > Fix For: Soon > > > Hi, > I have to close IE and open new IE again in every testcase. > I written an routine like this : > def setupnew(current_component="") > $ie.close if $ie > sleep(10) > $ie = Watir::IE.new() > sleep(10) > case current_component > when "WEB_ADMIN" > $ie.goto($adminLink) > when "WEB_REPORT" > $ie.goto($reportLink) > when "WEB_SEARCH" > $ie.goto($searchLink) > else > #puts "Setup case does not match" > end > end > This works well in Ruby 1.8 > Recently i upgrade to Ruby 1.9.2 and this routine start failing. > It closes the IE if it is open but then not opening the new IE it > just came out of script throwing error. > Error coming out as : > TestCaseNum: I18N_0001 > Description: Add AD Authentication from Webadmin, for FIGS. > E > Finished in 0.468750 seconds. > 1) Error: > test_0001(TC_I18N): > NoMethodError: unknown property or method: `name' > HRESULT error code:0x800706ba > The RPC server is unavailable. > C:/Ruby192/lib/ruby/gems/1.9.1/gems/watir-1.8.1/lib/watir/ie- > class.rb:319:in > `method_missing' > C:/Ruby192/lib/ruby/gems/1.9.1/gems/watir-1.8.1/lib/watir/ie- > class.rb:319:in > `exists?' > C:/Ruby192/lib/ruby/gems/1.9.1/gems/watir-1.8.1/lib/watir/ie- > class.rb:406:in > `close' > C:/IE_AUTOMATION/kazeon/qa/watir-v1_4-TIP/KazModules/I18N/ > I18N_Regression.rb > :47:in `setupnew' > C:/IE_AUTOMATION/kazeon/qa/watir-v1_4-TIP/KazModules/I18N/ > I18N_Regression.rb > :102:in `test_0001' > got the problem but not the solution. > In watir 1.6.7 which i use previously, code for ie.close is like > this : > #C:\ruby\lib\ruby\gems\1.8\gems\watir-1.6.7\lib\watir > # 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 > In watir 1.8.1 which i use now, code for ie.close is like this : > C:\Ruby192\lib\ruby\gems\1.9.1\gems\watir-1.8.1\lib\watir > # Closes the Browser > def close > return unless exists? > @ie.stop > wait rescue nil > chwnd = @ie.hwnd.to_i > @ie.quit > t = Time.now > while exists? > # just in case to avoid possible endless loop if failing to > close some > # window or tab > break if Time.now - t > 10 > sleep 0.3 > end > end > There is an change in code in 1.8.1. > If i replace the piece of code for ie.close of version 1.6.7 in 1.8.1 > file, the same routine starts working fine. > So what needs to be done now to have this working with 1.8.1 code? > Bhavesh -- 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 charley.baker at gmail.com Sun Jun 26 15:58:06 2011 From: charley.baker at gmail.com (Charley Baker) Date: Sun, 26 Jun 2011 13:58:06 -0600 Subject: [Wtr-development] Watir 1.9.1 RC1 In-Reply-To: References: Message-ID: This is cool stuff. Thanks for taking the lead on the IE9 changes and bumping some of your other changes from Convio out to see the light of day. :) I've been consumed with learning Rails after 6 years of straight Ruby and doing business development as part of my new job. I'd suggest you're definitely part of the core team and should be added to the team pages as a core committer. Anyone agree? Cheers, Charley On Sat, Jun 25, 2011 at 10:49 PM, Hugh McGowan wrote: > Hi all, > > I've made a release candidate for Watir 1.9.1. This release includes *only* > IE9-specific changes: > > * fix event handling for keyboard and mouse events in fire_event and add > missing mouse events > * add !doctype to all html tags in the test cases. This makes IE8 use IE8 > Document Standards and IE9 use IE9 Document Standards. A lot of bugs were > then exposed by this change (and detected the xpath issue we missed, > reported on Watir General) > * xpath matching on text values was broken cases because IE9 adds lots of > additional #text nodes. IE9 also changed ole_object.toString (silently > failed). Further, toString was not returning the actual text in IE9 so in > that case we're now using ole_object.wholeText > * fixed forms from blowing up if the name was not an attribute of the html > * non-control elements stopped displaying the name in ole_object.name so > using the getAttribute('name') instead. Made this the case for all elements > to avoid putting an ugly corner case in locator.rb > * fast location using getElementById works differently in IE9 so added > check to make sure the type of the object was what we expected or we fall > back to standard locators > > I think things are pretty good now - I ran tests on IE8 and IE9 in Win7 and > they all look great and will use the RC for a day or two before releasing. I > don't anticipate any other changes at this time, so hopefully this will be > the only RC this time :). > > Thanks! > Hugh > > IE9, why do you silently fail? why? > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Sun Jun 26 18:26:39 2011 From: alister.scott at gmail.com (Alister Scott) Date: Mon, 27 Jun 2011 08:26:39 +1000 Subject: [Wtr-development] Watir 1.9.1 RC1 In-Reply-To: References: Message-ID: <5004576089454961317@unknownmsgid> Agree. Alister Scott Brisbane, Australia On 27/06/2011, at 6:02 AM, Charley Baker wrote: This is cool stuff. Thanks for taking the lead on the IE9 changes and bumping some of your other changes from Convio out to see the light of day. :) I've been consumed with learning Rails after 6 years of straight Ruby and doing business development as part of my new job. I'd suggest you're definitely part of the core team and should be added to the team pages as a core committer. Anyone agree? Cheers, Charley On Sat, Jun 25, 2011 at 10:49 PM, Hugh McGowan wrote: > Hi all, > > I've made a release candidate for Watir 1.9.1. This release includes *only* > IE9-specific changes: > > * fix event handling for keyboard and mouse events in fire_event and add > missing mouse events > * add !doctype to all html tags in the test cases. This makes IE8 use IE8 > Document Standards and IE9 use IE9 Document Standards. A lot of bugs were > then exposed by this change (and detected the xpath issue we missed, > reported on Watir General) > * xpath matching on text values was broken cases because IE9 adds lots of > additional #text nodes. IE9 also changed ole_object.toString (silently > failed). Further, toString was not returning the actual text in IE9 so in > that case we're now using ole_object.wholeText > * fixed forms from blowing up if the name was not an attribute of the html > * non-control elements stopped displaying the name in ole_object.name so > using the getAttribute('name') instead. Made this the case for all elements > to avoid putting an ugly corner case in locator.rb > * fast location using getElementById works differently in IE9 so added > check to make sure the type of the object was what we expected or we fall > back to standard locators > > I think things are pretty good now - I ran tests on IE8 and IE9 in Win7 and > they all look great and will use the RC for a day or two before releasing. I > don't anticipate any other changes at this time, so hopefully this will be > the only RC this time :). > > Thanks! > Hugh > > IE9, why do you silently fail? why? > > _______________________________________________ > 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: From zeljko.filipin at wa-research.ch Mon Jun 27 04:03:10 2011 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Mon, 27 Jun 2011 10:03:10 +0200 Subject: [Wtr-development] Watir 1.9.1 RC1 In-Reply-To: References: Message-ID: On Sun, Jun 26, 2011 at 9:58 PM, Charley Baker wrote: > I'd suggest you're definitely part of the core team and should be added to the team pages as a core committer. +1 I will wait a few days so people get to vote and add Hugh to core developers (if nobody complains): http://watir.com/team/ ?eljko -- watir.com - community manager watir.com/book - author watirpodcast.com - host -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Mon Jun 27 04:29:31 2011 From: jarmo.p at gmail.com (Jarmo) Date: Mon, 27 Jun 2011 11:29:31 +0300 Subject: [Wtr-development] Watir 1.9.1 RC1 In-Reply-To: References: <5004576089454961317@unknownmsgid> Message-ID: He does everything a core developer should do. +1 from me:) On Jun 27, 2011 1:29 AM, "Alister Scott" wrote: > Agree. > > Alister Scott > Brisbane, Australia > > On 27/06/2011, at 6:02 AM, Charley Baker wrote: > > This is cool stuff. Thanks for taking the lead on the IE9 changes and > bumping some of your other changes from Convio out to see the light of day. > :) I've been consumed with learning Rails after 6 years of straight Ruby and > doing business development as part of my new job. I'd suggest you're > definitely part of the core team and should be added to the team pages as a > core committer. > > Anyone agree? > > Cheers, > > Charley > > On Sat, Jun 25, 2011 at 10:49 PM, Hugh McGowan wrote: > >> Hi all, >> >> I've made a release candidate for Watir 1.9.1. This release includes *only* >> IE9-specific changes: >> >> * fix event handling for keyboard and mouse events in fire_event and add >> missing mouse events >> * add !doctype to all html tags in the test cases. This makes IE8 use IE8 >> Document Standards and IE9 use IE9 Document Standards. A lot of bugs were >> then exposed by this change (and detected the xpath issue we missed, >> reported on Watir General) >> * xpath matching on text values was broken cases because IE9 adds lots of >> additional #text nodes. IE9 also changed ole_object.toString (silently >> failed). Further, toString was not returning the actual text in IE9 so in >> that case we're now using ole_object.wholeText >> * fixed forms from blowing up if the name was not an attribute of the html >> * non-control elements stopped displaying the name in ole_object.name so >> using the getAttribute('name') instead. Made this the case for all elements >> to avoid putting an ugly corner case in locator.rb >> * fast location using getElementById works differently in IE9 so added >> check to make sure the type of the object was what we expected or we fall >> back to standard locators >> >> I think things are pretty good now - I ran tests on IE8 and IE9 in Win7 and >> they all look great and will use the RC for a day or two before releasing. I >> don't anticipate any other changes at this time, so hopefully this will be >> the only RC this time :). >> >> Thanks! >> Hugh >> >> IE9, why do you silently fail? why? >> >> _______________________________________________ >> 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: From bret at pettichord.com Mon Jun 27 17:02:28 2011 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 27 Jun 2011 16:02:28 -0500 Subject: [Wtr-development] Watir 1.9.1 RC1 In-Reply-To: References: <5004576089454961317@unknownmsgid> Message-ID: +1 On Mon, Jun 27, 2011 at 3:29 AM, Jarmo wrote: > He does everything a core developer should do. +1 from me:) > > On Jun 27, 2011 1:29 AM, "Alister Scott" wrote: > > Agree. > > > > Alister Scott > > Brisbane, Australia > > > > On 27/06/2011, at 6:02 AM, Charley Baker > wrote: > > > > This is cool stuff. Thanks for taking the lead on the IE9 changes and > > bumping some of your other changes from Convio out to see the light of > day. > > :) I've been consumed with learning Rails after 6 years of straight Ruby > and > > doing business development as part of my new job. I'd suggest you're > > definitely part of the core team and should be added to the team pages as > a > > core committer. > > > > Anyone agree? > > > > Cheers, > > > > Charley > > > > On Sat, Jun 25, 2011 at 10:49 PM, Hugh McGowan >wrote: > > > >> Hi all, > >> > >> I've made a release candidate for Watir 1.9.1. This release includes > *only* > >> IE9-specific changes: > >> > >> * fix event handling for keyboard and mouse events in fire_event and add > >> missing mouse events > >> * add !doctype to all html tags in the test cases. This makes IE8 use > IE8 > >> Document Standards and IE9 use IE9 Document Standards. A lot of bugs > were > >> then exposed by this change (and detected the xpath issue we missed, > >> reported on Watir General) > >> * xpath matching on text values was broken cases because IE9 adds lots > of > >> additional #text nodes. IE9 also changed ole_object.toString (silently > >> failed). Further, toString was not returning the actual text in IE9 so > in > >> that case we're now using ole_object.wholeText > >> * fixed forms from blowing up if the name was not an attribute of the > html > >> * non-control elements stopped displaying the name in ole_object.nameso > >> using the getAttribute('name') instead. Made this the case for all > elements > >> to avoid putting an ugly corner case in locator.rb > >> * fast location using getElementById works differently in IE9 so added > >> check to make sure the type of the object was what we expected or we > fall > >> back to standard locators > >> > >> I think things are pretty good now - I ran tests on IE8 and IE9 in Win7 > and > >> they all look great and will use the RC for a day or two before > releasing. I > >> don't anticipate any other changes at this time, so hopefully this will > be > >> the only RC this time :). > >> > >> Thanks! > >> Hugh > >> > >> IE9, why do you silently fail? why? > >> > >> _______________________________________________ > >> 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 Director, Watir Project, www.watir.com Blog, www.testingwithvision.com Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Tue Jun 28 18:30:03 2011 From: bret at pettichord.com (Bret Pettichord) Date: Tue, 28 Jun 2011 17:30:03 -0500 Subject: [Wtr-development] Announcing Watir 1.9 Message-ID: I just noticed that we haven't posted an announcement of the new release to our website. Separately, I have asked Hugh to provide us with a photo for the website team page. Bret -- Bret Pettichord Director, Watir Project, www.watir.com Blog, www.testingwithvision.com Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinsdaddy at gmail.com Tue Jun 28 19:47:30 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Tue, 28 Jun 2011 18:47:30 -0500 Subject: [Wtr-development] Announcing Watir 1.9 In-Reply-To: References: Message-ID: Hi all, I'm excited about joining the team! Here's a link to my photo: http://www.gravatar.com/avatar/d97c4dfb28cf5771a21d8064718f745b.png Thanks! Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From charley.baker at gmail.com Tue Jun 28 20:07:27 2011 From: charley.baker at gmail.com (charley) Date: Tue, 28 Jun 2011 19:07:27 -0500 Subject: [Wtr-development] Announcing Watir 1.9 In-Reply-To: References: Message-ID: <46608F77-7F78-4793-BED9-1F4D8AED0169@gmail.com> Well deserved! -Charley On Jun 28, 2011, at 6:47 PM, Hugh McGowan wrote: > Hi all, > > I'm excited about joining the team! Here's a link to my photo: > > http://www.gravatar.com/avatar/d97c4dfb28cf5771a21d8064718f745b.png > > > Thanks! > Hugh > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Wed Jun 29 14:28:46 2011 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 29 Jun 2011 13:28:46 -0500 Subject: [Wtr-development] Announcing Watir 1.9 In-Reply-To: References: Message-ID: I have added Hugh to the team page. http://watir.com/team/ On Tue, Jun 28, 2011 at 6:47 PM, Hugh McGowan wrote: > Hi all, > > I'm excited about joining the team! Here's a link to my photo: > > http://www.gravatar.com/avatar/d97c4dfb28cf5771a21d8064718f745b.png > > > Thanks! > Hugh > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Director, Watir Project, www.watir.com Blog, www.testingwithvision.com Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Thu Jun 30 04:53:00 2011 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 30 Jun 2011 10:53:00 +0200 Subject: [Wtr-development] Announcing Watir 1.9 In-Reply-To: References: Message-ID: On Wed, Jun 29, 2011 at 8:28 PM, Bret Pettichord wrote: > I have added Hugh to the team page. > http://watir.com/team/ Thanks! :) ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinsdaddy at gmail.com Thu Jun 30 16:29:08 2011 From: colinsdaddy at gmail.com (Hugh McGowan) Date: Thu, 30 Jun 2011 15:29:08 -0500 Subject: [Wtr-development] Watir 1.9.1 released Message-ID: Hi all, I've pushed Watir 1.9.1 containing fixes for IE9. The only remaining IE9 issue is that file fields are not working in IE9. I've fixed the unit test so that it fails appropriately. Seems that there's something happening that's different when you click the 'Browse...' button with automation vs clicking it manually. So for example: manually click Browse... regardless of automating or manually completing the file upload, everything works click Browse... using watir doesn't matter if it's automated or manual after this. Symptoms are: * if you manually click the submit button, it resets the file_field *without posting the form* * if you use watir to click the submit button, it posts the form but the file_field value is empty Of course if you put the document mode back to IE8 everything works swimmingly. It seems that something in the way the Browser.. button is clicked is causing issues. I've tried firing events to see if there was something there we're missing but no luck. If anyone has any thoughts on things to try, I'd love to hear from you. Thanks! Hugh -------------- next part -------------- An HTML attachment was scrubbed... URL: