From watirjira at gmail.com Wed Sep 1 03:14:31 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Wed, 1 Sep 2010 02:14:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-453) firewatir dones work with cygwin because it can locate firefox executable In-Reply-To: <21820430.835.1283280570684.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <26776603.840.1283325271305.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zeljko updated WTR-453: ----------------------- Component/s: (was: Documentation) FireWatir > firewatir dones work with cygwin because it can locate firefox executable > ------------------------------------------------------------------------- > > Key: WTR-453 > URL: http://jira.openqa.org/browse/WTR-453 > Project: Watir > Issue Type: Bug > Components: FireWatir > Affects Versions: 1.6.5 > Environment: $ gem search watir > *** LOCAL GEMS *** > commonwatir (1.6.5) > firewatir (1.6.5) > watir (1.6.5) > $ gem env > RubyGems Environment: > - RUBYGEMS VERSION: 1.3.7 > - RUBY VERSION: 1.8.7 (2008-08-11 patchlevel 72) [i386-cygwin] > - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.8 > - RUBY EXECUTABLE: /usr/bin/ruby.exe > - EXECUTABLE DIRECTORY: /usr/bin > - RUBYGEMS PLATFORMS: > - ruby > - x86-cygwin > - GEM PATHS: > - /usr/lib/ruby/gems/1.8 > - /home/Alexis/.gem/ruby/1.8 > - GEM CONFIGURATION: > - :update_sources => true > - :verbose => true > - :benchmark => false > - :backtrace => false > - :bulk_threshold => 1000 > - REMOTE SOURCES: > - http://rubygems.org/ > $ > Reporter: fourchette > > if you try to run the example provided on watir example page using firefox and cygwin it just does not work > #!/usr/bin/ruby > # Here we see a very simple WATIR script to drive to google and validate a page > require 'rubygems' > require 'watir' # use watir gem > test_site = 'http://www.google.com' # set a variable > Watir::Browser.default = 'firefox' > b = Watir::Browser.new # open the IE browser > b.goto(test_site) # load url, go to site > b.text_field(:name, "q").set("pickaxe") # load text "pickaxe" into search field named "q" > b.button(:name, "btnG").click # "btnG" is the name of the Search button, click it > if b.text.include?("Programming Ruby") > puts "Test Passed. Found the test string: 'Programming Ruby'." > else > puts "Test Failed! Could not find: 'Programming Ruby'" > end > ____________ > $ ruby watir_test.rb > /usr/lib/ruby/gems/1.8/gems/firewatir-1.6.5/lib/firewatir/firefox.rb:1010:in `current_os': undefined local variable or method `plateform' for # (NameError) > from /usr/lib/ruby/gems/1.8/gems/firewatir-1.6.5/lib/firewatir/firefox.rb:124:in `initialize' > from /usr/lib/ruby/gems/1.8/gems/commonwatir-1.6.5/lib/watir/browser.rb:65:in `new' > from /usr/lib/ruby/gems/1.8/gems/commonwatir-1.6.5/lib/watir/browser.rb:65:in `new' > from watir_test.rb:8 > $ > the reason for that is because around line 1000 in /usr/lib/ruby/gems/1.8/gems/firewatir-1.6.5/lib/firewatir/firefox.rb > the variable platform == 'i386-cygwin', so it can't get caught by select/case right below. > all you need to change is > at firefox.rb:1000 > from > when /mingw32|mswin|windows/i > to > when /mingw32|mswin|windows|cygwin/i > and that's it. nothing else. > $ ruby watir_test.rb > sh: C:Program: command not found > Test Failed! Could not find: 'Programming Ruby' > $ > (actually the example fails because i have google in french, but it does work > i dont know what the > sh: C:Program: command not found > is doing in the output (and no the -w is not active, it vomits ugly things otherwise :)) > it would be great to push this change in the next firewatir release so that it actually supports cywin -- 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 Sep 1 03:16:30 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Wed, 1 Sep 2010 02:16:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-282) Watir doesn't work on Cygwin [patch] Message-ID: <31265601.842.1283325390744.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zeljko updated WTR-282: ----------------------- Component/s: (was: Modal Web Dialog) Other > Watir doesn't work on Cygwin [patch] > ------------------------------------ > > Key: WTR-282 > URL: http://jira.openqa.org/browse/WTR-282 > Project: Watir > Issue Type: Bug > Components: Modal Web Dialog > Affects Versions: 1.6.2 > Environment: WinXP / Cygwin > Reporter: andyl > Priority: Blocker > Fix For: Soon > > > On Cygwin, I ran into two separate problems that prevented Watir 1.6.2 from working. > First, the 'win32ole.so' file that ships with Watir appears to be incompatible with the version that is installed with my copy of Cygwin- > ruby. (see http://pastie.org/374756) > An error message 'bad file permissions' was generated when trying to run 'x = Watir::IE.new' from within IRB. > My workaround was to copy the 'ruby' version of win32ole.so into the 'watir' directories. (see http://pastie.org/374865) > Once this was done, another error occured - relating to modal dialogs. (see http://pastie.org/374865) > This was fixed by commenting out 2 lines in the Watir source code: > File - modal_dialog.rb Line - 65 GetUnknown.call ... > File - win32.rb Line - 6 GetUnknown = Win32API.new(... > Once these lines were commented out, watir worked. > Ideas for fixes: > - Fix the modal dialog issue with conditional execution: > GetUnknown.call (...) unless RUBY_PLATFORM == 'i386-cygwin' > GetUnknown=Win32APUI.new(... unless RUBY_PLATFORM =='i386-cygwin' > > - Fix the win32ole issue by not bundling this file in the gem (Brett thinks maybe it is not needed??) > - Cygwin support: run regression tests on cygwin!! -- 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 Sep 1 03:16:30 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Wed, 1 Sep 2010 02:16:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-282) Watir doesn't work on Cygwin [patch] Message-ID: <7001723.844.1283325390821.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zeljko updated WTR-282: ----------------------- Component/s: (was: Other) Modal Web Dialog > Watir doesn't work on Cygwin [patch] > ------------------------------------ > > Key: WTR-282 > URL: http://jira.openqa.org/browse/WTR-282 > Project: Watir > Issue Type: Bug > Components: Modal Web Dialog > Affects Versions: 1.6.2 > Environment: WinXP / Cygwin > Reporter: andyl > Priority: Blocker > Fix For: Soon > > > On Cygwin, I ran into two separate problems that prevented Watir 1.6.2 from working. > First, the 'win32ole.so' file that ships with Watir appears to be incompatible with the version that is installed with my copy of Cygwin- > ruby. (see http://pastie.org/374756) > An error message 'bad file permissions' was generated when trying to run 'x = Watir::IE.new' from within IRB. > My workaround was to copy the 'ruby' version of win32ole.so into the 'watir' directories. (see http://pastie.org/374865) > Once this was done, another error occured - relating to modal dialogs. (see http://pastie.org/374865) > This was fixed by commenting out 2 lines in the Watir source code: > File - modal_dialog.rb Line - 65 GetUnknown.call ... > File - win32.rb Line - 6 GetUnknown = Win32API.new(... > Once these lines were commented out, watir worked. > Ideas for fixes: > - Fix the modal dialog issue with conditional execution: > GetUnknown.call (...) unless RUBY_PLATFORM == 'i386-cygwin' > GetUnknown=Win32APUI.new(... unless RUBY_PLATFORM =='i386-cygwin' > > - Fix the win32ole issue by not bundling this file in the gem (Brett thinks maybe it is not needed??) > - Cygwin support: run regression tests on cygwin!! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From notethan at gmail.com Wed Sep 1 11:35:44 2010 From: notethan at gmail.com (Ethan) Date: Wed, 1 Sep 2010 11:35:44 -0400 Subject: [Wtr-development] new window automation library: WinWindow Message-ID: I've released a gem for a ruby library that I hope people will find useful, and I believe will be of interest to those using watir. The library is called WinWindow, and its aim is to represent a window (such as an IE window, or a javascript popup), and expose windows API methods in an object-oriented, ruby-like way. The project's site is at http://winwindow.vapir.org/ It was borne of frustration with winClicker and AutoIt, and I wrote it to replace, improve, and expand on functionality that watir currently uses those libraries for. Namely, interaction with modal dialogs (getting text, entering text, clicking buttons, closing); maximizing/focusing windows; dealing with File Upload dialogs. It also does screen captures, which I implemented because the win32screenshot gem was broken, although Jarmo has since fixed that gem. Some sample code showing use with watir, to close a javascript popup, follows: $ irb -r watir >> require 'winwindow' => true # launch a new browser >> ie=Watir::IE.new => # # create a WinWindow representing the browser >> w=WinWindow.new(ie.hwnd) => # # go to a site that'll give us a javascript popup >> ie.goto "http://www.mediacollege.com/internet/javascript/basic/alert.html " => 2.953125 # click the button to create the popup >> ie.button(:value, /alert/).click_no_wait => "" # see if the popup is on the window >> w.enabled_popup => # # click the "OK" button on the popup. the 'try_for' part tells it how many # seconds to try, because sending click messages through the windows API is # not very reliable and just doing it once tends to fail. >> w.enabled_popup.click_child_button_try_for!('OK', 4) => true # popup is gone. tl;dr version: to click on a button on ie's popup with text button_text (trying for n seconds), you can use WinWindow.new(ie.hwnd).enabled_popup.click_child_button_try_for!(button_text, n) I hope you'll give it a try and let me know what you think. -Ethan -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Wed Sep 1 16:09:31 2010 From: watirjira at gmail.com (Cliff White (JIRA)) Date: Wed, 1 Sep 2010 15:09:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Created: (WTR-454) Remove dependency on activesupport Message-ID: <33472924.847.1283371771356.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Remove dependency on activesupport ---------------------------------- Key: WTR-454 URL: http://jira.openqa.org/browse/WTR-454 Project: Watir Issue Type: Bug Components: FireWatir Affects Versions: 1.6.5 Environment: XP SP3 Reporter: Cliff White Priority: Major Per Charley's reply to http://stackoverflow.com/questions/3614865/firewatir-firewatir-returns-undefined-method-error-in-eclipse/3620642#3620642 "This appears to be a problem with the latest version of ActiveRecord - 3.0.0. I'd thought that we removed that as a dependency, apparently not. Please file a ticket in Jira and I'll take a look at it. " Ticket filed. Thanks! Cliff -- 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 Sep 2 04:11:31 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Thu, 2 Sep 2010 03:11:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-282) Watir doesn't work on Cygwin [patch] Message-ID: <15456989.858.1283415091365.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19840#action_19840 ] Jarmo Pertman commented on WTR-282: ----------------------------------- I have a completely different question which is not directly related with this issue - why are you even using Cygwin with Ruby and Firewatir? Just out of curiousity what's the real life usecase. > Watir doesn't work on Cygwin [patch] > ------------------------------------ > > Key: WTR-282 > URL: http://jira.openqa.org/browse/WTR-282 > Project: Watir > Issue Type: Bug > Components: Modal Web Dialog > Affects Versions: 1.6.2 > Environment: WinXP / Cygwin > Reporter: andyl > Priority: Blocker > Fix For: Soon > > > On Cygwin, I ran into two separate problems that prevented Watir 1.6.2 from working. > First, the 'win32ole.so' file that ships with Watir appears to be incompatible with the version that is installed with my copy of Cygwin- > ruby. (see http://pastie.org/374756) > An error message 'bad file permissions' was generated when trying to run 'x = Watir::IE.new' from within IRB. > My workaround was to copy the 'ruby' version of win32ole.so into the 'watir' directories. (see http://pastie.org/374865) > Once this was done, another error occured - relating to modal dialogs. (see http://pastie.org/374865) > This was fixed by commenting out 2 lines in the Watir source code: > File - modal_dialog.rb Line - 65 GetUnknown.call ... > File - win32.rb Line - 6 GetUnknown = Win32API.new(... > Once these lines were commented out, watir worked. > Ideas for fixes: > - Fix the modal dialog issue with conditional execution: > GetUnknown.call (...) unless RUBY_PLATFORM == 'i386-cygwin' > GetUnknown=Win32APUI.new(... unless RUBY_PLATFORM =='i386-cygwin' > > - Fix the win32ole issue by not bundling this file in the gem (Brett thinks maybe it is not needed??) > - Cygwin support: run regression tests on cygwin!! -- 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 Sep 2 04:51:31 2010 From: watirjira at gmail.com (fourchette (JIRA)) Date: Thu, 2 Sep 2010 03:51:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-282) Watir doesn't work on Cygwin [patch] Message-ID: <1469458.860.1283417491401.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19841#action_19841 ] fourchette commented on WTR-282: -------------------------------- simple : i am coerced into using windows. but i do like the wealth of the gnu environment, for starters using bash instead of cmd is a real productivity gain. besides the whole cygwin install/update model is just great. So well it is just convenient to install and use ruby from the cygwin install instead of the ruby one click installer. that was for the first point. second point is i am evaluating watir and trying to figure out if it is really a benefit compared to selenium for instance (so far i am not convinced but willing to really investigate the issue). so i need to see the same testing script working on both ie and firefox. following andy comments on http://jira.openqa.org/browse/WTR-453 i have been able to get watir to work with IE too. that was the second point last but not last, i faced plain not-working-firewatir going through the route of the watir installation guide http://watir.com/installation/#win so i opened up a discution on stackoverflow there: http://stackoverflow.com/questions/3602466/firefox-and-watir-wouldnt-work-on-windows-due-to-a-singularize-method-not-found/ that was the last point. i think having watir actually support cygwin seems really easy honnestly (about 3 lines to update, only 10 caracters for firewatir), so it is worth doing i'd say. > Watir doesn't work on Cygwin [patch] > ------------------------------------ > > Key: WTR-282 > URL: http://jira.openqa.org/browse/WTR-282 > Project: Watir > Issue Type: Bug > Components: Modal Web Dialog > Affects Versions: 1.6.2 > Environment: WinXP / Cygwin > Reporter: andyl > Priority: Blocker > Fix For: Soon > > > On Cygwin, I ran into two separate problems that prevented Watir 1.6.2 from working. > First, the 'win32ole.so' file that ships with Watir appears to be incompatible with the version that is installed with my copy of Cygwin- > ruby. (see http://pastie.org/374756) > An error message 'bad file permissions' was generated when trying to run 'x = Watir::IE.new' from within IRB. > My workaround was to copy the 'ruby' version of win32ole.so into the 'watir' directories. (see http://pastie.org/374865) > Once this was done, another error occured - relating to modal dialogs. (see http://pastie.org/374865) > This was fixed by commenting out 2 lines in the Watir source code: > File - modal_dialog.rb Line - 65 GetUnknown.call ... > File - win32.rb Line - 6 GetUnknown = Win32API.new(... > Once these lines were commented out, watir worked. > Ideas for fixes: > - Fix the modal dialog issue with conditional execution: > GetUnknown.call (...) unless RUBY_PLATFORM == 'i386-cygwin' > GetUnknown=Win32APUI.new(... unless RUBY_PLATFORM =='i386-cygwin' > > - Fix the win32ole issue by not bundling this file in the gem (Brett thinks maybe it is not needed??) > - Cygwin support: run regression tests on cygwin!! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From jarmo.p at gmail.com Thu Sep 2 07:13:41 2010 From: jarmo.p at gmail.com (Jarmo) Date: Thu, 2 Sep 2010 14:13:41 +0300 Subject: [Wtr-development] new window automation library: WinWindow In-Reply-To: References: Message-ID: Hi, Ethan! I've taken a glimpse on that thing now. Really, a glimpse. First of all, i think that it's somehow great if something else (ffi in this case) is used instead of AutoIt. On the other hand with AutoIt a lot of problems are already solved. So there are two sides for this approach. It's great that it is nicely documented :) >From a developer's view i don't like that (almost) all the code is in one file with 1365 lines. Why? As a user's view i looked at the API and it seems to be really-really (i mean, really) confuzing. For example, there are methods like #set_foreground! and #really_set_foreground!. Like, what? On another note, i've been lately producing some code using AutoIt since it is nicely integrated with current Watir. I'm being able to produce quite robust and effective results with it. I don't see many benefits of using something else currently (yup, you cannot use everything with AutoIt on locked workstation, but this is also true for FFI and something similar). Anyway, i'm planning to make it as a gem also probably. Sorry, if i'm not able to see the big picture. Keep up the good work! Jarmo On Wed, Sep 1, 2010 at 6:35 PM, Ethan wrote: > I've released a gem for a ruby library that I hope people will find useful, > and I believe will be of interest to those using watir. The library is > called WinWindow, and its aim is to represent a window (such as an IE > window, or a javascript popup), and expose windows API methods in an > object-oriented, ruby-like way. > The project's site is at?http://winwindow.vapir.org/ > It was borne of frustration with winClicker and AutoIt, and I wrote it to > replace, improve, and expand on functionality that watir currently uses > those libraries for. Namely, interaction with modal dialogs (getting text, > entering text, clicking buttons, closing); maximizing/focusing windows; > dealing with File Upload dialogs. It also does screen captures, which I > implemented because the win32screenshot gem was broken, although Jarmo has > since fixed that gem. > Some sample code showing use with watir, to close a javascript popup, > follows: > $ irb -r watir >>> require 'winwindow' > => true > # launch a new browser >>> ie=Watir::IE.new > => # > # create a WinWindow representing the browser >>> w=WinWindow.new(ie.hwnd) > => # @hwnd=395016, @class_name="IEFrame"> > # go to a site that'll give us a javascript popup >>> ie.goto >>> "http://www.mediacollege.com/internet/javascript/basic/alert.html" > => 2.953125 > # click the button to create the popup >>> ie.button(:value, /alert/).click_no_wait > => "" > # see if the popup is on the window >>> w.enabled_popup > => # @class_name="#32770"> > # click the "OK" button on the popup. the 'try_for' part tells it how many > # seconds to try, because sending click messages through the windows API is > # not very reliable and just doing it once tends to fail. >>> w.enabled_popup.click_child_button_try_for!('OK', 4) > => true > # popup is gone. > tl;dr version: to click on a button on ie's popup with text button_text > (trying for n seconds), you can use > WinWindow.new(ie.hwnd).enabled_popup.click_child_button_try_for!(button_text, > n) > > I hope you'll give it a try and let me know what you think. > -Ethan > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From zeljko.filipin at wa-research.ch Thu Sep 2 08:40:17 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 2 Sep 2010 14:40:17 +0200 Subject: [Wtr-development] [wtr-general] new window automation library: WinWindow In-Reply-To: References: Message-ID: On Wed, Sep 1, 2010 at 5:35 PM, Ethan wrote: > its aim is to represent a window (such as an IE window, or a javascript popup), and expose windows API methods in an object-oriented, ruby-like way. Ethan, this is great news. I will take a look at it as soon as I get a few minutes. I think it would be a good idea to completely remove all support for pop-ups from watir and have a separate gem for that. ?eljko -- watir.com - community manager watirpodcast.com - host testingpodcast.com - audio podcasts on software testing. all of them vidipodkast.com - pri?amo o hardveru, softveru i ?asopisu Vidi -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.koops at gmail.com Thu Sep 2 17:35:55 2010 From: tim.koops at gmail.com (Tim Koopmans) Date: Fri, 3 Sep 2010 07:35:55 +1000 Subject: [Wtr-development] [wtr-general] new window automation library: WinWindow In-Reply-To: References: Message-ID: +1 on a separate gem Cheers, Tim On Thu, Sep 2, 2010 at 10:40 PM, ?eljko Filipin wrote: > On Wed, Sep 1, 2010 at 5:35 PM, Ethan wrote: >> its aim is to represent a window (such as an IE window, or a javascript >> popup), and expose windows API methods in an object-oriented, ruby-like way. > > Ethan, > > this is great news. I will take a look at it as soon as I get a few minutes. > > I think it would be a good idea to completely remove all support for pop-ups > from watir and have a separate gem for that. > > ?eljko > -- > watir.com - community manager > watirpodcast.com - host > testingpodcast.com - audio podcasts on software testing. all of them > vidipodkast.com - pri?amo o hardveru, softveru i ?asopisu Vidi > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From watirjira at gmail.com Thu Sep 2 18:23:31 2010 From: watirjira at gmail.com (Bret Pettichord (JIRA)) Date: Thu, 2 Sep 2010 17:23:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-282) Watir doesn't work on Cygwin [patch] Message-ID: <12402982.863.1283466211202.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19842#action_19842 ] Bret Pettichord commented on WTR-282: ------------------------------------- You may be interested to know that I tested early versions of Watir on cygwin regularly. There is some code in our unit tests which is there specifically to support the file syntax of cygwin. > Watir doesn't work on Cygwin [patch] > ------------------------------------ > > Key: WTR-282 > URL: http://jira.openqa.org/browse/WTR-282 > Project: Watir > Issue Type: Bug > Components: Modal Web Dialog > Affects Versions: 1.6.2 > Environment: WinXP / Cygwin > Reporter: andyl > Priority: Blocker > Fix For: Soon > > > On Cygwin, I ran into two separate problems that prevented Watir 1.6.2 from working. > First, the 'win32ole.so' file that ships with Watir appears to be incompatible with the version that is installed with my copy of Cygwin- > ruby. (see http://pastie.org/374756) > An error message 'bad file permissions' was generated when trying to run 'x = Watir::IE.new' from within IRB. > My workaround was to copy the 'ruby' version of win32ole.so into the 'watir' directories. (see http://pastie.org/374865) > Once this was done, another error occured - relating to modal dialogs. (see http://pastie.org/374865) > This was fixed by commenting out 2 lines in the Watir source code: > File - modal_dialog.rb Line - 65 GetUnknown.call ... > File - win32.rb Line - 6 GetUnknown = Win32API.new(... > Once these lines were commented out, watir worked. > Ideas for fixes: > - Fix the modal dialog issue with conditional execution: > GetUnknown.call (...) unless RUBY_PLATFORM == 'i386-cygwin' > GetUnknown=Win32APUI.new(... unless RUBY_PLATFORM =='i386-cygwin' > > - Fix the win32ole issue by not bundling this file in the gem (Brett thinks maybe it is not needed??) > - Cygwin support: run regression tests on cygwin!! -- 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 paul.rogers at shaw.ca Fri Sep 3 17:47:57 2010 From: paul.rogers at shaw.ca (Paul Rogers) Date: Fri, 3 Sep 2010 15:47:57 -0600 Subject: [Wtr-development] Fwd: Watir Advertising In-Reply-To: References: <20100824124730.4r7k61i1usosgcw4@box580.bluehost.com> Message-ID: I havent heard back from them so I guess its not going to happen anyway. On Tue, Aug 31, 2010 at 4:08 PM, ?eljko Filipin wrote: > If you search for "Ads on watir.com" on wtr-development and watir-general > you will find our recent discussion. I remember that Alister really did not > like the idea, nobody else had any complaints, as far as I found in my mail > archive. > > Let me dream for a moment. What if we raised enough money to pay Charley to > work part time (or even full time) on Watir? :) > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From alister.scott at gmail.com Sat Sep 4 06:30:38 2010 From: alister.scott at gmail.com (Alister Scott) Date: Sat, 4 Sep 2010 20:30:38 +1000 Subject: [Wtr-development] Fwd: Watir Advertising In-Reply-To: References: <20100824124730.4r7k61i1usosgcw4@box580.bluehost.com> Message-ID: If people think it's a good idea to move off wordpress.com to ?eljko's self hosted site, then I don't have any issues with it. That way we can run google ads and use the revenue. Cheers, Alister Scott Brisbane, Australia Watir Web Master: http://watir.com Blog: http://watirmelon.com LinkedIn: 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* On Sat, Sep 4, 2010 at 7:47 AM, Paul Rogers wrote: > I havent heard back from them so I guess its not going to happen anyway. > > On Tue, Aug 31, 2010 at 4:08 PM, ?eljko Filipin > wrote: > > If you search for "Ads on watir.com" on wtr-development and > watir-general > > you will find our recent discussion. I remember that Alister really did > not > > like the idea, nobody else had any complaints, as far as I found in my > mail > > archive. > > > > Let me dream for a moment. What if we raised enough money to pay Charley > to > > work part time (or even full time) on Watir? :) > > > > ?eljko > > > > _______________________________________________ > > 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 Sep 6 08:35:58 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Mon, 6 Sep 2010 14:35:58 +0200 Subject: [Wtr-development] Fwd: Watir Advertising In-Reply-To: References: <20100824124730.4r7k61i1usosgcw4@box580.bluehost.com> Message-ID: On Sat, Sep 4, 2010 at 12:30 PM, Alister Scott wrote: > If people think it's a good idea to move off wordpress.com to ?eljko's self hosted site, then I don't have any issues with it. > That way we can run google ads and use the revenue. I will try to move the site to my shared hosting in the next few days or weeks. We can try it there for a week or a month with the ads and see how it goes. We can also move back to wordpress.com if we do not like it there. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Mon Sep 6 08:42:04 2010 From: jarmo.p at gmail.com (Jarmo) Date: Mon, 6 Sep 2010 15:42:04 +0300 Subject: [Wtr-development] Fwd: Watir Advertising In-Reply-To: References: <20100824124730.4r7k61i1usosgcw4@box580.bluehost.com> Message-ID: Just wondering, how many (unique) hits does watir.com get in a month? Jarmo On Mon, Sep 6, 2010 at 3:35 PM, ?eljko Filipin wrote: > On Sat, Sep 4, 2010 at 12:30 PM, Alister Scott > wrote: >> If people think it's a good idea to move off wordpress.com to ?eljko's >> self hosted site, then I don't have any issues with it. >> That way we can run google ads and use the revenue. > > I will try to move the site to my shared hosting in the next few days or > weeks. We can try it there for a week or a month with the ads and see how it > goes. We can also move back to wordpress.com if we do not like it there. > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From zeljko.filipin at wa-research.ch Mon Sep 6 08:48:41 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Mon, 6 Sep 2010 14:48:41 +0200 Subject: [Wtr-development] Fwd: Watir Advertising In-Reply-To: References: <20100824124730.4r7k61i1usosgcw4@box580.bluehost.com> Message-ID: On Mon, Sep 6, 2010 at 2:42 PM, Jarmo wrote: > Just wondering, how many (unique) hits does watir.com get in a month? wordpress.com says (but does not say what the numbers mean, I guess all visits): Months and Years Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov DecTotal 2009 1,0281,4892,0987,49735,45335,83936,785 120,189201040,33440,957 46,70144,518 39,55641,08542,98740,780 6,365 343,283 Average per Day Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov DecOverall 2009 5148682501,1441,1951,187 5892010 1,3011,463 1,5061,4841,2761,3701,3871,315 1,174 1,382?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Mon Sep 6 09:16:06 2010 From: jarmo.p at gmail.com (Jarmo) Date: Mon, 6 Sep 2010 16:16:06 +0300 Subject: [Wtr-development] Fwd: Watir Advertising In-Reply-To: References: <20100824124730.4r7k61i1usosgcw4@box580.bluehost.com> Message-ID: Auch. Pretty nice :) Jarmo On Mon, Sep 6, 2010 at 3:48 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Mon, Sep 6, 2010 at 2:42 PM, Jarmo wrote: > > Just wondering, how many (unique) hits does watir.com get in a month? > > wordpress.com says (but does not say what the numbers mean, I guess all > visits): > > Months and Years > Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov DecTotal 2009 > > > > > 1,0281,4892,0987,49735,45335,83936,785 120,189201040,33440,957 46,701 > 44,51839,55641,08542,98740,780 6,365 > > > 343,283 Average per Day > Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov DecOverall 2009 > > > > > 5148682501,1441,1951,187 5892010 1,3011,463 1,5061,4841,2761,3701,3871,315 > 1,174 > > > 1,382?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: From jarmo.p at gmail.com Mon Sep 6 09:16:51 2010 From: jarmo.p at gmail.com (Jarmo) Date: Mon, 6 Sep 2010 16:16:51 +0300 Subject: [Wtr-development] Fwd: Watir Advertising In-Reply-To: References: <20100824124730.4r7k61i1usosgcw4@box580.bluehost.com> Message-ID: Forgot to ask, no analytics installed? Maybe should do it, just for the curiosity. Jarmo On Mon, Sep 6, 2010 at 4:16 PM, Jarmo wrote: > Auch. Pretty nice :) > > Jarmo > > On Mon, Sep 6, 2010 at 3:48 PM, ?eljko Filipin < > zeljko.filipin at wa-research.ch> wrote: > >> On Mon, Sep 6, 2010 at 2:42 PM, Jarmo wrote: >> > Just wondering, how many (unique) hits does watir.com get in a month? >> >> wordpress.com says (but does not say what the numbers mean, I guess all >> visits): >> >> Months and Years >> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov DecTotal 2009 >> >> >> >> >> 1,0281,4892,0987,49735,45335,83936,785 120,189201040,33440,957 46,701 >> 44,51839,55641,08542,98740,780 6,365 >> >> >> 343,283 Average per Day >> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov DecOverall 2009 >> >> >> >> >> 5148682501,1441,1951,187 5892010 1,3011,463 1,5061,4841,2761,3701,387 >> 1,3151,174 >> >> >> 1,382?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: From zeljko.filipin at wa-research.ch Mon Sep 6 09:21:29 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Mon, 6 Sep 2010 15:21:29 +0200 Subject: [Wtr-development] Fwd: Watir Advertising In-Reply-To: References: <20100824124730.4r7k61i1usosgcw4@box580.bluehost.com> Message-ID: On Mon, Sep 6, 2010 at 3:16 PM, Jarmo wrote: > Forgot to ask, no analytics installed? Maybe should do it, just for the curiosity. watir.com is hosted on wordpress.com that does not allow installing plugins (as far as I know). ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From notethan at gmail.com Thu Sep 9 12:45:18 2010 From: notethan at gmail.com (Ethan) Date: Thu, 9 Sep 2010 12:45:18 -0400 Subject: [Wtr-development] index in hash of attributes Message-ID: For vapir, I am pondering on deprecating usage of :index in a hash of attributes specifying an element. I'm looking to get reactions on this idea from watir devs. Basically, when using a hash, :index is a special case and is extracted from the attributes hash. I'd prefer not to have that one hash key treated differently from every other, and I think that the alternative I propose (below) is more elegant all around. I would replace this functionality with index being specified as a subscript of element collections. That is, instead of: container.element(:class => 'some class', :index => 2) you'd do: container.elements(:class => 'some class')[2] The latter is already supported in vapir's master, though not yet released as a gem (due to difficulties with some cases of subscript being 0-indexed, when Array is returned, and some being 1-indexed where an element collection is returned). Thoughts? -Ethan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Thu Sep 9 15:57:18 2010 From: jarmo.p at gmail.com (Jarmo) Date: Thu, 9 Sep 2010 22:57:18 +0300 Subject: [Wtr-development] index in hash of attributes In-Reply-To: References: Message-ID: I think that it is a nice idea. Although if i made a suggestion to make indexes 0-based then there were arguments against it due to the backwards incompatibility concern. I like the fact that it is possible to specify arguments for the element collections (elements(:class => "something")), because currently it isn't (for vanilla Watir) and you'd have to use #find or #find_all instead. Anyway, +1 from me. Jarmo On Thu, Sep 9, 2010 at 7:45 PM, Ethan wrote: > For vapir, I am pondering on deprecating usage of :index in a hash of > attributes specifying an element. I'm looking to get reactions on this idea > from watir devs. > Basically, when using a hash, :index is a special case and is extracted from > the attributes hash. I'd prefer not to have that one hash key treated > differently from every other, and I think that the alternative I propose > (below) is more elegant all around. > I would replace this functionality with index being specified as a subscript > of element collections. That is, instead of: > container.element(:class => 'some class', :index => 2) > you'd do: > container.elements(:class => 'some class')[2] > The latter is already supported in vapir's master, though not yet released > as a gem (due to difficulties with some cases of subscript being 0-indexed, > when Array is returned, and some being 1-indexed where an element collection > is returned). > Thoughts? > -Ethan > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From notethan at gmail.com Thu Sep 9 16:12:04 2010 From: notethan at gmail.com (Ethan) Date: Thu, 9 Sep 2010 16:12:04 -0400 Subject: [Wtr-development] index in hash of attributes In-Reply-To: References: Message-ID: I am all for 0-indexing (which has come up plenty of times before on this list, I think). I plan to make vapir configurable as soon as I have time to put into that, and at some point make 0-indexing the default, and at some point after that deprecate 1-indexing. On Thu, Sep 9, 2010 at 15:57, Jarmo wrote: > I think that it is a nice idea. Although if i made a suggestion to > make indexes 0-based then there were arguments against it due to the > backwards incompatibility concern. > > I like the fact that it is possible to specify arguments for the > element collections (elements(:class => "something")), because > currently it isn't (for vanilla Watir) and you'd have to use #find or > #find_all instead. > > Anyway, +1 from me. > > Jarmo > > On Thu, Sep 9, 2010 at 7:45 PM, Ethan wrote: > > For vapir, I am pondering on deprecating usage of :index in a hash of > > attributes specifying an element. I'm looking to get reactions on this > idea > > from watir devs. > > Basically, when using a hash, :index is a special case and is extracted > from > > the attributes hash. I'd prefer not to have that one hash key treated > > differently from every other, and I think that the alternative I propose > > (below) is more elegant all around. > > I would replace this functionality with index being specified as a > subscript > > of element collections. That is, instead of: > > container.element(:class => 'some class', :index => 2) > > you'd do: > > container.elements(:class => 'some class')[2] > > The latter is already supported in vapir's master, though not yet > released > > as a gem (due to difficulties with some cases of subscript being > 0-indexed, > > when Array is returned, and some being 1-indexed where an element > collection > > is returned). > > Thoughts? > > -Ethan > > > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jari.bakken at gmail.com Thu Sep 9 16:16:34 2010 From: jari.bakken at gmail.com (Jari Bakken) Date: Thu, 9 Sep 2010 22:16:34 +0200 Subject: [Wtr-development] index in hash of attributes In-Reply-To: References: Message-ID: On Thu, Sep 9, 2010 at 6:45 PM, Ethan wrote: > For vapir, I am pondering on deprecating usage of :index in a hash of > attributes specifying an element. I'm looking to get reactions on this idea > from watir devs. > Basically, when using a hash, :index is a special case and is extracted from > the attributes hash. I'd prefer not to have that one hash key treated > differently from every other, and I think that the alternative I propose > (below) is more elegant all around. It's not just this one key though - :xpath, :text, :value are all special cases (with the latter two being equivalent in some cases) - which makes me wonder if there are also other reasons why you'd like it removed? Just curious. :) > I would replace this functionality with index being specified as a subscript > of element collections. That is, instead of: > container.element(:class => 'some class', :index => 2) > you'd do: > container.elements(:class => 'some class')[2] > The latter is already supported in vapir's master, though not yet released > as a gem (due to difficulties with some cases of subscript being 0-indexed, I don't really have a strong opinion on this, but I have no problem removing :index if there is consensus for that. Passing a selector hash to the plural Container methods is supported in watir-webdriver. So ~1 from me. From notethan at gmail.com Thu Sep 9 18:22:46 2010 From: notethan at gmail.com (Ethan) Date: Thu, 9 Sep 2010 18:22:46 -0400 Subject: [Wtr-development] index in hash of attributes In-Reply-To: References: Message-ID: :xpath is a special case (there are a few of these), but it's not extracted from a hash if one is given. In vapir, using a hash implies that all of the hash pairs correspond to DOM attributes and attribute values of the dom element. :xpath isn't supported as a hash key, since it's not an attribute of the element on the dom, so no exception is made for it. It is only supported as a 'how' in (how, what) arguments - that is to say, element(:xpath, '//whatever') will use an xpath locator, whereas element(:xpath => '//whatever') will look for an element with an attribute called 'xpath' with a value of '//whatever' (which won't exist). I think that this makes sense, because the only reason to use a hash is to combine multiple selectors. There is no way to combine :xpath with any other selector. (theoretically, maybe, but I haven't implemented it that way and don't plan to.) So, no exception is made for :xpath as a hash key. :text and :value aren't special cases, they are both attributes on the dom and can be sensibly used together in a hash of attributes. I wrote a bit about this for the vapir wiki (just now, since I haven't done a good job documenting it anywhere previously) - it's up at http://wiki.github.com/vapir/vapir/locators . On Thu, Sep 9, 2010 at 16:16, Jari Bakken wrote: > On Thu, Sep 9, 2010 at 6:45 PM, Ethan wrote: > > For vapir, I am pondering on deprecating usage of :index in a hash of > > attributes specifying an element. I'm looking to get reactions on this > idea > > from watir devs. > > Basically, when using a hash, :index is a special case and is extracted > from > > the attributes hash. I'd prefer not to have that one hash key treated > > differently from every other, and I think that the alternative I propose > > (below) is more elegant all around. > > It's not just this one key though - :xpath, :text, :value are all > special cases (with the latter two being equivalent in some cases) - > which makes me wonder if there are also other reasons why you'd like > it removed? Just curious. :) > > > I would replace this functionality with index being specified as a > subscript > > of element collections. That is, instead of: > > container.element(:class => 'some class', :index => 2) > > you'd do: > > container.elements(:class => 'some class')[2] > > The latter is already supported in vapir's master, though not yet > released > > as a gem (due to difficulties with some cases of subscript being > 0-indexed, > > I don't really have a strong opinion on this, but I have no problem > removing :index if there is consensus for that. Passing a selector > hash to the plural Container methods is supported in watir-webdriver. > > So ~1 from me. > _______________________________________________ > 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 jari.bakken at gmail.com Thu Sep 9 19:16:45 2010 From: jari.bakken at gmail.com (Jari Bakken) Date: Fri, 10 Sep 2010 01:16:45 +0200 Subject: [Wtr-development] index in hash of attributes In-Reply-To: References: Message-ID: On Fri, Sep 10, 2010 at 12:22 AM, Ethan wrote: > :xpath is a special case (there are a few of these), but it's not extracted > from a hash if one is given. In vapir, using a hash implies that all of the > hash pairs correspond to DOM attributes and attribute values of the dom > element. :xpath isn't supported as a hash key, since it's not an attribute > of the element on the dom, so no exception is made for it. It is?only > supported as a 'how' in (how, what) arguments -?that is to say, > > element(:xpath, '//whatever') > will use an xpath locator, whereas > element(:xpath => '//whatever') > will look for an element with an attribute called 'xpath' with a value of > '//whatever' (which won't exist). This is a bug, in my opinion. > I think that this makes sense, because the only reason to use a hash is to > combine multiple selectors. There is no way to combine :xpath with any other > selector. (theoretically, maybe, but I haven't implemented it that way and > don't plan to.) So, no exception is made for :xpath as a hash key. Right. watir-webdriver currently will just use the xpath given and ignore anything else - a more correct approach would probably be to raise if additional selectors are given. But I think not allowing (:xpath => "foo") as an equivalent of (:xpath, "foo") is just adding unnecessary API complexity and will be super confusing to users. The less exceptions and special rules to remember, the better. > :text and :value aren't special cases, they are both attributes on the dom > and can be sensibly used together in a hash of attributes. > I wrote a bit about this for the vapir wiki (just now, since I haven't done > a good job documenting it anywhere previously) - it's up > at?http://wiki.github.com/vapir/vapir/locators . > This is a minor point, but :text and :value are not "attributes on the dom" according to the HTML spec (they do appear, but only on a small set of elements). :text in particular is definitely special cased in Watir (e.g. it should match against the inner text for