From zeljko.filipin at wa-research.ch Fri Oct 1 05:20:07 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Fri, 1 Oct 2010 11:20:07 +0200 Subject: [Wtr-development] README file to github!? In-Reply-To: References: Message-ID: On Thu, Sep 30, 2010 at 10:32 PM, Jarmo wrote: > 1) There is only FireWatir examples. Good point. I will make separate require statements for each supported gem. > 2) Maybe use hashrocket in locating elements instead of "old" > comma-style? I did not know that => is called hashrocket :) I was thinking about updating docs to use hashrocket syntax but never had the time. I have: - updated both README file and http://watir.com/examples/ - renamed "b" variable to "browser" to make it clear to the new people where it points to - removed "full code" section from examples page to make it easier to update the code, so I do not have to do it three times (already doing it two times, README file and Examples page) - removed "Starting a new browser at our site directly" section, I do not think it is so important that it should be included in the basic examples - added all watir gems (stable and experimental) to README Please let me know if you disagree with my changes. More information: http://github.com/bret/watir/pull/8 ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Fri Oct 1 05:33:57 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Fri, 1 Oct 2010 11:33:57 +0200 Subject: [Wtr-development] gem owner In-Reply-To: References: Message-ID: On Thu, Sep 30, 2010 at 5:16 PM, Charley Baker wrote: > You can write a quick script to remove > the other names if you want. :) Done: $ gem owner watir Owners for gem: watir - charley.baker at gmail.com - zeljko.filipin at gmail.com - bret at pettichord.com $ gem owner firewatir Owners for gem: firewatir - charley.baker at gmail.com - zeljko.filipin at gmail.com - bret at pettichord.com $ gem owner commonwatir Owners for gem: commonwatir - zeljko.filipin at gmail.com - bret at pettichord.com - charley.baker at gmail.com Should I add Jarmo? Anybody else? I left myself in the list because I saw that I can "edit the links through Gemcutter's web interface". ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Fri Oct 1 05:40:41 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Fri, 1 Oct 2010 11:40:41 +0200 Subject: [Wtr-development] gem owner In-Reply-To: References: Message-ID: Also for safariwatir. Before: $ gem owner safariwatir Owners for gem: safariwatir - tom at infoether.com - rubyforge at clabs.org - zeljko.filipin at gmail.com - charley.baker at gmail.com - angrez at gmail.com - srao at thoughtworks.com - peter.chau at shaw.ca - lorenzo_jorquera at yahoo.com - jmccarthy at cafepress.com - fox at atomicobject.com - christopher.mcmahon at gmail.com - mike at michaeldkelly.com - esh at qualitytree.com - ati.ozgur at gmail.com - jeff.darklight at gmail.com - kingsley at icecode.org - bret at pettichord.com - jkohl at telusplanet.net - paul.rogers at shaw.ca After: $ gem owner safariwatir Owners for gem: safariwatir - tom at infoether.com - zeljko.filipin at gmail.com - charley.baker at gmail.com - bret at pettichord.com ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Fri Oct 1 05:42:07 2010 From: alister.scott at gmail.com (Alister Scott) Date: Fri, 1 Oct 2010 19:42:07 +1000 Subject: [Wtr-development] README file to github!? In-Reply-To: References: Message-ID: Wow! Thanks for updating watir.com/examples so quickly. I think it's looking good. Thanks for all your work on this ?eljko! Cheers, Alister On Fri, Oct 1, 2010 at 7:20 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Thu, Sep 30, 2010 at 10:32 PM, Jarmo wrote: > > 1) There is only FireWatir examples. > > Good point. I will make separate require statements for each supported gem. > > > > 2) Maybe use hashrocket in locating elements instead of "old" > > comma-style? > > I did not know that => is called hashrocket :) > > I was thinking about updating docs to use hashrocket syntax but never had > the time. > > I have: > > - updated both README file and http://watir.com/examples/ > - renamed "b" variable to "browser" to make it clear to the new people > where it points to > - removed "full code" section from examples page to make it easier to > update the code, so I do not have to do it three times (already doing it two > times, README file and Examples page) > - removed "Starting a new browser at our site directly" section, I do not > think it is so important that it should be included in the basic examples > - added all watir gems (stable and experimental) to README > > Please let me know if you disagree with my changes. > > More information: > > http://github.com/bret/watir/pull/8 > > ?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 Fri Oct 1 05:54:06 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Fri, 1 Oct 2010 11:54:06 +0200 Subject: [Wtr-development] gem owner In-Reply-To: References: Message-ID: Since I can edit web pages for these gems I have added links to Source Code, Documentation, Wiki, Mailing List and Bug Tracker for all of them: https://rubygems.org/gems/watir https://rubygems.org/gems/firewatir https://rubygems.org/gems/commonwatir https://rubygems.org/gems/safariwatir ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheezy at me.com Fri Oct 1 05:58:04 2010 From: cheezy at me.com (Jeff Morgan) Date: Fri, 01 Oct 2010 05:58:04 -0400 Subject: [Wtr-development] Watir 1.6.6.rc2 is up and ready for testing In-Reply-To: References: <16180D39-FDDB-489D-9F53-7423893F0293@me.com> Message-ID: <1B70B550-96C2-48EA-9D3B-765982A5B039@me.com> Just a little complexity is all. I have some testers with cukes using watir and activerecord. Also using factory_girl with activerecord. Needed to make changes to force everything to use 2.3.9 activerecord/resource and 1.2.4 factory_girl. That's all. On Sep 30, 2010, at 5:17 PM, Charley Baker wrote: > Unfortunately I didn't remove it from this version, was planning on > 1.6.7 in a few weeks, and lumped it in there. It is a large dependency > with only a couple of methods being used. What are you seeing? > > > Charley Baker > Lead Developer, Watir, http://watir.com > > > > On Thu, Sep 30, 2010 at 2:33 PM, Jarmo wrote: >> Not for this version, i guess. Maybe in next version. Any problems with it? >> >> Jarmo >> >> On Thu, Sep 30, 2010 at 8:31 PM, Jeff Morgan wrote: >>> Charlie, >>> >>> Are there any plans to try to eliminate the dependency on activesupport prior to the final release? >>> >>> Thanks >>> -Cheezy >>> >>> >>> On Sep 30, 2010, at 11:09 AM, Charley Baker wrote: >>> >>>> Hello (fire)watirists! >>>> >>>> We are happy to announce that a (very) long-waited (Fire)Watir >>>> 1.6.6.rc2 is out! Please grab it now. >>>> >>>> Changes from rc1 include: >>>> * A main README.rdoc file (Zeljko) >>>> * Unit test fixes for Firewatir (Zeljko) >>>> * Ability to run unit tests from gems (Jarmo) >>>> * Additional unit test and bug fixes (Jarmo) >>>> >>>> You can check out the full changelog at >>>> http://github.com/bret/watir/blob/master/CHANGES >>>> >>>> >>>> Make sure your local gem system is up to date. >>>> >>>> gem update --system >>>> run gem -v at the command line, you should be running 1.3.7 >>>> >>>> gem install (fire)watir --pre >>>> >>>> Note: If you're installing on Mac or Linux you'll want to use >>>> firewatir for the gem install. >>>> ...and give it a go. Try to use it with your existing test suites and >>>> so on to see if there are any issues. >>>> >>>> If there are any problems then: >>>> 1) Fix it and send a pull request on Github, our main github repo: >>>> http://github.com/bret/watir >>>> This is the preferred way of accepting patches, we're happy to work >>>> with you on how to do this, github also has extensive docs on how to >>>> fork and submit a pull request. >>>> 2) Add it to our JIRA tracker: http://jira.openqa.org/browse/WTR >>>> If you need help with that let us know. >>>> >>>> >>>> With your help, we will be getting out a final version of 1.6.6 >>>> shortly and working on continuously rolling out releases on a quick >>>> timeline. We already have actions lined up for 1.6.7 which should be >>>> released fairly quickly as we make our way through the current tickets >>>> and changes and roll them into releases. >>>> >>>> If you do have time and can help, please let us know, we can take any >>>> help from documentation to running tests on various OSes. We're a >>>> friendly project and would be happy to mentor you if you and/or your >>>> company is willing to put in the time. >>>> Cheers, >>>> Charley & Jarmo >>>> _______________________________________________ >>>> Wtr-development mailing list >>>> Wtr-development at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development From zeljko.filipin at wa-research.ch Fri Oct 1 06:55:46 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Fri, 1 Oct 2010 12:55:46 +0200 Subject: [Wtr-development] Watir 1.6.6.rc2 is up and ready for testing In-Reply-To: References: Message-ID: On Thu, Sep 30, 2010 at 5:09 PM, Charley Baker wrote: > We are happy to announce that a (very) long-waited (Fire)Watir > 1.6.6.rc2 is out! C:\watir\firewatir>rake test (...) 318 tests, 1679 assertions, 1 failures, 2 errors Failed tests are our old friends "attach to new window". C:\watir\watir>rake test (...) 311 tests, 1467 assertions, 0 failures, 0 errors ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Fri Oct 1 08:02:26 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Fri, 1 Oct 2010 14:02:26 +0200 Subject: [Wtr-development] Questions about unit tests In-Reply-To: References: Message-ID: On Thu, Sep 30, 2010 at 7:32 PM, Charley Baker wrote: > Yep, that's old stuff. http://github.com/bret/watir/pull/9 ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Fri Oct 1 08:56:15 2010 From: alister.scott at gmail.com (Alister Scott) Date: Fri, 1 Oct 2010 22:56:15 +1000 Subject: [Wtr-development] doc folder In-Reply-To: References: Message-ID: I agree to delete it. If we need to access something missing we can always look in a previous version. All the doco is now on watir.com or the wiki. Cheers, Alister On Wed, Sep 29, 2010 at 8:48 PM, Jarmo wrote: > Yes, agreed. But without checking that it isn't really anywhere in use > i cannot guarantee that it really isn't. There might be some sneaky > rake task or whatever :) > > Jarmo > > On Wed, Sep 29, 2010 at 11:47 AM, ?eljko Filipin > wrote: > > On Mon, Sep 27, 2010 at 1:25 PM, Jarmo wrote: > >> Yes, everything which is not used, could be deleted. But i'd start > >> cleaning up repo after final release of 1.6.6. > > > > There is no rush, it can wait, but I see no harm in just deleting a > folder > > that is not used for over a year. It is still in version control. > > > > ?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 alister.scott at gmail.com Fri Oct 1 08:30:16 2010 From: alister.scott at gmail.com (Alister Scott) Date: Fri, 1 Oct 2010 22:30:16 +1000 Subject: [Wtr-development] Watir 1.6.6.rc2 is up and ready for testing In-Reply-To: References: Message-ID: I ran unit tests on watir 1.6.6rc2 on Win 7 IE9 and got the following: Finished in 64.603 seconds. 1) Error: test_status_returns_window_status(TC_Browser): WIN32OLERuntimeError: statusText OLE error code:80004005 in HRESULT error code:0x80020009 Exception occurred. C:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.6.rc2/lib/watir/ie-class.rb:343:in `method_missing' C:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.6.rc2/lib/watir/ie-class.rb:343:in `status' C:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.6.rc2/unittests/browser_test. rb:13:in `test_status_returns_window_status' 2) Failure: test_form_outer_html(TC_Forms2) [./unittests/../unittests/form_test.rb:53]: <"action=pass2.html id=f2 method=get name=test2>
expected but was <"action=pass2.html id=f2 method=get name=test2>
. 311 tests, 1466 assertions, 1 failures, 1 errors rake aborted! Command failed with status (1): [c:/ruby/bin/ruby.exe -I"lib" "c:/ruby/lib/...] (See full trace by running task with --trace) 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 Fri, Oct 1, 2010 at 8:55 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Thu, Sep 30, 2010 at 5:09 PM, Charley Baker > wrote: > > We are happy to announce that a (very) long-waited (Fire)Watir > > 1.6.6.rc2 is out! > > C:\watir\firewatir>rake test > (...) > 318 tests, 1679 assertions, 1 failures, 2 errors > > Failed tests are our old friends "attach to new window". > > > > C:\watir\watir>rake test > (...) > 311 tests, 1467 assertions, 0 failures, 0 errors > > ?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 alister.scott at gmail.com Fri Oct 1 08:37:16 2010 From: alister.scott at gmail.com (Alister Scott) Date: Fri, 1 Oct 2010 22:37:16 +1000 Subject: [Wtr-development] Watir 1.6.6.rc2 is up and ready for testing In-Reply-To: References: Message-ID: Same result as ?eljko on Firefox on Windows 7. On Fri, Oct 1, 2010 at 10:30 PM, Alister Scott wrote: > I ran unit tests on watir 1.6.6rc2 on Win 7 IE9 and got the following: > > Finished in 64.603 seconds. > > 1) Error: > test_status_returns_window_status(TC_Browser): > WIN32OLERuntimeError: statusText > OLE error code:80004005 in > > HRESULT error code:0x80020009 > Exception occurred. > > C:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.6.rc2/lib/watir/ie-class.rb:343:in > `method_missing' > > C:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.6.rc2/lib/watir/ie-class.rb:343:in > `status' > > C:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.6.rc2/unittests/browser_test. > rb:13:in `test_status_returns_window_status' > > 2) Failure: > test_form_outer_html(TC_Forms2) [./unittests/../unittests/form_test.rb:53]: > <"action=pass2.html id=f2 method=get name=test2>
value=sub > mit"> expected but was > <"action=pass2.html id=f2 method=get name=test2>
type=submi > t value=submit">. > > 311 tests, 1466 assertions, 1 failures, 1 errors > rake aborted! > Command failed with status (1): [c:/ruby/bin/ruby.exe -I"lib" > "c:/ruby/lib/...] > > (See full trace by running task with --trace) > > 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 Fri, Oct 1, 2010 at 8:55 PM, ?eljko Filipin < > zeljko.filipin at wa-research.ch> wrote: > >> On Thu, Sep 30, 2010 at 5:09 PM, Charley Baker >> wrote: >> > We are happy to announce that a (very) long-waited (Fire)Watir >> > 1.6.6.rc2 is out! >> >> C:\watir\firewatir>rake test >> (...) >> 318 tests, 1679 assertions, 1 failures, 2 errors >> >> Failed tests are our old friends "attach to new window". >> >> >> >> C:\watir\watir>rake test >> (...) >> 311 tests, 1467 assertions, 0 failures, 0 errors >> >> ?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 Fri Oct 1 10:40:04 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Fri, 1 Oct 2010 16:40:04 +0200 Subject: [Wtr-development] element.to_s instead of element.show In-Reply-To: References: Message-ID: If Ethan (or anybody else) does not have the will or the time to play with it, I would delete all show_*, show and to_s methods. For the next version, if anybody calls those methods, it would just output a short note and a link to a page that lists some popular developer add-ons for popular browsers. For some future version, we could just delete the methods. What do you think? ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Fri Oct 1 11:08:38 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Fri, 1 Oct 2010 17:08:38 +0200 Subject: [Wtr-development] source cleanup Message-ID: I guess I will have a few questions related to source cleanup, so I have decided to start a new thread: 1) We have licenses all over the place: http://github.com/bret/watir/blob/master/watir/lib/watir/ie.rb http://github.com/bret/watir/blob/master/firewatir/LICENSE http://github.com/bret/watir/blob/master/commonwatir/LICENSE http://github.com/bret/watir/blob/master/watir/lib/license.rb http://github.com/bret/watir/blob/master/watir/lib/watir/winClicker.rb Should I move it to LICENSE file located in root? 2) Should we delete installer folder? http://github.com/bret/watir/tree/1.6.5.rc2/watir/installer/ 3) Should we delete watir-simple? http://github.com/bret/watir/blob/master/watir/lib/watir/watir_simple.rb 4) Should we delete these files: http://github.com/bret/watir/blob/master//.project http://github.com/bret/watir/blob/master//transform-results.xsl http://github.com/bret/watir/blob/master/commonwatir/.project http://github.com/bret/watir/blob/master/firewatir/.loadpath http://github.com/bret/watir/blob/master/firewatir/.project http://github.com/bret/watir/blob/master/watir/.project http://github.com/bret/watir/blob/master/watir/unittests/.cvsignore 5) Looks like these files need to be updated: http://github.com/bret/watir/blob/master/watir/building_watir.txt http://github.com/bret/watir/blob/master/watir/install_dev_gems.bat http://github.com/bret/watir/blob/master/watir/watir_release.txt I could do everything except 5) ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From charley.baker at gmail.com Fri Oct 1 11:33:21 2010 From: charley.baker at gmail.com (Charley Baker) Date: Fri, 1 Oct 2010 09:33:21 -0600 Subject: [Wtr-development] source cleanup In-Reply-To: References: Message-ID: Answers inline. On Fri, Oct 1, 2010 at 9:08 AM, ?eljko Filipin wrote: > I guess I will have a few questions related to source cleanup, so I have > decided to start a new thread: > > 1) We have licenses all over the place: > > http://github.com/bret/watir/blob/master/watir/lib/watir/ie.rb > http://github.com/bret/watir/blob/master/firewatir/LICENSE > http://github.com/bret/watir/blob/master/commonwatir/LICENSE > http://github.com/bret/watir/blob/master/watir/lib/license.rb > http://github.com/bret/watir/blob/master/watir/lib/watir/winClicker.rb > > Should I move it to LICENSE file located in root? The license holders would be the ones to answer this question - Paul, Bret and Angrez. > > 2) Should we delete installer folder? > > http://github.com/bret/watir/tree/1.6.5.rc2/watir/installer/ Sounds good, I don't see us using an installer again. > > 3) Should we delete watir-simple? > > http://github.com/bret/watir/blob/master/watir/lib/watir/watir_simple.rb http://jira.openqa.org/browse/WTR-131 I'd suggested moving it to contrib a long time ago, it might be worth asking on the main list if anyone uses it. As of now, it's definitely unsupported code. > > 4) Should we delete these files: > > http://github.com/bret/watir/blob/master//.project > http://github.com/bret/watir/blob/master//transform-results.xsl > http://github.com/bret/watir/blob/master/commonwatir/.project > http://github.com/bret/watir/blob/master/firewatir/.loadpath > http://github.com/bret/watir/blob/master/firewatir/.project > http://github.com/bret/watir/blob/master/watir/.project > http://github.com/bret/watir/blob/master/watir/unittests/.cvsignore > Yes for everything with the possible exception of the transform-results.xsl. There are a lot of CI related tasks in the rake file as well, anyone vote on keeping or deleting these? > 5) Looks like these files need to be updated: > > http://github.com/bret/watir/blob/master/watir/building_watir.txt > http://github.com/bret/watir/blob/master/watir/install_dev_gems.bat > http://github.com/bret/watir/blob/master/watir/watir_release.txt These could be deleted as well, the whole process is different now and much simpler. I suppose I could write a new watir_release doc, it's a pretty trivial process now to push a release. > > I could do everything except 5) > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From marekj.com at gmail.com Fri Oct 1 12:02:38 2010 From: marekj.com at gmail.com (marekj) Date: Fri, 1 Oct 2010 11:02:38 -0500 Subject: [Wtr-development] README file to github!? In-Reply-To: References: Message-ID: Hi Guys, Sorry for not being engaged over the last few months, I had to move family from Dallas to Austin and have kids start new schools and so on so not much time for fun. Please take a look here. http://rubyforge.org/pipermail/wtr-development/2010-June/001863.html the repo is here http://github.com/marekj/watir/tree/rdocfix the rdoc out of this repo is here http://wtr.rubyforge.org/rdoc/1.6.5/ The main objective of this fix was to fix rdoc generation, make Readme files presentable and also make yardoc output. I see that some of this didn't make it to the main watir. Can you still use some of the fixes I made? marekj http://rubytester.com On Fri, Oct 1, 2010 at 4:42 AM, Alister Scott wrote: > Wow! Thanks for updating watir.com/examples so quickly. > I think it's looking good. Thanks for all your work on this ?eljko! > > Cheers, > > Alister > > > On Fri, Oct 1, 2010 at 7:20 PM, ?eljko Filipin > wrote: >> >> On Thu, Sep 30, 2010 at 10:32 PM, Jarmo wrote: >> > 1) There is only FireWatir examples. >> >> Good point. I will make separate require statements for each supported >> gem. >> >> > 2) Maybe use hashrocket in locating elements instead of "old" >> > comma-style? >> >> I did not know that => is called hashrocket :) >> >> I was thinking about updating docs to use hashrocket syntax but never had >> the time. >> >> I have: >> >> - updated both README file and http://watir.com/examples/ >> - renamed "b" variable to "browser" to make it clear to the new people >> where it points to >> - removed "full code" section from examples page to make it easier to >> update the code, so I do not have to do it three times (already doing it two >> times, README file and Examples page) >> - removed "Starting a new browser at our site directly" section, I do not >> think it is so important that it should be included in the basic examples >> - added all watir gems (stable and experimental) to README >> >> Please let me know if you disagree with my changes. >> >> More information: >> >> http://github.com/bret/watir/pull/8 >> >> ?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 > From marekj.com at gmail.com Fri Oct 1 12:33:41 2010 From: marekj.com at gmail.com (marekj) Date: Fri, 1 Oct 2010 11:33:41 -0500 Subject: [Wtr-development] README file to github!? In-Reply-To: References: Message-ID: I wanted to explain and defend my view of why there are 4 README.rdoc files in watir project. Watir project on github has a README.rdoc file as a landing page which is used to present the project and its 3 separate gems. Each library firewatir, watir, commonwatir has a README.rdoc specific to that library so each gem then has it's own readme. The main top level readme never makes it to the user's machine when they install the gems. If the user runs rdoc generation from the gems on their own machine they now have a local README for each one of the gems. The toplevel gem is visible on github as a landing page for the project. And that is why I thought there should be 4 README.rdoc files marekj http://rubytester.com On Fri, Oct 1, 2010 at 11:02 AM, marekj wrote: > Hi Guys, > Sorry for not being engaged over the last few months, I had to move > family from Dallas to Austin and have kids start new schools and so on > so not much time for fun. > > Please take a look here. > http://rubyforge.org/pipermail/wtr-development/2010-June/001863.html > the repo is here > http://github.com/marekj/watir/tree/rdocfix > the rdoc out of this repo is here > http://wtr.rubyforge.org/rdoc/1.6.5/ > > The main objective of this fix was to fix rdoc generation, make Readme > files presentable > and also make yardoc output. > > I see that some of this didn't make it to the main watir. > Can you still use some of the fixes I made? > > > > > marekj > > http://rubytester.com > > > > > On Fri, Oct 1, 2010 at 4:42 AM, Alister Scott wrote: >> Wow! Thanks for updating watir.com/examples so quickly. >> I think it's looking good. Thanks for all your work on this ?eljko! >> >> Cheers, >> >> Alister >> >> >> On Fri, Oct 1, 2010 at 7:20 PM, ?eljko Filipin >> wrote: >>> >>> On Thu, Sep 30, 2010 at 10:32 PM, Jarmo wrote: >>> > 1) There is only FireWatir examples. >>> >>> Good point. I will make separate require statements for each supported >>> gem. >>> >>> > 2) Maybe use hashrocket in locating elements instead of "old" >>> > comma-style? >>> >>> I did not know that => is called hashrocket :) >>> >>> I was thinking about updating docs to use hashrocket syntax but never had >>> the time. >>> >>> I have: >>> >>> - updated both README file and http://watir.com/examples/ >>> - renamed "b" variable to "browser" to make it clear to the new people >>> where it points to >>> - removed "full code" section from examples page to make it easier to >>> update the code, so I do not have to do it three times (already doing it two >>> times, README file and Examples page) >>> - removed "Starting a new browser at our site directly" section, I do not >>> think it is so important that it should be included in the basic examples >>> - added all watir gems (stable and experimental) to README >>> >>> Please let me know if you disagree with my changes. >>> >>> More information: >>> >>> http://github.com/bret/watir/pull/8 >>> >>> ?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 >> > From jarmo.p at gmail.com Fri Oct 1 13:40:49 2010 From: jarmo.p at gmail.com (Jarmo) Date: Fri, 1 Oct 2010 20:40:49 +0300 Subject: [Wtr-development] source cleanup In-Reply-To: References: Message-ID: Don't do anything before 1.6.6 has released. Also, i've sent similar mail before into this list (don't have time to look it up currently). Jarmo On Fri, Oct 1, 2010 at 6:08 PM, ?eljko Filipin wrote: > I guess I will have a few questions related to source cleanup, so I have > decided to start a new thread: > > 1) We have licenses all over the place: > > http://github.com/bret/watir/blob/master/watir/lib/watir/ie.rb > http://github.com/bret/watir/blob/master/firewatir/LICENSE > http://github.com/bret/watir/blob/master/commonwatir/LICENSE > http://github.com/bret/watir/blob/master/watir/lib/license.rb > http://github.com/bret/watir/blob/master/watir/lib/watir/winClicker.rb > > Should I move it to LICENSE file located in root? > > 2) Should we delete installer folder? > > http://github.com/bret/watir/tree/1.6.5.rc2/watir/installer/ > > 3) Should we delete watir-simple? > > http://github.com/bret/watir/blob/master/watir/lib/watir/watir_simple.rb > > 4) Should we delete these files: > > http://github.com/bret/watir/blob/master//.project > http://github.com/bret/watir/blob/master//transform-results.xsl > http://github.com/bret/watir/blob/master/commonwatir/.project > http://github.com/bret/watir/blob/master/firewatir/.loadpath > http://github.com/bret/watir/blob/master/firewatir/.project > http://github.com/bret/watir/blob/master/watir/.project > http://github.com/bret/watir/blob/master/watir/unittests/.cvsignore > > 5) Looks like these files need to be updated: > > http://github.com/bret/watir/blob/master/watir/building_watir.txt > http://github.com/bret/watir/blob/master/watir/install_dev_gems.bat > http://github.com/bret/watir/blob/master/watir/watir_release.txt > > I could do everything except 5) > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From bret at pettichord.com Fri Oct 1 13:46:04 2010 From: bret at pettichord.com (Bret Pettichord) Date: Fri, 1 Oct 2010 12:46:04 -0500 Subject: [Wtr-development] source cleanup In-Reply-To: References: Message-ID: On Fri, Oct 1, 2010 at 10:08 AM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > I guess I will have a few questions related to source cleanup, so I have > decided to start a new thread: > > 1) We have licenses all over the place: > > http://github.com/bret/watir/blob/master/watir/lib/watir/ie.rb > http://github.com/bret/watir/blob/master/firewatir/LICENSE > http://github.com/bret/watir/blob/master/commonwatir/LICENSE > http://github.com/bret/watir/blob/master/watir/lib/license.rb > http://github.com/bret/watir/blob/master/watir/lib/watir/winClicker.rb > > Should I move it to LICENSE file located in root? > Makes sense. 2) Should we delete installer folder? > > http://github.com/bret/watir/tree/1.6.5.rc2/watir/installer/ > Yes > 3) Should we delete watir-simple? > > http://github.com/bret/watir/blob/master/watir/lib/watir/watir_simple.rb > Yes > 4) Should we delete these files: > > http://github.com/bret/watir/blob/master//.project > http://github.com/bret/watir/blob/master//transform-results.xsl > http://github.com/bret/watir/blob/master/commonwatir/.project > http://github.com/bret/watir/blob/master/firewatir/.loadpath > http://github.com/bret/watir/blob/master/firewatir/.project > http://github.com/bret/watir/blob/master/watir/.project > http://github.com/bret/watir/blob/master/watir/unittests/.cvsignore > Yes. The transform result was used for the CI results. I don't think there are any plans to resuscitate this. > 5) Looks like these files need to be updated: > > http://github.com/bret/watir/blob/master/watir/building_watir.txt > http://github.com/bret/watir/blob/master/watir/install_dev_gems.bat > http://github.com/bret/watir/blob/master/watir/watir_release.txt > > I could do everything except 5) > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Fri Oct 1 14:38:49 2010 From: jarmo.p at gmail.com (Jarmo) Date: Fri, 1 Oct 2010 21:38:49 +0300 Subject: [Wtr-development] README file to github!? In-Reply-To: References: Message-ID: I'll take a look at these soon. Thanks. Jarmo On Fri, Oct 1, 2010 at 7:02 PM, marekj wrote: > Hi Guys, > Sorry for not being engaged over the last few months, I had to move > family from Dallas to Austin and have kids start new schools and so on > so not much time for fun. > > Please take a look here. > http://rubyforge.org/pipermail/wtr-development/2010-June/001863.html > the repo is here > http://github.com/marekj/watir/tree/rdocfix > the rdoc out of this repo is here > http://wtr.rubyforge.org/rdoc/1.6.5/ > > The main objective of this fix was to fix rdoc generation, make Readme > files presentable > and also make yardoc output. > > I see that some of this didn't make it to the main watir. > Can you still use some of the fixes I made? > > > > > marekj > > http://rubytester.com > > > > > On Fri, Oct 1, 2010 at 4:42 AM, Alister Scott wrote: >> Wow! Thanks for updating watir.com/examples so quickly. >> I think it's looking good. Thanks for all your work on this ?eljko! >> >> Cheers, >> >> Alister >> >> >> On Fri, Oct 1, 2010 at 7:20 PM, ?eljko Filipin >> wrote: >>> >>> On Thu, Sep 30, 2010 at 10:32 PM, Jarmo wrote: >>> > 1) There is only FireWatir examples. >>> >>> Good point. I will make separate require statements for each supported >>> gem. >>> >>> > 2) Maybe use hashrocket in locating elements instead of "old" >>> > comma-style? >>> >>> I did not know that => is called hashrocket :) >>> >>> I was thinking about updating docs to use hashrocket syntax but never had >>> the time. >>> >>> I have: >>> >>> - updated both README file and http://watir.com/examples/ >>> - renamed "b" variable to "browser" to make it clear to the new people >>> where it points to >>> - removed "full code" section from examples page to make it easier to >>> update the code, so I do not have to do it three times (already doing it two >>> times, README file and Examples page) >>> - removed "Starting a new browser at our site directly" section, I do not >>> think it is so important that it should be included in the basic examples >>> - added all watir gems (stable and experimental) to README >>> >>> Please let me know if you disagree with my changes. >>> >>> More information: >>> >>> http://github.com/bret/watir/pull/8 >>> >>> ?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 >> > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development From jarmo.p at gmail.com Fri Oct 1 14:41:14 2010 From: jarmo.p at gmail.com (Jarmo) Date: Fri, 1 Oct 2010 21:41:14 +0300 Subject: [Wtr-development] README file to github!? In-Reply-To: References: Message-ID: That's just not true. It might be the case at the moment, but i have a plan to fix that. In my mind there should be still 1 README on github and when gems are being made then that same README should be copied into 3 gems. So every gem would have the same README. I don't see much of a point of having different readme-s though since the API should be same anyway (i know it currently isn't 100%, but that shouldn't be in the readme anyway). As you can see then currently on the github isn't any VERSION or CHANGES in commonwatir, watir or firewatir directory, but they're still there when you install gems. Same plan goes to README. Jarmo On Fri, Oct 1, 2010 at 7:33 PM, marekj wrote: > I wanted to explain and defend my view of why there are 4 README.rdoc > files in watir project. > > Watir project on github has a README.rdoc file as a landing page which > is used to present the project and its 3 separate gems. > Each library firewatir, watir, commonwatir has a README.rdoc specific > to that library so each gem then has it's own readme. > The main top level readme never makes it to the user's machine when > they install the gems. > If the user runs rdoc generation from the gems on their own machine > they now have a local README for each one of the gems. > The toplevel gem is visible on github as a landing page for the project. > > And that is why I thought there should be 4 README.rdoc files > > > marekj > > http://rubytester.com > > > > > On Fri, Oct 1, 2010 at 11:02 AM, marekj wrote: >> Hi Guys, >> Sorry for not being engaged over the last few months, I had to move >> family from Dallas to Austin and have kids start new schools and so on >> so not much time for fun. >> >> Please take a look here. >> http://rubyforge.org/pipermail/wtr-development/2010-June/001863.html >> the repo is here >> http://github.com/marekj/watir/tree/rdocfix >> the rdoc out of this repo is here >> http://wtr.rubyforge.org/rdoc/1.6.5/ >> >> The main objective of this fix was to fix rdoc generation, make Readme >> files presentable >> and also make yardoc output. >> >> I see that some of this didn't make it to the main watir. >> Can you still use some of the fixes I made? >> >> >> >> >> marekj >> >> http://rubytester.com >> >> >> >> >> On Fri, Oct 1, 2010 at 4:42 AM, Alister Scott wrote: >>> Wow! Thanks for updating watir.com/examples so quickly. >>> I think it's looking good. Thanks for all your work on this ?eljko! >>> >>> Cheers, >>> >>> Alister >>> >>> >>> On Fri, Oct 1, 2010 at 7:20 PM, ?eljko Filipin >>> wrote: >>>> >>>> On Thu, Sep 30, 2010 at 10:32 PM, Jarmo wrote: >>>> > 1) There is only FireWatir examples. >>>> >>>> Good point. I will make separate require statements for each supported >>>> gem. >>>> >>>> > 2) Maybe use hashrocket in locating elements instead of "old" >>>> > comma-style? >>>> >>>> I did not know that => is called hashrocket :) >>>> >>>> I was thinking about updating docs to use hashrocket syntax but never had >>>> the time. >>>> >>>> I have: >>>> >>>> - updated both README file and http://watir.com/examples/ >>>> - renamed "b" variable to "browser" to make it clear to the new people >>>> where it points to >>>> - removed "full code" section from examples page to make it easier to >>>> update the code, so I do not have to do it three times (already doing it two >>>> times, README file and Examples page) >>>> - removed "Starting a new browser at our site directly" section, I do not >>>> think it is so important that it should be included in the basic examples >>>> - added all watir gems (stable and experimental) to README >>>> >>>> Please let me know if you disagree with my changes. >>>> >>>> More information: >>>> >>>> http://github.com/bret/watir/pull/8 >>>> >>>> ?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 >>> >> > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development From jarmo.p at gmail.com Fri Oct 1 14:43:44 2010 From: jarmo.p at gmail.com (Jarmo) Date: Fri, 1 Oct 2010 21:43:44 +0300 Subject: [Wtr-development] Fwd: [GitHub] Build fixes and attribute fixes [bret/watir GH-1] In-Reply-To: References: <4ca283fc20e0f_6ba73f97533230781c8@fe3.rs.github.com.tmail> Message-ID: I've sent a message to Alan that we're gonna review his pull requests right after 1.6.6 has been released. Just FYI. Jarmo On Wed, Sep 29, 2010 at 5:12 PM, Bret Pettichord wrote: > FYI > > ---------- Forwarded message ---------- > From: GitHub > Date: Tue, Sep 28, 2010 at 7:10 PM > Subject: [GitHub] Build fixes and attribute fixes [bret/watir GH-1] > To: bret at pettichord.com > > > alanshields wants someone to pull from > alanshields:build_fixes_and_attribute_fixes: > > Please find enclosed a set of patches to: > > - Enable building on UNIX > - Correctly handle .attribute_value('foo-bar') > - Not throw an exception when an element like
is checked for > containing text > > Thank you very much for all your work on FireWatir! > Alan Shields > > View Pull Request: http://github.com/bret/watir/pull/1 > > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From marekj.com at gmail.com Fri Oct 1 14:59:04 2010 From: marekj.com at gmail.com (marekj) Date: Fri, 1 Oct 2010 13:59:04 -0500 Subject: [Wtr-development] README file to github!? In-Reply-To: References: Message-ID: On Fri, Oct 1, 2010 at 1:41 PM, Jarmo wrote: > That's just not true. It might be the case at the moment, but i have a > plan to fix that. In my mind there should be still 1 README on github > and when gems are being made then that same README should be copied > into 3 gems. So every gem would have the same README. I don't see much > of a point of having different readme-s Thanks Jarmo, now I know what you mean to have one README as a template. I had not thought of that. > though since the API should be > same anyway (i know it currently isn't 100%, but that shouldn't be in > the readme anyway). > > As you can see then currently on the github isn't any VERSION or > CHANGES in commonwatir, watir or firewatir directory, but they're > still there when you install gems. Same plan goes to README. > > Jarmo > > On Fri, Oct 1, 2010 at 7:33 PM, marekj wrote: >> I wanted to explain and defend my view of why there are 4 README.rdoc >> files in watir project. >> >> Watir project on github has a README.rdoc file as a landing page which >> is used to present the project and its 3 separate gems. >> Each library firewatir, watir, commonwatir has a README.rdoc specific >> to that library so each gem then has it's own readme. >> The main top level readme never makes it to the user's machine when >> they install the gems. >> If the user runs rdoc generation from the gems on their own machine >> they now have a local README for each one of the gems. >> The toplevel gem is visible on github as a landing page for the project. >> >> And that is why I thought there should be 4 README.rdoc files >> >> >> marekj >> >> http://rubytester.com >> >> >> >> >> On Fri, Oct 1, 2010 at 11:02 AM, marekj wrote: >>> Hi Guys, >>> Sorry for not being engaged over the last few months, I had to move >>> family from Dallas to Austin and have kids start new schools and so on >>> so not much time for fun. >>> >>> Please take a look here. >>> http://rubyforge.org/pipermail/wtr-development/2010-June/001863.html >>> the repo is here >>> http://github.com/marekj/watir/tree/rdocfix >>> the rdoc out of this repo is here >>> http://wtr.rubyforge.org/rdoc/1.6.5/ >>> >>> The main objective of this fix was to fix rdoc generation, make Readme >>> files presentable >>> and also make yardoc output. >>> >>> I see that some of this didn't make it to the main watir. >>> Can you still use some of the fixes I made? >>> >>> >>> >>> >>> marekj >>> >>> http://rubytester.com >>> >>> >>> >>> >>> On Fri, Oct 1, 2010 at 4:42 AM, Alister Scott wrote: >>>> Wow! Thanks for updating watir.com/examples so quickly. >>>> I think it's looking good. Thanks for all your work on this ?eljko! >>>> >>>> Cheers, >>>> >>>> Alister >>>> >>>> >>>> On Fri, Oct 1, 2010 at 7:20 PM, ?eljko Filipin >>>> wrote: >>>>> >>>>> On Thu, Sep 30, 2010 at 10:32 PM, Jarmo wrote: >>>>> > 1) There is only FireWatir examples. >>>>> >>>>> Good point. I will make separate require statements for each supported >>>>> gem. >>>>> >>>>> > 2) Maybe use hashrocket in locating elements instead of "old" >>>>> > comma-style? >>>>> >>>>> I did not know that => is called hashrocket :) >>>>> >>>>> I was thinking about updating docs to use hashrocket syntax but never had >>>>> the time. >>>>> >>>>> I have: >>>>> >>>>> - updated both README file and http://watir.com/examples/ >>>>> - renamed "b" variable to "browser" to make it clear to the new people >>>>> where it points to >>>>> - removed "full code" section from examples page to make it easier to >>>>> update the code, so I do not have to do it three times (already doing it two >>>>> times, README file and Examples page) >>>>> - removed "Starting a new browser at our site directly" section, I do not >>>>> think it is so important that it should be included in the basic examples >>>>> - added all watir gems (stable and experimental) to README >>>>> >>>>> Please let me know if you disagree with my changes. >>>>> >>>>> More information: >>>>> >>>>> http://github.com/bret/watir/pull/8 >>>>> From bret at pettichord.com Fri Oct 1 19:54:15 2010 From: bret at pettichord.com (Bret Pettichord) Date: Fri, 1 Oct 2010 18:54:15 -0500 Subject: [Wtr-development] README file to github!? In-Reply-To: References: Message-ID: I've updated master so that all the gems now use the one readme. I will also make these changes to the 1.6.6 release branch. Bret On Fri, Oct 1, 2010 at 1:59 PM, marekj wrote: > On Fri, Oct 1, 2010 at 1:41 PM, Jarmo wrote: > > That's just not true. It might be the case at the moment, but i have a > > plan to fix that. In my mind there should be still 1 README on github > > and when gems are being made then that same README should be copied > > into 3 gems. So every gem would have the same README. I don't see much > > of a point of having different readme-s > > Thanks Jarmo, now I know what you mean to have one README as a > template. I had not thought of that. > > > though since the API should be > > same anyway (i know it currently isn't 100%, but that shouldn't be in > > the readme anyway). > > > > As you can see then currently on the github isn't any VERSION or > > CHANGES in commonwatir, watir or firewatir directory, but they're > > still there when you install gems. Same plan goes to README. > > > > Jarmo > > > > On Fri, Oct 1, 2010 at 7:33 PM, marekj wrote: > >> I wanted to explain and defend my view of why there are 4 README.rdoc > >> files in watir project. > >> > >> Watir project on github has a README.rdoc file as a landing page which > >> is used to present the project and its 3 separate gems. > >> Each library firewatir, watir, commonwatir has a README.rdoc specific > >> to that library so each gem then has it's own readme. > >> The main top level readme never makes it to the user's machine when > >> they install the gems. > >> If the user runs rdoc generation from the gems on their own machine > >> they now have a local README for each one of the gems. > >> The toplevel gem is visible on github as a landing page for the project. > >> > >> And that is why I thought there should be 4 README.rdoc files > >> > >> > >> marekj > >> > >> http://rubytester.com > >> > >> > >> > >> > >> On Fri, Oct 1, 2010 at 11:02 AM, marekj wrote: > >>> Hi Guys, > >>> Sorry for not being engaged over the last few months, I had to move > >>> family from Dallas to Austin and have kids start new schools and so on > >>> so not much time for fun. > >>> > >>> Please take a look here. > >>> http://rubyforge.org/pipermail/wtr-development/2010-June/001863.html > >>> the repo is here > >>> http://github.com/marekj/watir/tree/rdocfix > >>> the rdoc out of this repo is here > >>> http://wtr.rubyforge.org/rdoc/1.6.5/ > >>> > >>> The main objective of this fix was to fix rdoc generation, make Readme > >>> files presentable > >>> and also make yardoc output. > >>> > >>> I see that some of this didn't make it to the main watir. > >>> Can you still use some of the fixes I made? > >>> > >>> > >>> > >>> > >>> marekj > >>> > >>> http://rubytester.com > >>> > >>> > >>> > >>> > >>> On Fri, Oct 1, 2010 at 4:42 AM, Alister Scott > wrote: > >>>> Wow! Thanks for updating watir.com/examples so quickly. > >>>> I think it's looking good. Thanks for all your work on this ?eljko! > >>>> > >>>> Cheers, > >>>> > >>>> Alister > >>>> > >>>> > >>>> On Fri, Oct 1, 2010 at 7:20 PM, ?eljko Filipin > >>>> wrote: > >>>>> > >>>>> On Thu, Sep 30, 2010 at 10:32 PM, Jarmo wrote: > >>>>> > 1) There is only FireWatir examples. > >>>>> > >>>>> Good point. I will make separate require statements for each > supported > >>>>> gem. > >>>>> > >>>>> > 2) Maybe use hashrocket in locating elements instead of "old" > >>>>> > comma-style? > >>>>> > >>>>> I did not know that => is called hashrocket :) > >>>>> > >>>>> I was thinking about updating docs to use hashrocket syntax but never > had > >>>>> the time. > >>>>> > >>>>> I have: > >>>>> > >>>>> - updated both README file and http://watir.com/examples/ > >>>>> - renamed "b" variable to "browser" to make it clear to the new > people > >>>>> where it points to > >>>>> - removed "full code" section from examples page to make it easier to > >>>>> update the code, so I do not have to do it three times (already doing > it two > >>>>> times, README file and Examples page) > >>>>> - removed "Starting a new browser at our site directly" section, I do > not > >>>>> think it is so important that it should be included in the basic > examples > >>>>> - added all watir gems (stable and experimental) to README > >>>>> > >>>>> Please let me know if you disagree with my changes. > >>>>> > >>>>> More information: > >>>>> > >>>>> http://github.com/bret/watir/pull/8 > >>>>> > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From abaird at bairdsnet.net Fri Oct 1 22:52:56 2010 From: abaird at bairdsnet.net (Alan Baird) Date: Fri, 1 Oct 2010 21:52:56 -0500 Subject: [Wtr-development] element.to_s instead of element.show In-Reply-To: References: Message-ID: >The show methods were quite handy before there were tools like firebug. Now I never use them any more. Does any one? I don't use the show methods, but the .to_s methods come in handy. Here is my use case. Suppose you need to get some specific divs and you do something like: important_divs = @br.divs.select{|div| div.class_name[/important_div_regexp/]} Now, if I'm in irb, I might test this out to see if the important_divs are really the ones I'm looking for, and the implementation of .to_s currently lists the id and other important attributes. It's not clear in your proposal if this would stop working like this and instead I would get the normal ruby class name syntax. If this is the case, this would be less functional and would cause me to do more work to iterate through important_divs to check them out and see if they were what I wanted. IE Dev toolbar and Firefox don't help here because I'm using it to debug my program in irb. We don't have to do any work to keep the .to_s methods do we? If not, why should we remove them if they are useful for some and not harmful to others? Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Sat Oct 2 04:04:31 2010 From: jarmo.p at gmail.com (Jarmo) Date: Sat, 2 Oct 2010 11:04:31 +0300 Subject: [Wtr-development] Watir 1.6.6.rc2 is up and ready for testing In-Reply-To: References: Message-ID: Pretty good. I guess we can say that it's IE9 compatible? :) On Fri, Oct 1, 2010 at 3:30 PM, Alister Scott wrote: > I ran unit tests on watir 1.6.6rc2 on Win 7 IE9 and got the following: > > Finished in 64.603 seconds. > > ? 1) Error: > test_status_returns_window_status(TC_Browser): > WIN32OLERuntimeError: statusText > ??? OLE error code:80004005 in > ????? > ??? HRESULT error code:0x80020009 > ????? Exception occurred. > > C:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.6.rc2/lib/watir/ie-class.rb:343:in > `method_missing' > > C:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.6.rc2/lib/watir/ie-class.rb:343:in > `status' > > C:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.6.rc2/unittests/browser_test. > rb:13:in `test_status_returns_window_status' > > ? 2) Failure: > test_form_outer_html(TC_Forms2) [./unittests/../unittests/form_test.rb:53]: > <"action=pass2.html id=f2 method=get name=test2>
value=sub > mit"> expected but was > <"action=pass2.html id=f2 method=get name=test2>
type=submi > t value=submit">. > > 311 tests, 1466 assertions, 1 failures, 1 errors > rake aborted! > Command failed with status (1): [c:/ruby/bin/ruby.exe -I"lib" > "c:/ruby/lib/...] > > (See full trace by running task with --trace) > > 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 Fri, Oct 1, 2010 at 8:55 PM, ?eljko Filipin > wrote: >> >> On Thu, Sep 30, 2010 at 5:09 PM, Charley Baker >> wrote: >> > ?We are happy to announce that a (very) long-waited (Fire)Watir >> > 1.6.6.rc2 is out! >> >> C:\watir\firewatir>rake test >> (...) >> 318 tests, 1679 assertions, 1 failures, 2 errors >> >> Failed tests are our old friends "attach to new window". >> >> >> >> C:\watir\watir>rake test >> (...) >> 311 tests, 1467 assertions, 0 failures, 0 errors >> >> ?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 > From jarmo.p at gmail.com Sat Oct 2 04:07:38 2010 From: jarmo.p at gmail.com (Jarmo) Date: Sat, 2 Oct 2010 11:07:38 +0300 Subject: [Wtr-development] source cleanup In-Reply-To: References: Message-ID: I agree on everything with Bret. I don't see any point of moving watir-simple to contrib. We'll just mention in the CHANGES that it got deleted and if anyone is using it then they can grab it from some old gem or from git. Jarmo On Fri, Oct 1, 2010 at 8:46 PM, Bret Pettichord wrote: > > > On Fri, Oct 1, 2010 at 10:08 AM, ?eljko Filipin > wrote: >> >> I guess I will have a few questions related to source cleanup, so I have >> decided to start a new thread: >> >> 1) We have licenses all over the place: >> >> http://github.com/bret/watir/blob/master/watir/lib/watir/ie.rb >> http://github.com/bret/watir/blob/master/firewatir/LICENSE >> http://github.com/bret/watir/blob/master/commonwatir/LICENSE >> http://github.com/bret/watir/blob/master/watir/lib/license.rb >> http://github.com/bret/watir/blob/master/watir/lib/watir/winClicker.rb >> >> Should I move it to LICENSE file located in root? > > Makes sense. > >> 2) Should we delete installer folder? >> >> http://github.com/bret/watir/tree/1.6.5.rc2/watir/installer/ > > Yes > > >> >> 3) Should we delete watir-simple? >> >> http://github.com/bret/watir/blob/master/watir/lib/watir/watir_simple.rb > > Yes > >> >> 4) Should we delete these files: >> >> http://github.com/bret/watir/blob/master//.project >> http://github.com/bret/watir/blob/master//transform-results.xsl >> http://github.com/bret/watir/blob/master/commonwatir/.project >> http://github.com/bret/watir/blob/master/firewatir/.loadpath >> http://github.com/bret/watir/blob/master/firewatir/.project >> http://github.com/bret/watir/blob/master/watir/.project >> http://github.com/bret/watir/blob/master/watir/unittests/.cvsignore > > Yes. > > The transform result was used for the CI results. I don't think there are > any plans to resuscitate this. > >> >> 5) Looks like these files need to be updated: >> >> http://github.com/bret/watir/blob/master/watir/building_watir.txt >> http://github.com/bret/watir/blob/master/watir/install_dev_gems.bat >> http://github.com/bret/watir/blob/master/watir/watir_release.txt >> >> I could do everything except 5) >> >> ?eljko >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From jarmo.p at gmail.com Sat Oct 2 05:29:55 2010 From: jarmo.p at gmail.com (Jarmo) Date: Sat, 2 Oct 2010 12:29:55 +0300 Subject: [Wtr-development] source cleanup In-Reply-To: References: Message-ID: I forgot to mention that if we want to deal with these license problems properly then it's not as easy as asking from just license holders since we have there 2 types of licenses - BSD and MIT. That means that we cannot just delete one of those and use only one and we cannot multi-license just like that either. To do it properly we'd have to ask from any contributor so far for their permission and if we can't get hold of some or cannot get permission then we'd have to delete their contribution and rewrite it with our own code. That would be a proper way to handle this kind of situations unfortunately. I'm not sure if it's done in real life like that with real projects. I've heard that they did something like that with Mozilla project a while ago (e.g. deleted some parts of the code and rewrote these due to being unable to contact all contributors). Just FYI. Jarmo On Sat, Oct 2, 2010 at 11:07 AM, Jarmo wrote: > I agree on everything with Bret. I don't see any point of moving > watir-simple to contrib. We'll just mention in the CHANGES that it got > deleted and if anyone is using it then they can grab it from some old > gem or from git. > > Jarmo > > On Fri, Oct 1, 2010 at 8:46 PM, Bret Pettichord wrote: >> >> >> On Fri, Oct 1, 2010 at 10:08 AM, ?eljko Filipin >> wrote: >>> >>> I guess I will have a few questions related to source cleanup, so I have >>> decided to start a new thread: >>> >>> 1) We have licenses all over the place: >>> >>> http://github.com/bret/watir/blob/master/watir/lib/watir/ie.rb >>> http://github.com/bret/watir/blob/master/firewatir/LICENSE >>> http://github.com/bret/watir/blob/master/commonwatir/LICENSE >>> http://github.com/bret/watir/blob/master/watir/lib/license.rb >>> http://github.com/bret/watir/blob/master/watir/lib/watir/winClicker.rb >>> >>> Should I move it to LICENSE file located in root? >> >> Makes sense. >> >>> 2) Should we delete installer folder? >>> >>> http://github.com/bret/watir/tree/1.6.5.rc2/watir/installer/ >> >> Yes >> >> >>> >>> 3) Should we delete watir-simple? >>> >>> http://github.com/bret/watir/blob/master/watir/lib/watir/watir_simple.rb >> >> Yes >> >>> >>> 4) Should we delete these files: >>> >>> http://github.com/bret/watir/blob/master//.project >>> http://github.com/bret/watir/blob/master//transform-results.xsl >>> http://github.com/bret/watir/blob/master/commonwatir/.project >>> http://github.com/bret/watir/blob/master/firewatir/.loadpath >>> http://github.com/bret/watir/blob/master/firewatir/.project >>> http://github.com/bret/watir/blob/master/watir/.project >>> http://github.com/bret/watir/blob/master/watir/unittests/.cvsignore >> >> Yes. >> >> The transform result was used for the CI results. I don't think there are >> any plans to resuscitate this. >> >>> >>> 5) Looks like these files need to be updated: >>> >>> http://github.com/bret/watir/blob/master/watir/building_watir.txt >>> http://github.com/bret/watir/blob/master/watir/install_dev_gems.bat >>> http://github.com/bret/watir/blob/master/watir/watir_release.txt >>> >>> I could do everything except 5) >>> >>> ?eljko >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >> >> >> >> -- >> Bret Pettichord >> Lead Developer, Watir, www.watir.com >> >> Blog, www.io.com/~wazmo/blog >> Twitter, www.twitter.com/bpettichord >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > From charley.baker at gmail.com Sat Oct 2 11:10:38 2010 From: charley.baker at gmail.com (Charley Baker) Date: Sat, 2 Oct 2010 09:10:38 -0600 Subject: [Wtr-development] Watir 1.6.6.rc2 is up and ready for testing In-Reply-To: References: Message-ID: Interesting. Unfortunately the only machine I have access to is my VM with XP and IE8. That blasted form test. :) Jarmo just fixed the ordering since the previous hard coded comparison didn't work with IE 8 and was brittle. It looks like IE9 stuffs in an empty style attribute for some odd reason. Not a big deal but somewhat annoying. The other error is a little more disconcerting. IE9 doesn't have a statusText method? I tried searching msdn to no avail. It's not a show stopper for this release but I would like to figure out what's happening for the next release. Thanks for the results Alistair. Charley Baker Lead Developer, Watir, http://watir.com On Sat, Oct 2, 2010 at 2:04 AM, Jarmo wrote: > Pretty good. I guess we can say that it's IE9 compatible? :) > > On Fri, Oct 1, 2010 at 3:30 PM, Alister Scott wrote: >> I ran unit tests on watir 1.6.6rc2 on Win 7 IE9 and got the following: >> >> Finished in 64.603 seconds. >> >> ? 1) Error: >> test_status_returns_window_status(TC_Browser): >> WIN32OLERuntimeError: statusText >> ??? OLE error code:80004005 in >> ????? >> ??? HRESULT error code:0x80020009 >> ????? Exception occurred. >> >> C:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.6.rc2/lib/watir/ie-class.rb:343:in >> `method_missing' >> >> C:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.6.rc2/lib/watir/ie-class.rb:343:in >> `status' >> >> C:/ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.6.rc2/unittests/browser_test. >> rb:13:in `test_status_returns_window_status' >> >> ? 2) Failure: >> test_form_outer_html(TC_Forms2) [./unittests/../unittests/form_test.rb:53]: >> <"action=pass2.html id=f2 method=get name=test2>
> value=sub >> mit"> expected but was >> <"action=pass2.html id=f2 method=get name=test2>
> type=submi >> t value=submit">. >> >> 311 tests, 1466 assertions, 1 failures, 1 errors >> rake aborted! >> Command failed with status (1): [c:/ruby/bin/ruby.exe -I"lib" >> "c:/ruby/lib/...] >> >> (See full trace by running task with --trace) >> >> 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 Fri, Oct 1, 2010 at 8:55 PM, ?eljko Filipin >> wrote: >>> >>> On Thu, Sep 30, 2010 at 5:09 PM, Charley Baker >>> wrote: >>> > ?We are happy to announce that a (very) long-waited (Fire)Watir >>> > 1.6.6.rc2 is out! >>> >>> C:\watir\firewatir>rake test >>> (...) >>> 318 tests, 1679 assertions, 1 failures, 2 errors >>> >>> Failed tests are our old friends "attach to new window". >>> >>> >>> >>> C:\watir\watir>rake test >>> (...) >>> 311 tests, 1467 assertions, 0 failures, 0 errors >>> >>> ?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 >> > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development From charley.baker at gmail.com Sat Oct 2 11:22:02 2010 From: charley.baker at gmail.com (Charley Baker) Date: Sat, 2 Oct 2010 09:22:02 -0600 Subject: [Wtr-development] README file to github!? In-Reply-To: References: Message-ID: Once you make these changes to the release branch and update CHANGES, I vote we release 1.6.6 final and start working on 1.6.7. All in favor? Let me know if you want me to merge it. Charley Baker Lead Developer, Watir, http://watir.com 2010/10/1 Bret Pettichord : > I've updated master so that all the gems now use the one readme. > > I will also make these changes to the 1.6.6 release branch. > > Bret > > On Fri, Oct 1, 2010 at 1:59 PM, marekj wrote: >> >> On Fri, Oct 1, 2010 at 1:41 PM, Jarmo wrote: >> > That's just not true. It might be the case at the moment, but i have a >> > plan to fix that. In my mind there should be still 1 README on github >> > and when gems are being made then that same README should be copied >> > into 3 gems. So every gem would have the same README. I don't see much >> > of a point of having different readme-s >> >> Thanks Jarmo, now I know what you mean to have one README as a >> template. I had not thought of that. >> >> > though since the API should be >> > same anyway (i know it currently isn't 100%, but that shouldn't be in >> > the readme anyway). >> > >> > As you can see then currently on the github isn't any VERSION or >> > CHANGES in commonwatir, watir or firewatir directory, but they're >> > still there when you install gems. Same plan goes to README. >> > >> > Jarmo >> > >> > On Fri, Oct 1, 2010 at 7:33 PM, marekj wrote: >> >> I wanted to explain and defend my view of why there are 4 README.rdoc >> >> files in watir project. >> >> >> >> Watir project on github has a README.rdoc file as a landing page which >> >> is used to present the project and its 3 separate gems. >> >> Each library firewatir, watir, commonwatir has a README.rdoc specific >> >> to that library so each gem then has it's own readme. >> >> The main top level readme never makes it to the user's machine when >> >> they install the gems. >> >> If the user runs rdoc generation from the gems on their own machine >> >> they now have a local README for each one of the gems. >> >> The toplevel gem is visible on github as a landing page for the >> >> project. >> >> >> >> And that is why I thought there should be 4 README.rdoc files >> >> >> >> >> >> marekj >> >> >> >> http://rubytester.com >> >> >> >> >> >> >> >> >> >> On Fri, Oct 1, 2010 at 11:02 AM, marekj wrote: >> >>> Hi Guys, >> >>> Sorry for not being engaged over the last few months, I had to move >> >>> family from Dallas to Austin and have kids start new schools and so on >> >>> so not much time for fun. >> >>> >> >>> Please take a look here. >> >>> http://rubyforge.org/pipermail/wtr-development/2010-June/001863.html >> >>> the repo is here >> >>> http://github.com/marekj/watir/tree/rdocfix >> >>> the rdoc out of this repo is here >> >>> http://wtr.rubyforge.org/rdoc/1.6.5/ >> >>> >> >>> The main objective of this fix was to fix rdoc generation, make Readme >> >>> files presentable >> >>> and also make yardoc output. >> >>> >> >>> I see that some of this didn't make it to the main watir. >> >>> Can you still use some of the fixes I made? >> >>> >> >>> >> >>> >> >>> >> >>> marekj >> >>> >> >>> http://rubytester.com >> >>> >> >>> >> >>> >> >>> >> >>> On Fri, Oct 1, 2010 at 4:42 AM, Alister Scott >> >>> wrote: >> >>>> Wow! Thanks for updating watir.com/examples so quickly. >> >>>> I think it's looking good. Thanks for all your work on this ?eljko! >> >>>> >> >>>> Cheers, >> >>>> >> >>>> Alister >> >>>> >> >>>> >> >>>> On Fri, Oct 1, 2010 at 7:20 PM, ?eljko Filipin >> >>>> wrote: >> >>>>> >> >>>>> On Thu, Sep 30, 2010 at 10:32 PM, Jarmo wrote: >> >>>>> > 1) There is only FireWatir examples. >> >>>>> >> >>>>> Good point. I will make separate require statements for each >> >>>>> supported >> >>>>> gem. >> >>>>> >> >>>>> > 2) Maybe use hashrocket in locating elements instead of "old" >> >>>>> > comma-style? >> >>>>> >> >>>>> I did not know that => is called hashrocket :) >> >>>>> >> >>>>> I was thinking about updating docs to use hashrocket syntax but >> >>>>> never had >> >>>>> the time. >> >>>>> >> >>>>> I have: >> >>>>> >> >>>>> - updated both README file and http://watir.com/examples/ >> >>>>> - renamed "b" variable to "browser" to make it clear to the new >> >>>>> people >> >>>>> where it points to >> >>>>> - removed "full code" section from examples page to make it easier >> >>>>> to >> >>>>> update the code, so I do not have to do it three times (already >> >>>>> doing it two >> >>>>> times, README file and Examples page) >> >>>>> - removed "Starting a new browser at our site directly" section, I >> >>>>> do not >> >>>>> think it is so important that it should be included in the basic >> >>>>> examples >> >>>>> - added all watir gems (stable and experimental) to README >> >>>>> >> >>>>> Please let me know if you disagree with my changes. >> >>>>> >> >>>>> More information: >> >>>>> >> >>>>> http://github.com/bret/watir/pull/8 >> >>>>> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From bret at pettichord.com Sat Oct 2 13:39:13 2010 From: bret at pettichord.com (Bret Pettichord) Date: Sat, 2 Oct 2010 12:39:13 -0500 Subject: [Wtr-development] source cleanup In-Reply-To: References: Message-ID: I think I can help simplify the license situation. But not right now. Bret On Sat, Oct 2, 2010 at 4:29 AM, Jarmo wrote: > I forgot to mention that if we want to deal with these license > problems properly then it's not as easy as asking from just license > holders since we have there 2 types of licenses - BSD and MIT. That > means that we cannot just delete one of those and use only one and we > cannot multi-license just like that either. To do it properly we'd > have to ask from any contributor so far for their permission and if we > can't get hold of some or cannot get permission then we'd have to > delete their contribution and rewrite it with our own code. That would > be a proper way to handle this kind of situations unfortunately. I'm > not sure if it's done in real life like that with real projects. I've > heard that they did something like that with Mozilla project a while > ago (e.g. deleted some parts of the code and rewrote these due to > being unable to contact all contributors). > > Just FYI. > > Jarmo > > On Sat, Oct 2, 2010 at 11:07 AM, Jarmo wrote: > > I agree on everything with Bret. I don't see any point of moving > > watir-simple to contrib. We'll just mention in the CHANGES that it got > > deleted and if anyone is using it then they can grab it from some old > > gem or from git. > > > > Jarmo > > > > On Fri, Oct 1, 2010 at 8:46 PM, Bret Pettichord > wrote: > >> > >> > >> On Fri, Oct 1, 2010 at 10:08 AM, ?eljko Filipin > >> wrote: > >>> > >>> I guess I will have a few questions related to source cleanup, so I > have > >>> decided to start a new thread: > >>> > >>> 1) We have licenses all over the place: > >>> > >>> http://github.com/bret/watir/blob/master/watir/lib/watir/ie.rb > >>> http://github.com/bret/watir/blob/master/firewatir/LICENSE > >>> http://github.com/bret/watir/blob/master/commonwatir/LICENSE > >>> http://github.com/bret/watir/blob/master/watir/lib/license.rb > >>> http://github.com/bret/watir/blob/master/watir/lib/watir/winClicker.rb > >>> > >>> Should I move it to LICENSE file located in root? > >> > >> Makes sense. > >> > >>> 2) Should we delete installer folder? > >>> > >>> http://github.com/bret/watir/tree/1.6.5.rc2/watir/installer/ > >> > >> Yes > >> > >> > >>> > >>> 3) Should we delete watir-simple? > >>> > >>> > http://github.com/bret/watir/blob/master/watir/lib/watir/watir_simple.rb > >> > >> Yes > >> > >>> > >>> 4) Should we delete these files: > >>> > >>> http://github.com/bret/watir/blob/master//.project > >>> http://github.com/bret/watir/blob/master//transform-results.xsl > >>> http://github.com/bret/watir/blob/master/commonwatir/.project > >>> http://github.com/bret/watir/blob/master/firewatir/.loadpath > >>> http://github.com/bret/watir/blob/master/firewatir/.project > >>> http://github.com/bret/watir/blob/master/watir/.project > >>> http://github.com/bret/watir/blob/master/watir/unittests/.cvsignore > >> > >> Yes. > >> > >> The transform result was used for the CI results. I don't think there > are > >> any plans to resuscitate this. > >> > >>> > >>> 5) Looks like these files need to be updated: > >>> > >>> http://github.com/bret/watir/blob/master/watir/building_watir.txt > >>> http://github.com/bret/watir/blob/master/watir/install_dev_gems.bat > >>> http://github.com/bret/watir/blob/master/watir/watir_release.txt > >>> > >>> I could do everything except 5) > >>> > >>> ?eljko > >>> > >>> _______________________________________________ > >>> Wtr-development mailing list > >>> Wtr-development at rubyforge.org > >>> http://rubyforge.org/mailman/listinfo/wtr-development > >> > >> > >> > >> -- > >> Bret Pettichord > >> Lead Developer, Watir, www.watir.com > >> > >> Blog, www.io.com/~wazmo/blog > >> Twitter, www.twitter.com/bpettichord > >> > >> > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Sat Oct 2 13:40:36 2010 From: bret at pettichord.com (Bret Pettichord) Date: Sat, 2 Oct 2010 12:40:36 -0500 Subject: [Wtr-development] README file to github!? In-Reply-To: References: Message-ID: It's a beautiful day out today, so I'm going to take care of some yard work and assemble my new grill. I'll merge it after that. Or you can do it now. Bret On Sat, Oct 2, 2010 at 10:22 AM, Charley Baker wrote: > Once you make these changes to the release branch and update CHANGES, > I vote we release 1.6.6 final and start working on 1.6.7. All in > favor? Let me know if you want me to merge it. > > > Charley Baker > Lead Developer, Watir, http://watir.com > > > > 2010/10/1 Bret Pettichord : > > I've updated master so that all the gems now use the one readme. > > > > I will also make these changes to the 1.6.6 release branch. > > > > Bret > > > > On Fri, Oct 1, 2010 at 1:59 PM, marekj wrote: > >> > >> On Fri, Oct 1, 2010 at 1:41 PM, Jarmo wrote: > >> > That's just not true. It might be the case at the moment, but i have a > >> > plan to fix that. In my mind there should be still 1 README on github > >> > and when gems are being made then that same README should be copied > >> > into 3 gems. So every gem would have the same README. I don't see much > >> > of a point of having different readme-s > >> > >> Thanks Jarmo, now I know what you mean to have one README as a > >> template. I had not thought of that. > >> > >> > though since the API should be > >> > same anyway (i know it currently isn't 100%, but that shouldn't be in > >> > the readme anyway). > >> > > >> > As you can see then currently on the github isn't any VERSION or > >> > CHANGES in commonwatir, watir or firewatir directory, but they're > >> > still there when you install gems. Same plan goes to README. > >> > > >> > Jarmo > >> > > >> > On Fri, Oct 1, 2010 at 7:33 PM, marekj wrote: > >> >> I wanted to explain and defend my view of why there are 4 README.rdoc > >> >> files in watir project. > >> >> > >> >> Watir project on github has a README.rdoc file as a landing page > which > >> >> is used to present the project and its 3 separate gems. > >> >> Each library firewatir, watir, commonwatir has a README.rdoc specific > >> >> to that library so each gem then has it's own readme. > >> >> The main top level readme never makes it to the user's machine when > >> >> they install the gems. > >> >> If the user runs rdoc generation from the gems on their own machine > >> >> they now have a local README for each one of the gems. > >> >> The toplevel gem is visible on github as a landing page for the > >> >> project. > >> >> > >> >> And that is why I thought there should be 4 README.rdoc files > >> >> > >> >> > >> >> marekj > >> >> > >> >> http://rubytester.com > >> >> > >> >> > >> >> > >> >> > >> >> On Fri, Oct 1, 2010 at 11:02 AM, marekj > wrote: > >> >>> Hi Guys, > >> >>> Sorry for not being engaged over the last few months, I had to move > >> >>> family from Dallas to Austin and have kids start new schools and so > on > >> >>> so not much time for fun. > >> >>> > >> >>> Please take a look here. > >> >>> > http://rubyforge.org/pipermail/wtr-development/2010-June/001863.html > >> >>> the repo is here > >> >>> http://github.com/marekj/watir/tree/rdocfix > >> >>> the rdoc out of this repo is here > >> >>> http://wtr.rubyforge.org/rdoc/1.6.5/ > >> >>> > >> >>> The main objective of this fix was to fix rdoc generation, make > Readme > >> >>> files presentable > >> >>> and also make yardoc output. > >> >>> > >> >>> I see that some of this didn't make it to the main watir. > >> >>> Can you still use some of the fixes I made? > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> marekj > >> >>> > >> >>> http://rubytester.com > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> On Fri, Oct 1, 2010 at 4:42 AM, Alister Scott > >> >>> wrote: > >> >>>> Wow! Thanks for updating watir.com/examples so quickly. > >> >>>> I think it's looking good. Thanks for all your work on this ?eljko! > >> >>>> > >> >>>> Cheers, > >> >>>> > >> >>>> Alister > >> >>>> > >> >>>> > >> >>>> On Fri, Oct 1, 2010 at 7:20 PM, ?eljko Filipin > >> >>>> wrote: > >> >>>>> > >> >>>>> On Thu, Sep 30, 2010 at 10:32 PM, Jarmo > wrote: > >> >>>>> > 1) There is only FireWatir examples. > >> >>>>> > >> >>>>> Good point. I will make separate require statements for each > >> >>>>> supported > >> >>>>> gem. > >> >>>>> > >> >>>>> > 2) Maybe use hashrocket in locating elements instead of "old" > >> >>>>> > comma-style? > >> >>>>> > >> >>>>> I did not know that => is called hashrocket :) > >> >>>>> > >> >>>>> I was thinking about updating docs to use hashrocket syntax but > >> >>>>> never had > >> >>>>> the time. > >> >>>>> > >> >>>>> I have: > >> >>>>> > >> >>>>> - updated both README file and http://watir.com/examples/ > >> >>>>> - renamed "b" variable to "browser" to make it clear to the new > >> >>>>> people > >> >>>>> where it points to > >> >>>>> - removed "full code" section from examples page to make it easier > >> >>>>> to > >> >>>>> update the code, so I do not have to do it three times (already > >> >>>>> doing it two > >> >>>>> times, README file and Examples page) > >> >>>>> - removed "Starting a new browser at our site directly" section, I > >> >>>>> do not > >> >>>>> think it is so important that it should be included in the basic > >> >>>>> examples > >> >>>>> - added all watir gems (stable and experimental) to README > >> >>>>> > >> >>>>> Please let me know if you disagree with my changes. > >> >>>>> > >> >>>>> More information: > >> >>>>> > >> >>>>> http://github.com/bret/watir/pull/8 > >> >>>>> > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > > > -- > > Bret Pettichord > > Lead Developer, Watir, www.watir.com > > > > Blog, www.io.com/~wazmo/blog > > Twitter, www.twitter.com/bpettichord > > > > > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Sat Oct 2 13:43:29 2010 From: bret at pettichord.com (Bret Pettichord) Date: Sat, 2 Oct 2010 12:43:29 -0500 Subject: [Wtr-development] element.to_s instead of element.show In-Reply-To: References: Message-ID: Alan, What you are are really asking for is useful "inspect" methods. This is what IRB uses by default to display an object. I believe someone fairly recently cleaned these up. Could you take a look at them and let us know if these meet your needs? If not, I'd like to make them better. Bret On Fri, Oct 1, 2010 at 9:52 PM, Alan Baird wrote: > >The show methods were quite handy before there were tools like firebug. > Now I never use them any more. Does any one? > > I don't use the show methods, but the .to_s methods come in handy. Here is > my use case. Suppose you need to get some specific divs and you do > something like: > > important_divs = @br.divs.select{|div| > div.class_name[/important_div_regexp/]} > > Now, if I'm in irb, I might test this out to see if the important_divs are > really the ones I'm looking for, and the implementation of .to_s currently > lists the id and other important attributes. It's not clear in your > proposal if this would stop working like this and instead I would get the > normal ruby class name syntax. If this is the case, this would be less > functional and would cause me to do more work to iterate through > important_divs to check them out and see if they were what I wanted. IE Dev > toolbar and Firefox don't help here because I'm using it to debug my program > in irb. > > We don't have to do any work to keep the .to_s methods do we? If not, why > should we remove them if they are useful for some and not harmful to others? > > Alan > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Sat Oct 2 13:40:36 2010 From: bret at pettichord.com (Bret Pettichord) Date: Sat, 2 Oct 2010 12:40:36 -0500 Subject: [Wtr-development] README file to github!? In-Reply-To: References: Message-ID: It's a beautiful day out today, so I'm going to take care of some yard work and assemble my new grill. I'll merge it after that. Or you can do it now. Bret On Sat, Oct 2, 2010 at 10:22 AM, Charley Baker wrote: > Once you make these changes to the release branch and update CHANGES, > I vote we release 1.6.6 final and start working on 1.6.7. All in > favor? Let me know if you want me to merge it. > > > Charley Baker > Lead Developer, Watir, http://watir.com > > > > 2010/10/1 Bret Pettichord : > > I've updated master so that all the gems now use the one readme. > > > > I will also make these changes to the 1.6.6 release branch. > > > > Bret > > > > On Fri, Oct 1, 2010 at 1:59 PM, marekj wrote: > >> > >> On Fri, Oct 1, 2010 at 1:41 PM, Jarmo wrote: > >> > That's just not true. It might be the case at the moment, but i have a > >> > plan to fix that. In my mind there should be still 1 README on github > >> > and when gems are being made then that same README should be copied > >> > into 3 gems. So every gem would have the same README. I don't see much > >> > of a point of having different readme-s > >> > >> Thanks Jarmo, now I know what you mean to have one README as a > >> template. I had not thought of that. > >> > >> > though since the API should be > >> > same anyway (i know it currently isn't 100%, but that shouldn't be in > >> > the readme anyway). > >> > > >> > As you can see then currently on the github isn't any VERSION or > >> > CHANGES in commonwatir, watir or firewatir directory, but they're > >> > still there when you install gems. Same plan goes to README. > >> > > >> > Jarmo > >> > > >> > On Fri, Oct 1, 2010 at 7:33 PM, marekj wrote: > >> >> I wanted to explain and defend my view of why there are 4 README.rdoc > >> >> files in watir project. > >> >> > >> >> Watir project on github has a README.rdoc file as a landing page > which > >> >> is used to present the project and its 3 separate gems. > >> >> Each library firewatir, watir, commonwatir has a README.rdoc specific > >> >> to that library so each gem then has it's own readme. > >> >> The main top level readme never makes it to the user's machine when > >> >> they install the gems. > >> >> If the user runs rdoc generation from the gems on their own machine > >> >> they now have a local README for each one of the gems. > >> >> The toplevel gem is visible on github as a landing page for the > >> >> project. > >> >> > >> >> And that is why I thought there should be 4 README.rdoc files > >> >> > >> >> > >> >> marekj > >> >> > >> >> http://rubytester.com > >> >> > >> >> > >> >> > >> >> > >> >> On Fri, Oct 1, 2010 at 11:02 AM, marekj > wrote: > >> >>> Hi Guys, > >> >>> Sorry for not being engaged over the last few months, I had to move > >> >>> family from Dallas to Austin and have kids start new schools and so > on > >> >>> so not much time for fun. > >> >>> > >> >>> Please take a look here. > >> >>> > http://rubyforge.org/pipermail/wtr-development/2010-June/001863.html > >> >>> the repo is here > >> >>> http://github.com/marekj/watir/tree/rdocfix > >> >>> the rdoc out of this repo is here > >> >>> http://wtr.rubyforge.org/rdoc/1.6.5/ > >> >>> > >> >>> The main objective of this fix was to fix rdoc generation, make > Readme > >> >>> files presentable > >> >>> and also make yardoc output. > >> >>> > >> >>> I see that some of this didn't make it to the main watir. > >> >>> Can you still use some of the fixes I made? > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> marekj > >> >>> > >> >>> http://rubytester.com > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> On Fri, Oct 1, 2010 at 4:42 AM, Alister Scott > >> >>> wrote: > >> >>>> Wow! Thanks for updating watir.com/examples so quickly. > >> >>>> I think it's looking good. Thanks for all your work on this ?eljko! > >> >>>> > >> >>>> Cheers, > >> >>>> > >> >>>> Alister > >> >>>> > >> >>>> > >> >>>> On Fri, Oct 1, 2010 at 7:20 PM, ?eljko Filipin > >> >>>> wrote: > >> >>>>> > >> >>>>> On Thu, Sep 30, 2010 at 10:32 PM, Jarmo > wrote: > >> >>>>> > 1) There is only FireWatir examples. > >> >>>>> > >> >>>>> Good point. I will make separate require statements for each > >> >>>>> supported > >> >>>>> gem. > >> >>>>> > >> >>>>> > 2) Maybe use hashrocket in locating elements instead of "old" > >> >>>>> > comma-style? > >> >>>>> > >> >>>>> I did not know that => is called hashrocket :) > >> >>>>> > >> >>>>> I was thinking about updating docs to use hashrocket syntax but > >> >>>>> never had > >> >>>>> the time. > >> >>>>> > >> >>>>> I have: > >> >>>>> > >> >>>>> - updated both README file and http://watir.com/examples/ > >> >>>>> - renamed "b" variable to "browser" to make it clear to the new > >> >>>>> people > >> >>>>> where it points to > >> >>>>> - removed "full code" section from examples page to make it easier > >> >>>>> to > >> >>>>> update the code, so I do not have to do it three times (already > >> >>>>> doing it two > >> >>>>> times, README file and Examples page) > >> >>>>> - removed "Starting a new browser at our site directly" section, I > >> >>>>> do not > >> >>>>> think it is so important that it should be included in the basic > >> >>>>> examples > >> >>>>> - added all watir gems (stable and experimental) to README > >> >>>>> > >> >>>>> Please let me know if you disagree with my changes. > >> >>>>> > >> >>>>> More information: > >> >>>>> > >> >>>>> http://github.com/bret/watir/pull/8 > >> >>>>> > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > > > -- > > Bret Pettichord > > Lead Developer, Watir, www.watir.com > > > > Blog, www.io.com/~wazmo/blog > > Twitter, www.twitter.com/bpettichord > > > > > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From charley.baker at gmail.com Sat Oct 2 14:33:55 2010 From: charley.baker at gmail.com (Charley Baker) Date: Sat, 2 Oct 2010 12:33:55 -0600 Subject: [Wtr-development] README file to github!? In-Reply-To: References: Message-ID: Done. I cherrypicked the README change from master, updated VERSION and CHANGES. Releasing final 1.6.6 in a few if anyone can double check we're good to go. :) Charley Baker Lead Developer, Watir, http://watir.com On Sat, Oct 2, 2010 at 11:40 AM, Bret Pettichord wrote: > It's a beautiful day out today, so I'm going to take care of some yard work > and assemble my new grill. > > I'll merge it after that. Or you can do it now. > > Bret > > On Sat, Oct 2, 2010 at 10:22 AM, Charley Baker > wrote: >> >> Once you make these changes to the release branch and update CHANGES, >> I vote we release 1.6.6 final and start working on 1.6.7. All in >> favor? Let me know if you want me to merge it. >> >> >> Charley Baker >> Lead Developer, Watir, http://watir.com >> >> >> >> 2010/10/1 Bret Pettichord : >> > I've updated master so that all the gems now use the one readme. >> > >> > I will also make these changes to the 1.6.6 release branch. >> > >> > Bret >> > >> > On Fri, Oct 1, 2010 at 1:59 PM, marekj wrote: >> >> >> >> On Fri, Oct 1, 2010 at 1:41 PM, Jarmo wrote: >> >> > That's just not true. It might be the case at the moment, but i have >> >> > a >> >> > plan to fix that. In my mind there should be still 1 README on github >> >> > and when gems are being made then that same README should be copied >> >> > into 3 gems. So every gem would have the same README. I don't see >> >> > much >> >> > of a point of having different readme-s >> >> >> >> Thanks Jarmo, now I know what you mean to have one README as a >> >> template. I had not thought of that. >> >> >> >> > though since the API should be >> >> > same anyway (i know it currently isn't 100%, but that shouldn't be in >> >> > the readme anyway). >> >> > >> >> > As you can see then currently on the github isn't any VERSION or >> >> > CHANGES in commonwatir, watir or firewatir directory, but they're >> >> > still there when you install gems. Same plan goes to README. >> >> > >> >> > Jarmo >> >> > >> >> > On Fri, Oct 1, 2010 at 7:33 PM, marekj wrote: >> >> >> I wanted to explain and defend my view of why there are 4 >> >> >> README.rdoc >> >> >> files in watir project. >> >> >> >> >> >> Watir project on github has a README.rdoc file as a landing page >> >> >> which >> >> >> is used to present the project and its 3 separate gems. >> >> >> Each library firewatir, watir, commonwatir has a README.rdoc >> >> >> specific >> >> >> to that library so each gem then has it's own readme. >> >> >> The main top level readme never makes it to the user's machine when >> >> >> they install the gems. >> >> >> If the user runs rdoc generation from the gems on their own machine >> >> >> they now have a local README for each one of the gems. >> >> >> The toplevel gem is visible on github as a landing page for the >> >> >> project. >> >> >> >> >> >> And that is why I thought there should be 4 README.rdoc files >> >> >> >> >> >> >> >> >> marekj >> >> >> >> >> >> http://rubytester.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Oct 1, 2010 at 11:02 AM, marekj >> >> >> wrote: >> >> >>> Hi Guys, >> >> >>> Sorry for not being engaged over the last few months, I had to move >> >> >>> family from Dallas to Austin and have kids start new schools and so >> >> >>> on >> >> >>> so not much time for fun. >> >> >>> >> >> >>> Please take a look here. >> >> >>> >> >> >>> http://rubyforge.org/pipermail/wtr-development/2010-June/001863.html >> >> >>> the repo is here >> >> >>> http://github.com/marekj/watir/tree/rdocfix >> >> >>> the rdoc out of this repo is here >> >> >>> http://wtr.rubyforge.org/rdoc/1.6.5/ >> >> >>> >> >> >>> The main objective of this fix was to fix rdoc generation, make >> >> >>> Readme >> >> >>> files presentable >> >> >>> and also make yardoc output. >> >> >>> >> >> >>> I see that some of this didn't make it to the main watir. >> >> >>> Can you still use some of the fixes I made? >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> marekj >> >> >>> >> >> >>> http://rubytester.com >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> On Fri, Oct 1, 2010 at 4:42 AM, Alister Scott >> >> >>> wrote: >> >> >>>> Wow! Thanks for updating watir.com/examples so quickly. >> >> >>>> I think it's looking good. Thanks for all your work on this >> >> >>>> ?eljko! >> >> >>>> >> >> >>>> Cheers, >> >> >>>> >> >> >>>> Alister >> >> >>>> >> >> >>>> >> >> >>>> On Fri, Oct 1, 2010 at 7:20 PM, ?eljko Filipin >> >> >>>> wrote: >> >> >>>>> >> >> >>>>> On Thu, Sep 30, 2010 at 10:32 PM, Jarmo >> >> >>>>> wrote: >> >> >>>>> > 1) There is only FireWatir examples. >> >> >>>>> >> >> >>>>> Good point. I will make separate require statements for each >> >> >>>>> supported >> >> >>>>> gem. >> >> >>>>> >> >> >>>>> > 2) Maybe use hashrocket in locating elements instead of "old" >> >> >>>>> > comma-style? >> >> >>>>> >> >> >>>>> I did not know that => is called hashrocket :) >> >> >>>>> >> >> >>>>> I was thinking about updating docs to use hashrocket syntax but >> >> >>>>> never had >> >> >>>>> the time. >> >> >>>>> >> >> >>>>> I have: >> >> >>>>> >> >> >>>>> - updated both README file and http://watir.com/examples/ >> >> >>>>> - renamed "b" variable to "browser" to make it clear to the new >> >> >>>>> people >> >> >>>>> where it points to >> >> >>>>> - removed "full code" section from examples page to make it >> >> >>>>> easier >> >> >>>>> to >> >> >>>>> update the code, so I do not have to do it three times (already >> >> >>>>> doing it two >> >> >>>>> times, README file and Examples page) >> >> >>>>> - removed "Starting a new browser at our site directly" section, >> >> >>>>> I >> >> >>>>> do not >> >> >>>>> think it is so important that it should be included in the basic >> >> >>>>> examples >> >> >>>>> - added all watir gems (stable and experimental) to README >> >> >>>>> >> >> >>>>> Please let me know if you disagree with my changes. >> >> >>>>> >> >> >>>>> More information: >> >> >>>>> >> >> >>>>> http://github.com/bret/watir/pull/8 >> >> >>>>> >> >> _______________________________________________ >> >> Wtr-development mailing list >> >> Wtr-development at rubyforge.org >> >> http://rubyforge.org/mailman/listinfo/wtr-development >> > >> > >> > -- >> > Bret Pettichord >> > Lead Developer, Watir, www.watir.com >> > >> > Blog, www.io.com/~wazmo/blog >> > Twitter, www.twitter.com/bpettichord >> > >> > >> > _______________________________________________ >> > Wtr-development mailing list >> > Wtr-development at rubyforge.org >> > http://rubyforge.org/mailman/listinfo/wtr-development >> > >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From watirjira at gmail.com Sat Oct 2 14:44:31 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 13:44:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-403) JSSh documentation for Firefox Message-ID: <31842691.1046.1286045071263.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19861#action_19861 ] Charley Baker commented on WTR-403: ----------------------------------- Zeljko, any plans for resolving this? > JSSh documentation for Firefox > ------------------------------ > > Key: WTR-403 > URL: http://jira.openqa.org/browse/WTR-403 > Project: Watir > Issue Type: Bug > Components: FireWatir > Affects Versions: Open QA Migration > Environment: any > Reporter: Zeljko > > - moved from http://code.google.com/p/firewatir/issues/detail?id=85 > Issue 85: JSSh documentation for Firefox > 1 person starred this issue and may be notified of changes. > Status: New > Owner: ---- > Reported by mdhv1974, Jun 28, 2009 > What steps will reproduce the problem? > 1. Search web for JSSh documentation and it points to > http://www.croczilla.com/jssh. The link when clicked, always > returns "Resource not found" > Can anyone help with the said documents or provide a link? > Regards > Babu -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 14:46:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 13:46:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-409) install for 1.6.2 doesn't work after 1.6.5 release Message-ID: <13004280.1049.1286045190669.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19862#action_19862 ] Charley Baker commented on WTR-409: ----------------------------------- Any updates on this issue? Close? > install for 1.6.2 doesn't work after 1.6.5 release > -------------------------------------------------- > > Key: WTR-409 > URL: http://jira.openqa.org/browse/WTR-409 > Project: Watir > Issue Type: Bug > Components: Gem installer > Affects Versions: 1.6.2 > Environment: windows > Reporter: Alan Baird > Assignee: Charley Baker > Priority: Critical > Fix For: 1.6.3 > > > This morning I was helping a coworker get some things up and running with watir and noticed that he had inadvertently got 1.6.5. Since 1.6.5 changes the way .visible? works, we decided to go back to 1.6.2 and make sure everything was ok there. We removed watir, commonwatir and firewatir and verified that everything was uninstalled. After that, we did the following: > C:\ >gem install watir -v 1.6.2 > ERROR: Error installing watir: > firewatir requires commonwatir (= 1.6.5, runtime) > C:\ >gem list --local > *** LOCAL GEMS *** > (removed unnecessary gems) > ... > commonwatir (1.6.2) > ... > C:\ >gem install firewatir -v 1.6.2 > Successfully installed firewatir-1.6.2 > 1 gem installed > Installing ri documentation for firewatir-1.6.2... > Installing RDoc documentation for firewatir-1.6.2... > C:\ >gem install watir -v 1.6.2 > Successfully installed watir-1.6.2 > 1 gem installed > Installing ri documentation for watir-1.6.2... > Installing RDoc documentation for watir-1.6.2... > So, to me it seems that there is a gem dependency in the firewatir install for commonwatir 1.6.5 (or maybe it's just the latest version). > What do you think? > Alan > For complete discussion, see http://groups.google.com/group/watir-general/browse_thread/thread/ee8e1abadb533b61?tvc=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 14:51:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 13:51:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Resolved: (WTR-386) JRuby and firewatir Message-ID: <6156578.1051.1286045490721.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker resolved WTR-386. ------------------------------- Resolution: Fixed This should be fixed with Ian Dees commit. http://github.com/bret/watir/commit/9c7f58a37231cbb41d73dae32a24b438d2c7faa8 > JRuby and firewatir > ------------------- > > Key: WTR-386 > URL: http://jira.openqa.org/browse/WTR-386 > Project: Watir > Issue Type: Bug > Components: FireWatir > Affects Versions: Open QA Migration > Environment: jruby > Reporter: Zeljko > > - moved from http://code.google.com/p/firewatir/issues/detail?id=53 > Issue 53: JRuby and firewatir > 3 people starred this issue and may be notified of changes. > Status: New > Owner: ---- > Type-Defect > Priority-Medium > Reported by rstudner, Nov 10, 2007 > What steps will reproduce the problem? > 1. jruby -S gem install firewatir1.1.gem > There is an array index out of bounds error upon trying to do this. > JRuby + Firewatir would be a killer combo.. so i'm trying my best to get > this to work :) > --- > Comment 1 by angrez, Nov 11, 2007 > I'll try this and let you know -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 14:51:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 13:51:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-386) JRuby and firewatir Message-ID: <31254719.1053.1286045490764.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker closed WTR-386. ----------------------------- Fixed. > JRuby and firewatir > ------------------- > > Key: WTR-386 > URL: http://jira.openqa.org/browse/WTR-386 > Project: Watir > Issue Type: Bug > Components: FireWatir > Affects Versions: Open QA Migration > Environment: jruby > Reporter: Zeljko > > - moved from http://code.google.com/p/firewatir/issues/detail?id=53 > Issue 53: JRuby and firewatir > 3 people starred this issue and may be notified of changes. > Status: New > Owner: ---- > Type-Defect > Priority-Medium > Reported by rstudner, Nov 10, 2007 > What steps will reproduce the problem? > 1. jruby -S gem install firewatir1.1.gem > There is an array index out of bounds error upon trying to do this. > JRuby + Firewatir would be a killer combo.. so i'm trying my best to get > this to work :) > --- > Comment 1 by angrez, Nov 11, 2007 > I'll try this and let you know -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 15:04:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 14:04:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-225) Improve Popup Handling [patch] Message-ID: <13740658.1057.1286046270902.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker closed WTR-225. ----------------------------- Closing. > Improve Popup Handling [patch] > ------------------------------ > > Key: WTR-225 > URL: http://jira.openqa.org/browse/WTR-225 > Project: Watir > Issue Type: Bug > Affects Versions: 1.5.6 > Reporter: Bret Pettichord > Priority: Major > Fix For: 1.6.6 > > > Here is one way to make this work. This needs to be repackaged to make things easier for users. > Hi all! > I've just spent some time trying to figure out how to dismiss > javascript popups. The information is out there, but it took me a > while to get it all put together and then to try out the various > suggestions until I found one that worked for me. Just in case it > helps someone else, I'll summarize what I found as well as some things > I added here. > 1.) You need to update the winClicker.rb file in your watir directory > (in my case, it was at: c:\ruby\lib\ruby\gems\1.8\gems > \watir-1.5.3\watir). Change the dialog title from "Internet Explorer" > to "Windows Internet Explorer". I used the regex /Internet Explorer/ > so that it will work no matter which version of IE I use. > 2.) Require 'watir/contrib/enabled_popup' for your tests. > 3.) Define the popupChecker method to watch for a popup and dismiss > it (in this case, by clicking the button with the specified text): > def popupChecker(text) > Timeout::timeout(2)do > begin > if $ie.enabled_popup > hwnd = $ie.enabled_popup(5) > w = WinClicker.new > w.makeWindowActive(hwnd) > w.clickWindowsButton_hwnd(hwnd, > text) > end > rescue Timeout::Error > puts 'No popup existed' > end > end > end > 4.) Use the click_no_wait method on the link or button that will > launch the popup. > ie.button(:text, 'Continue').click_no_wait > 5.) Call the popupChecker method in case a popup exists > popupChecker('OK') > I hope this helps! > -Tiffany -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 15:04:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 14:04:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Resolved: (WTR-225) Improve Popup Handling [patch] Message-ID: <28942892.1055.1286046270789.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker resolved WTR-225. ------------------------------- Resolution: Fixed Fix Version/s: (was: Soon) 1.6.6 This is well documented, closing. > Improve Popup Handling [patch] > ------------------------------ > > Key: WTR-225 > URL: http://jira.openqa.org/browse/WTR-225 > Project: Watir > Issue Type: Bug > Affects Versions: 1.5.6 > Reporter: Bret Pettichord > Priority: Major > Fix For: 1.6.6 > > > Here is one way to make this work. This needs to be repackaged to make things easier for users. > Hi all! > I've just spent some time trying to figure out how to dismiss > javascript popups. The information is out there, but it took me a > while to get it all put together and then to try out the various > suggestions until I found one that worked for me. Just in case it > helps someone else, I'll summarize what I found as well as some things > I added here. > 1.) You need to update the winClicker.rb file in your watir directory > (in my case, it was at: c:\ruby\lib\ruby\gems\1.8\gems > \watir-1.5.3\watir). Change the dialog title from "Internet Explorer" > to "Windows Internet Explorer". I used the regex /Internet Explorer/ > so that it will work no matter which version of IE I use. > 2.) Require 'watir/contrib/enabled_popup' for your tests. > 3.) Define the popupChecker method to watch for a popup and dismiss > it (in this case, by clicking the button with the specified text): > def popupChecker(text) > Timeout::timeout(2)do > begin > if $ie.enabled_popup > hwnd = $ie.enabled_popup(5) > w = WinClicker.new > w.makeWindowActive(hwnd) > w.clickWindowsButton_hwnd(hwnd, > text) > end > rescue Timeout::Error > puts 'No popup existed' > end > end > end > 4.) Use the click_no_wait method on the link or button that will > launch the popup. > ie.button(:text, 'Continue').click_no_wait > 5.) Call the popupChecker method in case a popup exists > popupChecker('OK') > I hope this helps! > -Tiffany -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 15:07:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 14:07:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Resolved: (WTR-192) wait needs timeouts (sample code provided) Message-ID: <19266289.1059.1286046450820.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker resolved WTR-192. ------------------------------- Assignee: Charley Baker Resolution: Fixed Fix Version/s: (was: Soon) 1.6.6 Fixed for 1.6.6, closing. > wait needs timeouts (sample code provided) > ------------------------------------------ > > Key: WTR-192 > URL: http://jira.openqa.org/browse/WTR-192 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.5.3 > Reporter: Charley Baker > Assignee: Charley Baker > Priority: Major > Fix For: 1.6.6 > > > There are a few loops inside wait that need to have timeouts added. > while @ie.busy # XXX need to add time out > sleep a_moment > end > until @ie.readyState == READYSTATE_COMPLETE do # need time out > sleep a_moment > end > until doc.readyState == "complete" do # need time out > sleep a_moment > end > Otherwise if ie doesn't return the right value Watir hangs. > Noticed this on yahoo's finance page when streaming quotes are turned on: > http://finance.yahoo.com/q?s=ROST -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 15:07:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 14:07:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-192) wait needs timeouts (sample code provided) Message-ID: <9649362.1061.1286046450966.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker closed WTR-192. ----------------------------- Fixed for 1.6.6, closing. > wait needs timeouts (sample code provided) > ------------------------------------------ > > Key: WTR-192 > URL: http://jira.openqa.org/browse/WTR-192 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.5.3 > Reporter: Charley Baker > Assignee: Charley Baker > Priority: Major > Fix For: 1.6.6 > > > There are a few loops inside wait that need to have timeouts added. > while @ie.busy # XXX need to add time out > sleep a_moment > end > until @ie.readyState == READYSTATE_COMPLETE do # need time out > sleep a_moment > end > until doc.readyState == "complete" do # need time out > sleep a_moment > end > Otherwise if ie doesn't return the right value Watir hangs. > Noticed this on yahoo's finance page when streaming quotes are turned on: > http://finance.yahoo.com/q?s=ROST -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 15:09:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 14:09:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-166) Wait for XHRs and timers to complete before considering the page loaded (either as a configurable option or always on) Message-ID: <13271023.1064.1286046570846.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19869#action_19869 ] Charley Baker commented on WTR-166: ----------------------------------- Interesting issue, any further thoughts on this? > Wait for XHRs and timers to complete before considering the page loaded (either as a configurable option or always on) > ---------------------------------------------------------------------------------------------------------------------- > > Key: WTR-166 > URL: http://jira.openqa.org/browse/WTR-166 > Project: Watir > Issue Type: New Feature > Components: Wait > Affects Versions: 1.5.0/1.5.1 > Environment: x > Reporter: Jeff Fry > Priority: Major > Fix For: Next > > > Watir.wait() listens to whether IE thinks its done loading, and then checks to see that the main document and any sub documents/frames have finished loading. More and more, there are pages that on load also kick off various XHRs and timers. For me - and possibly for a growing number of folks, testing more AJAXy applications - it would be great to expand wait() to check if there are any XHRs or timers pending, in additional to the checks it currently makes. > Note, I don't know, but there may be applications where an XHR is intentionally left open at all times. If this happens I would guess that it's rare, but if we change the default behavior of watir.wait() to wait for pending XHRs and timers, we might want to give a config option that turns this off as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 16:39:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 15:39:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Resolved: (WTR-190) Watir can generate invalid attributes in tags which makes rexml raise an exception [patch] Message-ID: <22674749.1067.1286051970657.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker resolved WTR-190. ------------------------------- Resolution: Fixed Fix Version/s: (was: Next) 1.6.6 Closing, we're using nokogiri now and the OP can't repro. > Watir can generate invalid attributes in tags which makes rexml raise an exception [patch] > ------------------------------------------------------------------------------------------ > > Key: WTR-190 > URL: http://jira.openqa.org/browse/WTR-190 > Project: Watir > Issue Type: Bug > Components: Xpath Support > Affects Versions: 1.5.3 > Environment: Windows XP Sp2 > Reporter: Christian Fraenkel > Assignee: Angrez > Priority: Major > Fix For: 1.6.6 > > Attachments: patch.txt > > > in watir/ie.rb, all_tag_attributes, the used regex to filter attribute names is not restrictive enough - it allows every printable char in attribute names (which can lead to attributes like 'false;?="false;?"' for example). > A better regex that will not exhibit that problem would be /^[\w:][\w0-9.\-:]*$/ > I posted about this in the watir group: http://groups.google.com/group/watir-general/browse_thread/thread/454ba4d8bb4ea8b4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 16:39:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 15:39:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-190) Watir can generate invalid attributes in tags which makes rexml raise an exception [patch] Message-ID: <1233028.1070.1286051970715.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker closed WTR-190. ----------------------------- Closing, we're using nokogiri now and the OP can't repro. > Watir can generate invalid attributes in tags which makes rexml raise an exception [patch] > ------------------------------------------------------------------------------------------ > > Key: WTR-190 > URL: http://jira.openqa.org/browse/WTR-190 > Project: Watir > Issue Type: Bug > Components: Xpath Support > Affects Versions: 1.5.3 > Environment: Windows XP Sp2 > Reporter: Christian Fraenkel > Assignee: Angrez > Priority: Major > Fix For: 1.6.6 > > Attachments: patch.txt > > > in watir/ie.rb, all_tag_attributes, the used regex to filter attribute names is not restrictive enough - it allows every printable char in attribute names (which can lead to attributes like 'false;?="false;?"' for example). > A better regex that will not exhibit that problem would be /^[\w:][\w0-9.\-:]*$/ > I posted about this in the watir group: http://groups.google.com/group/watir-general/browse_thread/thread/454ba4d8bb4ea8b4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 16:43:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 15:43:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Resolved: (WTR-165) Watir's new wait logic doesn't always wait for all frames to load Message-ID: <11302272.1072.1286052210603.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker resolved WTR-165. ------------------------------- Resolution: Cannot Reproduce Can't repro this, closing for now. > Watir's new wait logic doesn't always wait for all frames to load > ----------------------------------------------------------------- > > Key: WTR-165 > URL: http://jira.openqa.org/browse/WTR-165 > Project: Watir > Issue Type: Bug > Components: Frame, Wait > Affects Versions: 1.5.0/1.5.1 > Environment: Win XP Pro > IE 7 > Watir Gem 1.5.1.1166 > ruby 1.8.5.21 > Reporter: David Brown > Fix For: Soon > > > I've been using the development gem 1.5.1.1166 which includes the > re-written wait logic to test a complex SAP web application. The main > content that I am automating is nested 4 frames deep. Up until this > past Friday this version of watir seemed to handle waiting for all of > the inner frames to load properly. Now however this wait logic isn't > always waiting until the pages load completely which causes my scripts > to fail. I don't think there have been any changes in the web app I'm > testing which would cause this. I did happen to install the > important/critical Microsoft security patches for June which could have > effected watir? > http://www.microsoft.com/technet/security/bulletin/ms07-jun.mspx > Has any one else experienced this problem with the new wait logic not > waiting quite long enough when there are many nested frames? > I wish this was a public web-app so I could provide an example w/html to > look at but it's not. > > Gems prior to 1.5.1.1166 would either give me the access denied errors > > as it tried to wait for the inner frames to load - or if those were > > suppressed, I had to put in a manual wait whenever I navigated to a new > > page: "sleep 0.1 until some_element_on_inner_frame.exists?". After > > installing 1166 all of these delay problems were fixed... Until now. > > > > Now that this issue has surfaced I'm forced to put the manual delays in > > again. It is not a big deal to do this, but, it's always cleaner if > > watir handles the delays properly. > In order to help narrow down the issue i've included a test script below which adds some extra logging to the watir wait method, and provides an example of the output I get when running it against my application. > ###############TEST SCRIPT ################ > require 'watir' > module Watir > class IE > # Block execution until the page has loaded. > # =nodoc > # Note: This code needs to be prepared for the ie object to be closed at > # any moment! > def wait(no_sleep=false) > @rexmlDomobject = nil > @down_load_time = 0.0 > a_moment = 0.2 # seconds > start_load_time = Time.now > begin > while @ie.busy # XXX need to add time out > sleep a_moment > end > until @ie.readyState == READYSTATE_COMPLETE do > sleep a_moment > end > sleep a_moment > until @ie.document do > sleep a_moment > end > docNum = 0 > documents_to_wait_for = [@ie.document] > rescue WIN32OLERuntimeError # IE window must have been closed > @down_load_time = Time.now - start_load_time > sleep @defaultSleepTime unless no_sleep > return @down_load_time > end > while doc = documents_to_wait_for.shift > docNum +=1 > begin > tsleep = Time.now > until doc.readyState == "complete" do > sleep a_moment > end > tsleep = Time.now - tsleep > puts "** waited #{tsleep} seconds for doc['#{docNum}'].readyState == 'complete'" > numFrames = doc.frames.length > @url_list << doc.url unless @url_list.include?(doc.url) > doc.frames.length.times do |n| > begin > documents_to_wait_for << doc.frames[n.to_s].document > puts "\t ** Adding Frame #{n+1} of #{numFrames} of document:'#{docNum}' as doc['#{docNum + n+1}']" > rescue WIN32OLERuntimeError > puts "\t ** WIN32OLERuntimeError Raised and Handled when Adding Frame #{n+1} of #{numFrames} of document:'#{docNum}' as doc['#{docNum + n+1}'] \n #{$!} \n\n" > end > end > rescue WIN32OLERuntimeError > puts "WIN32OLERuntimeError Raised and Handled when processing frames for doc['#{docNum}'] \n#{$!} \n #{$@.join("\n")} \n\n" > end > end > @down_load_time = Time.now - start_load_time > run_error_checks > sleep @defaultSleepTime unless no_sleep > @down_load_time > end > end > end > ie = Watir::IE.attach(:title,/SAP Netweaver/i) > puts "\n\n\n ****** Going to Accounts Screen Now ********" > ie.link(:text,'Accounts').click > dtime = ie.down_load_time > t = Time.now > #wait until the content of the innner frame is realy done loading. > sleep 0.1 until ie.frame(:name,/Desktop/).frame(:id,'isolatedWorkArea').frame(:name, 'crmA').frame(:name,/_B/).cell(:text,'Accounts').exists? > t = Time.now - t > puts "Navigated to Accounts: Watir waited:#{dtime} seconds - Inner Frame content wasn't available for another #{t} seconds" > ########SCRIPT OUTPUT############### > ****** Going to Accounts Screen Now ******** > ** waited 0.0 seconds for doc['1'].readyState == 'complete' > ** Adding Frame 1 of 3 of document:'1' as doc['2'] > ** Adding Frame 2 of 3 of document:'1' as doc['3'] > ** Adding Frame 3 of 3 of document:'1' as doc['4'] > ** waited 0.0 seconds for doc['2'].readyState == 'complete' > ** waited 0.0 seconds for doc['3'].readyState == 'complete' > ** waited 0.656 seconds for doc['4'].readyState == 'complete' > ** Adding Frame 1 of 2 of document:'4' as doc['5'] > ** Adding Frame 2 of 2 of document:'4' as doc['6'] > ** waited 0.0 seconds for doc['5'].readyState == 'complete' > ** waited 0.625 seconds for doc['6'].readyState == 'complete' > ** Adding Frame 1 of 1 of document:'6' as doc['7'] > ** waited 0.0 seconds for doc['7'].readyState == 'complete' > ** WIN32OLERuntimeError Raised and Handled when Adding Frame 1 of 2 of document:'7' as doc['8'] > document > OLE error code:80070005 in > Access is denied. > HRESULT error code:0x80020009 > Exception occurred. > ** Adding Frame 2 of 2 of document:'7' as doc['9'] > WIN32OLERuntimeError Raised and Handled when processing frames for doc['8'] > unknown property or method `readyState' > HRESULT error code:0x80070005 > Access is denied. > test_wait.rb:38:in `method_missing' > test_wait.rb:38:in `wait' > c:/ruby/lib/ruby/gems/1.8/gems/watir-1.5.1.1166/./watir.rb:2574:in `click' > test_wait.rb:69 > Navigated to Accounts: Watir waited:6.936 seconds - Inner Frame content wasn't available for another 1.297 seconds > ####################Frame info ################# > $ie.show_frames > there are 3 frames > frame index: 1 name: sapPopupMainId_X0 > frame index: 2 name: obnNavIFrame > frame index: 3 name: Desktop Innerpage > > ie.frame(:index,3).show_frames > there are 2 frames > frame index: 1 name: sapPopupMainId_X0 > frame index: 2 name: isolatedWorkArea > ie.frame(:index,3).frame(:index,2).show_frames > there are 1 frames > frame index: 1 name: crmA > ie.frame(:index,3).frame(:index,2).frame(:index,1).show_frames > there are 2 frames > frame index: 1 Access Denied, see http://wiki.openqa.org/display/WTR/FAQ#access-denied > frame index: 2 name: 4678CFD23E1209F4E100000093225E68_B ####### THIS IS THE FRAME THAT HAS THE CONTENT that watir isn't waiting for to load. ####### -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 16:43:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 15:43:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-165) Watir's new wait logic doesn't always wait for all frames to load Message-ID: <21985807.1074.1286052210635.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker closed WTR-165. ----------------------------- Can't repro this, closing for now. > Watir's new wait logic doesn't always wait for all frames to load > ----------------------------------------------------------------- > > Key: WTR-165 > URL: http://jira.openqa.org/browse/WTR-165 > Project: Watir > Issue Type: Bug > Components: Frame, Wait > Affects Versions: 1.5.0/1.5.1 > Environment: Win XP Pro > IE 7 > Watir Gem 1.5.1.1166 > ruby 1.8.5.21 > Reporter: David Brown > Fix For: Soon > > > I've been using the development gem 1.5.1.1166 which includes the > re-written wait logic to test a complex SAP web application. The main > content that I am automating is nested 4 frames deep. Up until this > past Friday this version of watir seemed to handle waiting for all of > the inner frames to load properly. Now however this wait logic isn't > always waiting until the pages load completely which causes my scripts > to fail. I don't think there have been any changes in the web app I'm > testing which would cause this. I did happen to install the > important/critical Microsoft security patches for June which could have > effected watir? > http://www.microsoft.com/technet/security/bulletin/ms07-jun.mspx > Has any one else experienced this problem with the new wait logic not > waiting quite long enough when there are many nested frames? > I wish this was a public web-app so I could provide an example w/html to > look at but it's not. > > Gems prior to 1.5.1.1166 would either give me the access denied errors > > as it tried to wait for the inner frames to load - or if those were > > suppressed, I had to put in a manual wait whenever I navigated to a new > > page: "sleep 0.1 until some_element_on_inner_frame.exists?". After > > installing 1166 all of these delay problems were fixed... Until now. > > > > Now that this issue has surfaced I'm forced to put the manual delays in > > again. It is not a big deal to do this, but, it's always cleaner if > > watir handles the delays properly. > In order to help narrow down the issue i've included a test script below which adds some extra logging to the watir wait method, and provides an example of the output I get when running it against my application. > ###############TEST SCRIPT ################ > require 'watir' > module Watir > class IE > # Block execution until the page has loaded. > # =nodoc > # Note: This code needs to be prepared for the ie object to be closed at > # any moment! > def wait(no_sleep=false) > @rexmlDomobject = nil > @down_load_time = 0.0 > a_moment = 0.2 # seconds > start_load_time = Time.now > begin > while @ie.busy # XXX need to add time out > sleep a_moment > end > until @ie.readyState == READYSTATE_COMPLETE do > sleep a_moment > end > sleep a_moment > until @ie.document do > sleep a_moment > end > docNum = 0 > documents_to_wait_for = [@ie.document] > rescue WIN32OLERuntimeError # IE window must have been closed > @down_load_time = Time.now - start_load_time > sleep @defaultSleepTime unless no_sleep > return @down_load_time > end > while doc = documents_to_wait_for.shift > docNum +=1 > begin > tsleep = Time.now > until doc.readyState == "complete" do > sleep a_moment > end > tsleep = Time.now - tsleep > puts "** waited #{tsleep} seconds for doc['#{docNum}'].readyState == 'complete'" > numFrames = doc.frames.length > @url_list << doc.url unless @url_list.include?(doc.url) > doc.frames.length.times do |n| > begin > documents_to_wait_for << doc.frames[n.to_s].document > puts "\t ** Adding Frame #{n+1} of #{numFrames} of document:'#{docNum}' as doc['#{docNum + n+1}']" > rescue WIN32OLERuntimeError > puts "\t ** WIN32OLERuntimeError Raised and Handled when Adding Frame #{n+1} of #{numFrames} of document:'#{docNum}' as doc['#{docNum + n+1}'] \n #{$!} \n\n" > end > end > rescue WIN32OLERuntimeError > puts "WIN32OLERuntimeError Raised and Handled when processing frames for doc['#{docNum}'] \n#{$!} \n #{$@.join("\n")} \n\n" > end > end > @down_load_time = Time.now - start_load_time > run_error_checks > sleep @defaultSleepTime unless no_sleep > @down_load_time > end > end > end > ie = Watir::IE.attach(:title,/SAP Netweaver/i) > puts "\n\n\n ****** Going to Accounts Screen Now ********" > ie.link(:text,'Accounts').click > dtime = ie.down_load_time > t = Time.now > #wait until the content of the innner frame is realy done loading. > sleep 0.1 until ie.frame(:name,/Desktop/).frame(:id,'isolatedWorkArea').frame(:name, 'crmA').frame(:name,/_B/).cell(:text,'Accounts').exists? > t = Time.now - t > puts "Navigated to Accounts: Watir waited:#{dtime} seconds - Inner Frame content wasn't available for another #{t} seconds" > ########SCRIPT OUTPUT############### > ****** Going to Accounts Screen Now ******** > ** waited 0.0 seconds for doc['1'].readyState == 'complete' > ** Adding Frame 1 of 3 of document:'1' as doc['2'] > ** Adding Frame 2 of 3 of document:'1' as doc['3'] > ** Adding Frame 3 of 3 of document:'1' as doc['4'] > ** waited 0.0 seconds for doc['2'].readyState == 'complete' > ** waited 0.0 seconds for doc['3'].readyState == 'complete' > ** waited 0.656 seconds for doc['4'].readyState == 'complete' > ** Adding Frame 1 of 2 of document:'4' as doc['5'] > ** Adding Frame 2 of 2 of document:'4' as doc['6'] > ** waited 0.0 seconds for doc['5'].readyState == 'complete' > ** waited 0.625 seconds for doc['6'].readyState == 'complete' > ** Adding Frame 1 of 1 of document:'6' as doc['7'] > ** waited 0.0 seconds for doc['7'].readyState == 'complete' > ** WIN32OLERuntimeError Raised and Handled when Adding Frame 1 of 2 of document:'7' as doc['8'] > document > OLE error code:80070005 in > Access is denied. > HRESULT error code:0x80020009 > Exception occurred. > ** Adding Frame 2 of 2 of document:'7' as doc['9'] > WIN32OLERuntimeError Raised and Handled when processing frames for doc['8'] > unknown property or method `readyState' > HRESULT error code:0x80070005 > Access is denied. > test_wait.rb:38:in `method_missing' > test_wait.rb:38:in `wait' > c:/ruby/lib/ruby/gems/1.8/gems/watir-1.5.1.1166/./watir.rb:2574:in `click' > test_wait.rb:69 > Navigated to Accounts: Watir waited:6.936 seconds - Inner Frame content wasn't available for another 1.297 seconds > ####################Frame info ################# > $ie.show_frames > there are 3 frames > frame index: 1 name: sapPopupMainId_X0 > frame index: 2 name: obnNavIFrame > frame index: 3 name: Desktop Innerpage > > ie.frame(:index,3).show_frames > there are 2 frames > frame index: 1 name: sapPopupMainId_X0 > frame index: 2 name: isolatedWorkArea > ie.frame(:index,3).frame(:index,2).show_frames > there are 1 frames > frame index: 1 name: crmA > ie.frame(:index,3).frame(:index,2).frame(:index,1).show_frames > there are 2 frames > frame index: 1 Access Denied, see http://wiki.openqa.org/display/WTR/FAQ#access-denied > frame index: 2 name: 4678CFD23E1209F4E100000093225E68_B ####### THIS IS THE FRAME THAT HAS THE CONTENT that watir isn't waiting for to load. ####### -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 16:45:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 15:45:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-154) Remove :beforeText and :afterText Message-ID: <31794037.1076.1286052330569.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19874#action_19874 ] Charley Baker commented on WTR-154: ----------------------------------- Bumping this. Should we remove these in the next version? > Remove :beforeText and :afterText > --------------------------------- > > Key: WTR-154 > URL: http://jira.openqa.org/browse/WTR-154 > Project: Watir > Issue Type: Improvement > Components: HTML Controls > Reporter: Bret Pettichord > Fix For: Soon > > > These don't seem to work the way people expect and won't port to Firewatir, etc anyway. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 16:47:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 15:47:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-129) Automatically wrap watir commands in a test case Message-ID: <14223236.1078.1286052450592.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19875#action_19875 ] Charley Baker commented on WTR-129: ----------------------------------- This seems like an issue that's already handled by "frameworks" - Taza, Watircraft. I'd recommend closing. > Automatically wrap watir commands in a test case > ------------------------------------------------ > > Key: WTR-129 > URL: http://jira.openqa.org/browse/WTR-129 > Project: Watir > Issue Type: New Feature > Reporter: Bret Pettichord > Priority: Major > Fix For: Future > > > Simple test case > class MyTest < Watir::TestCase > def my_test > goto('http://www.google.com') > text_field(:name, 'q').set 'ruby' > button(:name, 'btnG').click > assert(text.include? 'pickaxe') > end > end > Putting it all together > test1.rb: > goto('http://www.google.com') > text_field(:name, 'q').set 'ruby' > button(:name, 'btnG').click > assert(text.include? 'pickaxe') > test2.rb: > goto('http://www.google.com') > text_field(:name, 'q').set 'watir' > button(:name, 'btnG').click > assert(text.include? 'Holy Grail') > From the command line: > > watir -t test*.rb > This would automatically run the tests, creating a testcase wrapper for each test and then executing the combined suite. > Reusing browsers between tests > The "automatic" test suites will reuse a browser between tests, blanking the window, and recreate it if necessary. This is really the best way to use Watir. > * Possibly provide option to close and reopen between tests, but this is hard to make reliable! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 17:22:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 16:22:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Resolved: (WTR-46) Add a maximum page load time Message-ID: <15548786.1080.1286054550635.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker resolved WTR-46. ------------------------------ Resolution: Fixed Fix Version/s: (was: Future) 1.6.6 Fixed, we've added a timeout > Add a maximum page load time > ---------------------------- > > Key: WTR-46 > URL: http://jira.openqa.org/browse/WTR-46 > Project: Watir > Issue Type: Improvement > Components: Wait > Affects Versions: 1.4, 1.4.1 > Reporter: Charley Baker > Fix For: 1.6.6 > > > if a page takes too long to load, we should throw an exception. > Originally reported on Rubyforge: http://rubyforge.org/tracker/index.php?func=detail&aid=1863&group_id=104&atid=1999 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 17:22:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 16:22:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-46) Add a maximum page load time Message-ID: <8288184.1082.1286054550667.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker closed WTR-46. ---------------------------- Fixed, we've added a timeout > Add a maximum page load time > ---------------------------- > > Key: WTR-46 > URL: http://jira.openqa.org/browse/WTR-46 > Project: Watir > Issue Type: Improvement > Components: Wait > Affects Versions: 1.4, 1.4.1 > Reporter: Charley Baker > Fix For: 1.6.6 > > > if a page takes too long to load, we should throw an exception. > Originally reported on Rubyforge: http://rubyforge.org/tracker/index.php?func=detail&aid=1863&group_id=104&atid=1999 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 17:36:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 16:36:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-49) Rdoc needs to be set up as an enry point to Watir Documentation Message-ID: <12237749.1086.1286055390782.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker closed WTR-49. ---------------------------- Closing, rdocs's been updated. > Rdoc needs to be set up as an enry point to Watir Documentation > --------------------------------------------------------------- > > Key: WTR-49 > URL: http://jira.openqa.org/browse/WTR-49 > Project: Watir > Issue Type: Task > Components: Documentation > Reporter: Charley Baker > Priority: Major > Fix For: 1.6.6 > > > Now that we are distributing Watir as a Gem, we need to make the RDOC be a portal to all of our documentation. > 1. The main page of the RDOC should include links to the other Watir documentation (all doc in our package is also on > our website). > We also need to rearrange release notes, support information, etc, taking a cue from how other ruby projects are > documented. > Originally reported on Rubyforge: http://rubyforge.org/tracker/index.php?func=detail&aid=2280&group_id=104&atid=1999 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 17:36:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 16:36:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Resolved: (WTR-49) Rdoc needs to be set up as an enry point to Watir Documentation Message-ID: <2325933.1084.1286055390751.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker resolved WTR-49. ------------------------------ Resolution: Fixed Fix Version/s: (was: Soon) 1.6.6 Closing, rdocs's been updated. > Rdoc needs to be set up as an enry point to Watir Documentation > --------------------------------------------------------------- > > Key: WTR-49 > URL: http://jira.openqa.org/browse/WTR-49 > Project: Watir > Issue Type: Task > Components: Documentation > Reporter: Charley Baker > Priority: Major > Fix For: 1.6.6 > > > Now that we are distributing Watir as a Gem, we need to make the RDOC be a portal to all of our documentation. > 1. The main page of the RDOC should include links to the other Watir documentation (all doc in our package is also on > our website). > We also need to rearrange release notes, support information, etc, taking a cue from how other ruby projects are > documented. > Originally reported on Rubyforge: http://rubyforge.org/tracker/index.php?func=detail&aid=2280&group_id=104&atid=1999 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 17:38:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 16:38:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-22) SelectBox doesn't focus Message-ID: <6358797.1096.1286055510771.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker closed WTR-22. ---------------------------- Dup, closing. > SelectBox doesn't focus > ----------------------- > > Key: WTR-22 > URL: http://jira.openqa.org/browse/WTR-22 > Project: Watir > Issue Type: Bug > Components: HTML Controls > Affects Versions: 1.4.1 > Reporter: Charley Baker > Assignee: Bret Pettichord > Fix For: Soon > > > When we select an option in a SelectBox, it does not cause the previously active object to blur. We added a call to > focus in the select_item_in_select_list( name_or_value, item ) method, which seems to solve our problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 17:38:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 16:38:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Resolved: (WTR-22) SelectBox doesn't focus Message-ID: <5446248.1093.1286055510711.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker resolved WTR-22. ------------------------------ Resolution: Duplicate Dup, closing. > SelectBox doesn't focus > ----------------------- > > Key: WTR-22 > URL: http://jira.openqa.org/browse/WTR-22 > Project: Watir > Issue Type: Bug > Components: HTML Controls > Affects Versions: 1.4.1 > Reporter: Charley Baker > Assignee: Bret Pettichord > Fix For: Soon > > > When we select an option in a SelectBox, it does not cause the previously active object to blur. We added a call to > focus in the select_item_in_select_list( name_or_value, item ) method, which seems to solve our problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 17:42:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 16:42:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-422) Need a feature to identify unknown element using inner_text Message-ID: <9653.1100.1286055750640.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker closed WTR-422. ----------------------------- Closing, this will work with Element. > Need a feature to identify unknown element using inner_text > ----------------------------------------------------------- > > Key: WTR-422 > URL: http://jira.openqa.org/browse/WTR-422 > Project: Watir > Issue Type: New Feature > Components: HTML Controls > Affects Versions: 1.6.5 > Environment: IE: Windows > Reporter: Nick Wayne > Fix For: 1.6.6 > > > Hi, > It would be really nice if a method is provided to identify any element using inner_text. Right now one has to know the type of element one is looking for to begin with. e.g. div or td or tr. But it is not possible to traverse back from the inner_text and get the element. > e.g. What I am asking for is : > text1 > to be able to get by matching text1 even though I do not know what is the type of is. > Best regards, > Nick -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 17:42:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 16:42:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Resolved: (WTR-422) Need a feature to identify unknown element using inner_text Message-ID: <20000622.1098.1286055750609.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker resolved WTR-422. ------------------------------- Resolution: Fixed Fix Version/s: (was: Soon) 1.6.6 Closing, this will work with Element. > Need a feature to identify unknown element using inner_text > ----------------------------------------------------------- > > Key: WTR-422 > URL: http://jira.openqa.org/browse/WTR-422 > Project: Watir > Issue Type: New Feature > Components: HTML Controls > Affects Versions: 1.6.5 > Environment: IE: Windows > Reporter: Nick Wayne > Fix For: 1.6.6 > > > Hi, > It would be really nice if a method is provided to identify any element using inner_text. Right now one has to know the type of element one is looking for to begin with. e.g. div or td or tr. But it is not possible to traverse back from the inner_text and get the element. > e.g. What I am asking for is : > text1 > to be able to get by matching text1 even though I do not know what is the type of is. > Best regards, > Nick -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 17:36:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 16:36:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Resolved: (WTR-38) Many unit tests are incomplete Message-ID: <29705362.1088.1286055390822.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker resolved WTR-38. ------------------------------ Resolution: Fixed Fix Version/s: (was: Future) 1.6.6 Closing this. Unit tests have been updated. > Many unit tests are incomplete > ------------------------------ > > Key: WTR-38 > URL: http://jira.openqa.org/browse/WTR-38 > Project: Watir > Issue Type: Improvement > Components: Unit Tests > Reporter: Charley Baker > Fix For: 1.6.6 > > > Many of the unit tests 'test' by printing out the output of some command. Instead they should use assert_equal to compare > the output to the expected (or at least the current) output. > Whenever you see messages and data appearing when you run the tests, it is an indication that the tests aren't complete > and are unable to detect errors in these commands. > Originally reported on Rubyforge: http://rubyforge.org/tracker/index.php?func=detail&aid=1508&group_id=104&atid=1999 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 2 17:36:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Sat, 2 Oct 2010 16:36:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-38) Many unit tests are incomplete Message-ID: <30866750.1090.1286055390853.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker closed WTR-38. ---------------------------- Closing this. Unit tests have been updated. > Many unit tests are incomplete > ------------------------------ > > Key: WTR-38 > URL: http://jira.openqa.org/browse/WTR-38 > Project: Watir > Issue Type: Improvement > Components: Unit Tests > Reporter: Charley Baker > Fix For: 1.6.6 > > > Many of the unit tests 'test' by printing out the output of some command. Instead they should use assert_equal to compare > the output to the expected (or at least the current) output. > Whenever you see messages and data appearing when you run the tests, it is an indication that the tests aren't complete > and are unable to detect errors in these commands. > Originally reported on Rubyforge: http://rubyforge.org/tracker/index.php?func=detail&aid=1508&group_id=104&atid=1999 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From bret at pettichord.com Sat Oct 2 22:27:10 2010 From: bret at pettichord.com (Bret Pettichord) Date: Sat, 2 Oct 2010 21:27:10 -0500 Subject: [Wtr-development] README file to github!? In-Reply-To: References: Message-ID: Looks good to me. On Saturday, October 2, 2010, Charley Baker wrote: > Done. I cherrypicked the README change from master, updated VERSION > and CHANGES. Releasing final 1.6.6 in a few if anyone can double check > we're good to go. :) > > > Charley Baker > Lead Developer, Watir, http://watir.com > > > > On Sat, Oct 2, 2010 at 11:40 AM, Bret Pettichord wrote: >> It's a beautiful day out today, so I'm going to take care of some yard work >> and assemble my new grill. >> >> I'll merge it after that. Or you can do it now. >> >> Bret >> >> On Sat, Oct 2, 2010 at 10:22 AM, Charley Baker >> wrote: >>> >>> Once you make these changes to the release branch and update CHANGES, >>> I vote we release 1.6.6 final and start working on 1.6.7. All in >>> favor? Let me know if you want me to merge it. >>> >>> >>> Charley Baker >>> Lead Developer, Watir, http://watir.com >>> >>> >>> >>> 2010/10/1 Bret Pettichord : >>> > I've updated master so that all the gems now use the one readme. >>> > >>> > I will also make these changes to the 1.6.6 release branch. >>> > >>> > Bret >>> > >>> > On Fri, Oct 1, 2010 at 1:59 PM, marekj wrote: >>> >> >>> >> On Fri, Oct 1, 2010 at 1:41 PM, Jarmo wrote: >>> >> > That's just not true. It might be the case at the moment, but i have >>> >> > a >>> >> > plan to fix that. In my mind there should be still 1 README on github >>> >> > and when gems are being made then that same README should be copied >>> >> > into 3 gems. So every gem would have the same README. I don't see >>> >> > much >>> >> > of a point of having different readme-s >>> >> >>> >> Thanks Jarmo, now I know what you mean to have one README as a >>> >> template. I had not thought of that. >>> >> >>> >> > though since the API should be >>> >> > same anyway (i know it currently isn't 100%, but that shouldn't be in >>> >> > the readme anyway). >>> >> > >>> >> > As you can see then currently on the github isn't any VERSION or >>> >> > CHANGES in commonwatir, watir or firewatir directory, but they're >>> >> > still there when you install gems. Same plan goes to README. >>> >> > >>> >> > Jarmo >>> >> > >>> >> > On Fri, Oct 1, 2010 at 7:33 PM, marekj wrote: >>> >> >> I wanted to explain and defend my view of why there are 4 >>> >> >> README.rdoc >>> >> >> files in watir project. >>> >> >> >>> >> >> Watir project on github has a README.rdoc file as a landing page >>> >> >> which >>> >> >> is used to present the project and its 3 separate gems. >>> >> >> Each library firewatir, watir, commonwatir has a README.rdoc >>> >> >> specific >>> >> >> to that library so each gem then has it's own readme. >>> >> >> The main top level readme never makes it to the user's machine when >>> >> >> they install the gems. >>> >> >> If the user runs rdoc generation from the gems on their own machine >>> >> >> they now have a local README for each one of the gems. >>> >> >> The toplevel gem is visible on github as a landing page for the >>> >> >> project. >>> >> >> >>> >> >> And that is why I thought there should be 4 README.rdoc files >>> >> >> >>> >> >> >>> >> >> marekj >>> >> >> >>> >> >> http://rubytester.com >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Fri, Oct 1, 2010 at 11:02 AM, marekj -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord From alister.scott at gmail.com Sat Oct 2 23:31:41 2010 From: alister.scott at gmail.com (Alister Scott) Date: Sun, 3 Oct 2010 13:31:41 +1000 Subject: [Wtr-development] README file to github!? In-Reply-To: References: Message-ID: Agree, all good. On Sun, Oct 3, 2010 at 12:27 PM, Bret Pettichord wrote: > Looks good to me. > > On Saturday, October 2, 2010, Charley Baker > wrote: > > Done. I cherrypicked the README change from master, updated VERSION > > and CHANGES. Releasing final 1.6.6 in a few if anyone can double check > > we're good to go. :) > > > > > > Charley Baker > > Lead Developer, Watir, http://watir.com > > > > > > > > On Sat, Oct 2, 2010 at 11:40 AM, Bret Pettichord > wrote: > >> It's a beautiful day out today, so I'm going to take care of some yard > work > >> and assemble my new grill. > >> > >> I'll merge it after that. Or you can do it now. > >> > >> Bret > >> > >> On Sat, Oct 2, 2010 at 10:22 AM, Charley Baker > > >> wrote: > >>> > >>> Once you make these changes to the release branch and update CHANGES, > >>> I vote we release 1.6.6 final and start working on 1.6.7. All in > >>> favor? Let me know if you want me to merge it. > >>> > >>> > >>> Charley Baker > >>> Lead Developer, Watir, http://watir.com > >>> > >>> > >>> > >>> 2010/10/1 Bret Pettichord : > >>> > I've updated master so that all the gems now use the one readme. > >>> > > >>> > I will also make these changes to the 1.6.6 release branch. > >>> > > >>> > Bret > >>> > > >>> > On Fri, Oct 1, 2010 at 1:59 PM, marekj wrote: > >>> >> > >>> >> On Fri, Oct 1, 2010 at 1:41 PM, Jarmo wrote: > >>> >> > That's just not true. It might be the case at the moment, but i > have > >>> >> > a > >>> >> > plan to fix that. In my mind there should be still 1 README on > github > >>> >> > and when gems are being made then that same README should be > copied > >>> >> > into 3 gems. So every gem would have the same README. I don't see > >>> >> > much > >>> >> > of a point of having different readme-s > >>> >> > >>> >> Thanks Jarmo, now I know what you mean to have one README as a > >>> >> template. I had not thought of that. > >>> >> > >>> >> > though since the API should be > >>> >> > same anyway (i know it currently isn't 100%, but that shouldn't be > in > >>> >> > the readme anyway). > >>> >> > > >>> >> > As you can see then currently on the github isn't any VERSION or > >>> >> > CHANGES in commonwatir, watir or firewatir directory, but they're > >>> >> > still there when you install gems. Same plan goes to README. > >>> >> > > >>> >> > Jarmo > >>> >> > > >>> >> > On Fri, Oct 1, 2010 at 7:33 PM, marekj > wrote: > >>> >> >> I wanted to explain and defend my view of why there are 4 > >>> >> >> README.rdoc > >>> >> >> files in watir project. > >>> >> >> > >>> >> >> Watir project on github has a README.rdoc file as a landing page > >>> >> >> which > >>> >> >> is used to present the project and its 3 separate gems. > >>> >> >> Each library firewatir, watir, commonwatir has a README.rdoc > >>> >> >> specific > >>> >> >> to that library so each gem then has it's own readme. > >>> >> >> The main top level readme never makes it to the user's machine > when > >>> >> >> they install the gems. > >>> >> >> If the user runs rdoc generation from the gems on their own > machine > >>> >> >> they now have a local README for each one of the gems. > >>> >> >> The toplevel gem is visible on github as a landing page for the > >>> >> >> project. > >>> >> >> > >>> >> >> And that is why I thought there should be 4 README.rdoc files > >>> >> >> > >>> >> >> > >>> >> >> marekj > >>> >> >> > >>> >> >> http://rubytester.com > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> On Fri, Oct 1, 2010 at 11:02 AM, marekj < > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Sun Oct 3 08:59:22 2010 From: jarmo.p at gmail.com (Jarmo) Date: Sun, 3 Oct 2010 15:59:22 +0300 Subject: [Wtr-development] README file to github!? In-Reply-To: References: Message-ID: Go, go go. Jarmo On Sun, Oct 3, 2010 at 6:31 AM, Alister Scott wrote: > Agree, all good. > > > On Sun, Oct 3, 2010 at 12:27 PM, Bret Pettichord > wrote: >> >> Looks good to me. >> >> On Saturday, October 2, 2010, Charley Baker >> wrote: >> > Done. I cherrypicked the README change from master, updated VERSION >> > and CHANGES. Releasing final 1.6.6 in a few if anyone can double check >> > we're good to go. :) >> > >> > >> > Charley Baker >> > Lead Developer, Watir, http://watir.com >> > >> > >> > >> > On Sat, Oct 2, 2010 at 11:40 AM, Bret Pettichord >> > wrote: >> >> It's a beautiful day out today, so I'm going to take care of some yard >> >> work >> >> and assemble my new grill. >> >> >> >> I'll merge it after that. Or you can do it now. >> >> >> >> Bret >> >> >> >> On Sat, Oct 2, 2010 at 10:22 AM, Charley Baker >> >> >> >> wrote: >> >>> >> >>> Once you make these changes to the release branch and update CHANGES, >> >>> I vote we release 1.6.6 final and start working on 1.6.7. All in >> >>> favor? Let me know if you want me to merge it. >> >>> >> >>> >> >>> Charley Baker >> >>> Lead Developer, Watir, http://watir.com >> >>> >> >>> >> >>> >> >>> 2010/10/1 Bret Pettichord : >> >>> > I've updated master so that all the gems now use the one readme. >> >>> > >> >>> > I will also make these changes to the 1.6.6 release branch. >> >>> > >> >>> > Bret >> >>> > >> >>> > On Fri, Oct 1, 2010 at 1:59 PM, marekj wrote: >> >>> >> >> >>> >> On Fri, Oct 1, 2010 at 1:41 PM, Jarmo wrote: >> >>> >> > That's just not true. It might be the case at the moment, but i >> >>> >> > have >> >>> >> > a >> >>> >> > plan to fix that. In my mind there should be still 1 README on >> >>> >> > github >> >>> >> > and when gems are being made then that same README should be >> >>> >> > copied >> >>> >> > into 3 gems. So every gem would have the same README. I don't see >> >>> >> > much >> >>> >> > of a point of having different readme-s >> >>> >> >> >>> >> Thanks Jarmo, now I know what you mean to have one README as a >> >>> >> template. I had not thought of that. >> >>> >> >> >>> >> > though since the API should be >> >>> >> > same anyway (i know it currently isn't 100%, but that shouldn't >> >>> >> > be in >> >>> >> > the readme anyway). >> >>> >> > >> >>> >> > As you can see then currently on the github isn't any VERSION or >> >>> >> > CHANGES in commonwatir, watir or firewatir directory, but they're >> >>> >> > still there when you install gems. Same plan goes to README. >> >>> >> > >> >>> >> > Jarmo >> >>> >> > >> >>> >> > On Fri, Oct 1, 2010 at 7:33 PM, marekj >> >>> >> > wrote: >> >>> >> >> I wanted to explain and defend my view of why there are 4 >> >>> >> >> README.rdoc >> >>> >> >> files in watir project. >> >>> >> >> >> >>> >> >> Watir project on github has a README.rdoc file as a landing page >> >>> >> >> which >> >>> >> >> is used to present the project and its 3 separate gems. >> >>> >> >> Each library firewatir, watir, commonwatir has a README.rdoc >> >>> >> >> specific >> >>> >> >> to that library so each gem then has it's own readme. >> >>> >> >> The main top level readme never makes it to the user's machine >> >>> >> >> when >> >>> >> >> they install the gems. >> >>> >> >> If the user runs rdoc generation from the gems on their own >> >>> >> >> machine >> >>> >> >> they now have a local README for each one of the gems. >> >>> >> >> The toplevel gem is visible on github as a landing page for the >> >>> >> >> project. >> >>> >> >> >> >>> >> >> And that is why I thought there should be 4 README.rdoc files >> >>> >> >> >> >>> >> >> >> >>> >> >> marekj >> >>> >> >> >> >>> >> >> http://rubytester.com >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> On Fri, Oct 1, 2010 at 11:02 AM, marekj >> >> -- >> Bret Pettichord >> Lead Developer, Watir, www.watir.com >> >> Blog, www.io.com/~wazmo/blog >> Twitter, www.twitter.com/bpettichord >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From charley.baker at gmail.com Sun Oct 3 14:35:18 2010 From: charley.baker at gmail.com (Charley Baker) Date: Sun, 3 Oct 2010 12:35:18 -0600 Subject: [Wtr-development] Watir 1.6.6 final released Message-ID: Hello (fire)watirists! We are happy to announce that a (very) long-waited (Fire)Watir 1.6.6 final gem is out! You can check out changelog at http://github.com/bret/watir/blob/master/CHANGES Feel free to give it a test drive. Here are the basic instructions. Make sure your local gem system is up to date. gem update --system run gem -v at the command line, you should be running 1.3.7 gem install watir Note: If you're installing on Mac or Linux you'll want to use firewatir for the gem install. ...and give it a go. Try to use it with your existing test suites and so on to see if there are any issues. If there are any problems then: 1) Fix it and send a pull request on Github, our main github repo: http://github.com/bret/watir This is the preferred way of accepting patches, we're happy to work with you on how to do this, github also has extensive docs on how to fork and submit a pull request. 2) Add it to our JIRA tracker: http://jira.openqa.org/browse/WTR If you need help with that let us know. If you do have time and can help, please let us know, we can take any help from documentation to running tests on various OSes. We're a friendly project and would be happy to mentor you if you and/or your company is willing to put in the time. Cheers, The Watir Team From jarmo.p at gmail.com Sun Oct 3 15:53:59 2010 From: jarmo.p at gmail.com (Jarmo) Date: Sun, 3 Oct 2010 22:53:59 +0300 Subject: [Wtr-development] Watir 1.6.6 final released In-Reply-To: References: Message-ID: Hey! You forgot to tag it on git. You can still do it, i guess, otherwise the whole changelog link in CHANGES doesn't work - http://github.com/bret/watir/compare/v1.6.5...v1.6.6 Although i don't know if you tag it on release branch will the link still work... Jarmo On Sun, Oct 3, 2010 at 9:35 PM, Charley Baker wrote: > Hello (fire)watirists! > > We are happy to announce that a (very) long-waited (Fire)Watir > 1.6.6 final gem is out! > > You can check out changelog at http://github.com/bret/watir/blob/master/CHANGES > > Feel free to give it a test drive. Here are the basic instructions. > > Make sure your local gem system is up to date. > gem update --system > run gem -v at the command line, you should be running 1.3.7 > > gem install watir > Note: If you're installing on Mac or Linux you'll want to use > firewatir for the gem install. > > ...and give it a go. Try to use it with your existing test suites and > so on to see if there are any issues. > If there are any problems then: > 1) Fix it and send a pull request on Github, our main github repo: > http://github.com/bret/watir > ?This is the preferred way of accepting patches, we're happy to work > with you on how to do this, github also has extensive docs on how to > fork and submit a pull request. > 2) Add it to our JIRA tracker: http://jira.openqa.org/browse/WTR > If you need help with that let us know. > > If you do have time and can help, please let us know, we can take any > help from documentation to running tests on various OSes. We're a > friendly project and would be happy to mentor you if you and/or your > company is willing to put in the time. > > > Cheers, > The Watir Team > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From alex.ikhelis at gmail.com Sun Oct 3 16:30:04 2010 From: alex.ikhelis at gmail.com (Aliaksandr Ikhelis) Date: Sun, 3 Oct 2010 21:30:04 +0100 Subject: [Wtr-development] Watir 1.6.6 final released In-Reply-To: References: Message-ID: Hi guys, Thanks a lot for the new version of Watir! Sorry for looping into this thread. I believe many users wil have similar questions. 1. Is installation instructions page (with all the recommended ruby/rubygems versions) is up-to-date? http://watir.com/installation/ This have always been a bit tricky to get one's test environment to set up properly. 2. Is current watir-webdriver integration stable enough for usage? What is recommended for cross-browser testing with watir: watir for IE and FF, or watir-webdriver? Thank you, Aliaksandr Ikhelis On Sun, Oct 3, 2010 at 8:53 PM, Jarmo wrote: > Hey! > > You forgot to tag it on git. You can still do it, i guess, otherwise > the whole changelog link in CHANGES doesn't work - > http://github.com/bret/watir/compare/v1.6.5...v1.6.6 > > Although i don't know if you tag it on release branch will the link > still work... > > Jarmo > > On Sun, Oct 3, 2010 at 9:35 PM, Charley Baker > wrote: > > Hello (fire)watirists! > > > > We are happy to announce that a (very) long-waited (Fire)Watir > > 1.6.6 final gem is out! > > > > You can check out changelog at > http://github.com/bret/watir/blob/master/CHANGES > > > > Feel free to give it a test drive. Here are the basic instructions. > > > > Make sure your local gem system is up to date. > > gem update --system > > run gem -v at the command line, you should be running 1.3.7 > > > > gem install watir > > Note: If you're installing on Mac or Linux you'll want to use > > firewatir for the gem install. > > > > ...and give it a go. Try to use it with your existing test suites and > > so on to see if there are any issues. > > If there are any problems then: > > 1) Fix it and send a pull request on Github, our main github repo: > > http://github.com/bret/watir > > This is the preferred way of accepting patches, we're happy to work > > with you on how to do this, github also has extensive docs on how to > > fork and submit a pull request. > > 2) Add it to our JIRA tracker: http://jira.openqa.org/browse/WTR > > If you need help with that let us know. > > > > If you do have time and can help, please let us know, we can take any > > help from documentation to running tests on various OSes. We're a > > friendly project and would be happy to mentor you if you and/or your > > company is willing to put in the time. > > > > > > Cheers, > > The Watir Team > > _______________________________________________ > > 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 Sun Oct 3 20:47:31 2010 From: watirjira at gmail.com (Bret Pettichord (JIRA)) Date: Sun, 3 Oct 2010 19:47:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-129) Automatically wrap watir commands in a test case Message-ID: <24530458.1104.1286153251257.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret Pettichord closed WTR-129. ------------------------------- Resolution: Won't Fix I agree. This was an old idea that doesn't fit any more. > Automatically wrap watir commands in a test case > ------------------------------------------------ > > Key: WTR-129 > URL: http://jira.openqa.org/browse/WTR-129 > Project: Watir > Issue Type: New Feature > Reporter: Bret Pettichord > Priority: Major > Fix For: Future > > > Simple test case > class MyTest < Watir::TestCase > def my_test > goto('http://www.google.com') > text_field(:name, 'q').set 'ruby' > button(:name, 'btnG').click > assert(text.include? 'pickaxe') > end > end > Putting it all together > test1.rb: > goto('http://www.google.com') > text_field(:name, 'q').set 'ruby' > button(:name, 'btnG').click > assert(text.include? 'pickaxe') > test2.rb: > goto('http://www.google.com') > text_field(:name, 'q').set 'watir' > button(:name, 'btnG').click > assert(text.include? 'Holy Grail') > From the command line: > > watir -t test*.rb > This would automatically run the tests, creating a testcase wrapper for each test and then executing the combined suite. > Reusing browsers between tests > The "automatic" test suites will reuse a browser between tests, blanking the window, and recreate it if necessary. This is really the best way to use Watir. > * Possibly provide option to close and reopen between tests, but this is hard to make reliable! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sun Oct 3 20:50:30 2010 From: watirjira at gmail.com (Bret Pettichord (JIRA)) Date: Sun, 3 Oct 2010 19:50:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-403) JSSh documentation for Firefox Message-ID: <29366911.1106.1286153430554.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19887#action_19887 ] Bret Pettichord commented on WTR-403: ------------------------------------- I did a google search and quickly found this link (which is linked to from the Watir Wiki). http://www.stanleyshilov.com/blog/compile-firefox-jssh-ubuntu-9-10-64bit-ruby-watir/ Not sure what kind of documentation the Original Poster was looking for, but this seems pretty good. > JSSh documentation for Firefox > ------------------------------ > > Key: WTR-403 > URL: http://jira.openqa.org/browse/WTR-403 > Project: Watir > Issue Type: Bug > Components: FireWatir > Affects Versions: Open QA Migration > Environment: any > Reporter: Zeljko > > - moved from http://code.google.com/p/firewatir/issues/detail?id=85 > Issue 85: JSSh documentation for Firefox > 1 person starred this issue and may be notified of changes. > Status: New > Owner: ---- > Reported by mdhv1974, Jun 28, 2009 > What steps will reproduce the problem? > 1. Search web for JSSh documentation and it points to > http://www.croczilla.com/jssh. The link when clicked, always > returns "Resource not found" > Can anyone help with the said documents or provide a link? > Regards > Babu -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sun Oct 3 21:44:30 2010 From: watirjira at gmail.com (Bret Pettichord (JIRA)) Date: Sun, 3 Oct 2010 20:44:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-166) Wait for XHRs and timers to complete before considering the page loaded (either as a configurable option or always on) Message-ID: <27821282.1109.1286156670728.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19888#action_19888 ] Bret Pettichord commented on WTR-166: ------------------------------------- I still think we need to add a hook to the wait method. Actually, we have such a hook, in a way, and I've been using it at Convio. It is the "add_checker" method. This adds a method that is run after wait runs, but you could write a method (as I have) that waits for addition shit to happen in the browser before releasing control. So, I guess we could resolve this just by writing some documentation about how the existing add_checker method could be used to add custom wait logic. I guess I'm signging up to write this documentation. > Wait for XHRs and timers to complete before considering the page loaded (either as a configurable option or always on) > ---------------------------------------------------------------------------------------------------------------------- > > Key: WTR-166 > URL: http://jira.openqa.org/browse/WTR-166 > Project: Watir > Issue Type: New Feature > Components: Wait > Affects Versions: 1.5.0/1.5.1 > Environment: x > Reporter: Jeff Fry > Priority: Major > Fix For: Next > > > Watir.wait() listens to whether IE thinks its done loading, and then checks to see that the main document and any sub documents/frames have finished loading. More and more, there are pages that on load also kick off various XHRs and timers. For me - and possibly for a growing number of folks, testing more AJAXy applications - it would be great to expand wait() to check if there are any XHRs or timers pending, in additional to the checks it currently makes. > Note, I don't know, but there may be applications where an XHR is intentionally left open at all times. If this happens I would guess that it's rare, but if we change the default behavior of watir.wait() to wait for pending XHRs and timers, we might want to give a config option that turns this off as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sun Oct 3 21:44:30 2010 From: watirjira at gmail.com (Bret Pettichord (JIRA)) Date: Sun, 3 Oct 2010 20:44:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-166) Document how to use the add_checker method to add custom wait logic to Watir Message-ID: <27268196.1112.1286156670804.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret Pettichord updated WTR-166: -------------------------------- Summary: Document how to use the add_checker method to add custom wait logic to Watir (was: Wait for XHRs and timers to complete before considering the page loaded (either as a configurable option or always on)) > Document how to use the add_checker method to add custom wait logic to Watir > ---------------------------------------------------------------------------- > > Key: WTR-166 > URL: http://jira.openqa.org/browse/WTR-166 > Project: Watir > Issue Type: New Feature > Components: Wait > Affects Versions: 1.5.0/1.5.1 > Environment: x > Reporter: Jeff Fry > Priority: Major > Fix For: Next > > > Watir.wait() listens to whether IE thinks its done loading, and then checks to see that the main document and any sub documents/frames have finished loading. More and more, there are pages that on load also kick off various XHRs and timers. For me - and possibly for a growing number of folks, testing more AJAXy applications - it would be great to expand wait() to check if there are any XHRs or timers pending, in additional to the checks it currently makes. > Note, I don't know, but there may be applications where an XHR is intentionally left open at all times. If this happens I would guess that it's rare, but if we change the default behavior of watir.wait() to wait for pending XHRs and timers, we might want to give a config option that turns this off as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sun Oct 3 21:46:30 2010 From: watirjira at gmail.com (Bret Pettichord (JIRA)) Date: Sun, 3 Oct 2010 20:46:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Assigned: (WTR-166) Document how to use the add_checker method to add custom wait logic to Watir Message-ID: <4007368.1116.1286156790605.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret Pettichord reassigned WTR-166: ----------------------------------- Assignee: Bret Pettichord > Document how to use the add_checker method to add custom wait logic to Watir > ---------------------------------------------------------------------------- > > Key: WTR-166 > URL: http://jira.openqa.org/browse/WTR-166 > Project: Watir > Issue Type: New Feature > Components: Wait > Affects Versions: 1.5.0/1.5.1 > Environment: x > Reporter: Jeff Fry > Assignee: Bret Pettichord > Priority: Major > Fix For: Next > > > Watir.wait() listens to whether IE thinks its done loading, and then checks to see that the main document and any sub documents/frames have finished loading. More and more, there are pages that on load also kick off various XHRs and timers. For me - and possibly for a growing number of folks, testing more AJAXy applications - it would be great to expand wait() to check if there are any XHRs or timers pending, in additional to the checks it currently makes. > Note, I don't know, but there may be applications where an XHR is intentionally left open at all times. If this happens I would guess that it's rare, but if we change the default behavior of watir.wait() to wait for pending XHRs and timers, we might want to give a config option that turns this off as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Mon Oct 4 02:36:31 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Mon, 4 Oct 2010 01:36:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-166) Document how to use the add_checker method to add custom wait logic to Watir Message-ID: <22563603.1121.1286174191961.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19889#action_19889 ] Jarmo Pertman commented on WTR-166: ----------------------------------- I don't think you can do it easily with add_checker because every page behaves differently having different conditions to be met. I'd recomment using wait_until and similar things to play in here. Jari made few nice additions to current Waiter.wait_until in his Watir-WebDriver project, which i'd like to incorporate into Watir (with minor changes) also. It's also ok by Jari. Here are some examples: http://github.com/jarib/watir-webdriver/wiki/FAQ Here is the code itself: http://github.com/jarib/watir-webdriver/blob/master/lib/watir-webdriver/extensions/wait.rb And then we could document using these methods. What do you think? If it's ok, i'll gonna do it soon. > Document how to use the add_checker method to add custom wait logic to Watir > ---------------------------------------------------------------------------- > > Key: WTR-166 > URL: http://jira.openqa.org/browse/WTR-166 > Project: Watir > Issue Type: New Feature > Components: Wait > Affects Versions: 1.5.0/1.5.1 > Environment: x > Reporter: Jeff Fry > Assignee: Bret Pettichord > Priority: Major > Fix For: Next > > > Watir.wait() listens to whether IE thinks its done loading, and then checks to see that the main document and any sub documents/frames have finished loading. More and more, there are pages that on load also kick off various XHRs and timers. For me - and possibly for a growing number of folks, testing more AJAXy applications - it would be great to expand wait() to check if there are any XHRs or timers pending, in additional to the checks it currently makes. > Note, I don't know, but there may be applications where an XHR is intentionally left open at all times. If this happens I would guess that it's rare, but if we change the default behavior of watir.wait() to wait for pending XHRs and timers, we might want to give a config option that turns this off as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Mon Oct 4 04:07:30 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Mon, 4 Oct 2010 03:07:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-409) install for 1.6.2 doesn't work after 1.6.5 release Message-ID: <1150145.1124.1286179650950.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19890#action_19890 ] Zeljko commented on WTR-409: ---------------------------- If Alan does not complain in a few days I would close the ticket. > install for 1.6.2 doesn't work after 1.6.5 release > -------------------------------------------------- > > Key: WTR-409 > URL: http://jira.openqa.org/browse/WTR-409 > Project: Watir > Issue Type: Bug > Components: Gem installer > Affects Versions: 1.6.2 > Environment: windows > Reporter: Alan Baird > Assignee: Charley Baker > Priority: Critical > Fix For: 1.6.3 > > > This morning I was helping a coworker get some things up and running with watir and noticed that he had inadvertently got 1.6.5. Since 1.6.5 changes the way .visible? works, we decided to go back to 1.6.2 and make sure everything was ok there. We removed watir, commonwatir and firewatir and verified that everything was uninstalled. After that, we did the following: > C:\ >gem install watir -v 1.6.2 > ERROR: Error installing watir: > firewatir requires commonwatir (= 1.6.5, runtime) > C:\ >gem list --local > *** LOCAL GEMS *** > (removed unnecessary gems) > ... > commonwatir (1.6.2) > ... > C:\ >gem install firewatir -v 1.6.2 > Successfully installed firewatir-1.6.2 > 1 gem installed > Installing ri documentation for firewatir-1.6.2... > Installing RDoc documentation for firewatir-1.6.2... > C:\ >gem install watir -v 1.6.2 > Successfully installed watir-1.6.2 > 1 gem installed > Installing ri documentation for watir-1.6.2... > Installing RDoc documentation for watir-1.6.2... > So, to me it seems that there is a gem dependency in the firewatir install for commonwatir 1.6.5 (or maybe it's just the latest version). > What do you think? > Alan > For complete discussion, see http://groups.google.com/group/watir-general/browse_thread/thread/ee8e1abadb533b61?tvc=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Mon Oct 4 04:17:30 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Mon, 4 Oct 2010 03:17:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-403) JSSh documentation for Firefox Message-ID: <18262850.1126.1286180250656.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19891#action_19891 ] Zeljko commented on WTR-403: ---------------------------- jssh is dead: http://groups.google.com/group/watir-general/browse_thread/thread/17fa95d02e376250/ I vote for closing this ticket. > JSSh documentation for Firefox > ------------------------------ > > Key: WTR-403 > URL: http://jira.openqa.org/browse/WTR-403 > Project: Watir > Issue Type: Bug > Components: FireWatir > Affects Versions: Open QA Migration > Environment: any > Reporter: Zeljko > > - moved from http://code.google.com/p/firewatir/issues/detail?id=85 > Issue 85: JSSh documentation for Firefox > 1 person starred this issue and may be notified of changes. > Status: New > Owner: ---- > Reported by mdhv1974, Jun 28, 2009 > What steps will reproduce the problem? > 1. Search web for JSSh documentation and it points to > http://www.croczilla.com/jssh. The link when clicked, always > returns "Resource not found" > Can anyone help with the said documents or provide a link? > Regards > Babu -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Mon Oct 4 04:25:30 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Mon, 4 Oct 2010 03:25:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-154) Remove :beforeText and :afterText Message-ID: <14484896.1128.1286180730644.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19892#action_19892 ] Zeljko commented on WTR-154: ---------------------------- I vote for closing. If it stays it should be moved to contrib. > Remove :beforeText and :afterText > --------------------------------- > > Key: WTR-154 > URL: http://jira.openqa.org/browse/WTR-154 > Project: Watir > Issue Type: Improvement > Components: HTML Controls > Reporter: Bret Pettichord > Fix For: Soon > > > These don't seem to work the way people expect and won't port to Firewatir, etc anyway. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Mon Oct 4 09:17:31 2010 From: watirjira at gmail.com (Alan Baird (JIRA)) Date: Mon, 4 Oct 2010 08:17:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-409) install for 1.6.2 doesn't work after 1.6.5 release Message-ID: <32192833.1131.1286198251266.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Baird closed WTR-409. -------------------------- Resolution: Fixed I don't think people are going to be affected by this anymore. > install for 1.6.2 doesn't work after 1.6.5 release > -------------------------------------------------- > > Key: WTR-409 > URL: http://jira.openqa.org/browse/WTR-409 > Project: Watir > Issue Type: Bug > Components: Gem installer > Affects Versions: 1.6.2 > Environment: windows > Reporter: Alan Baird > Assignee: Charley Baker > Priority: Critical > Fix For: 1.6.3 > > > This morning I was helping a coworker get some things up and running with watir and noticed that he had inadvertently got 1.6.5. Since 1.6.5 changes the way .visible? works, we decided to go back to 1.6.2 and make sure everything was ok there. We removed watir, commonwatir and firewatir and verified that everything was uninstalled. After that, we did the following: > C:\ >gem install watir -v 1.6.2 > ERROR: Error installing watir: > firewatir requires commonwatir (= 1.6.5, runtime) > C:\ >gem list --local > *** LOCAL GEMS *** > (removed unnecessary gems) > ... > commonwatir (1.6.2) > ... > C:\ >gem install firewatir -v 1.6.2 > Successfully installed firewatir-1.6.2 > 1 gem installed > Installing ri documentation for firewatir-1.6.2... > Installing RDoc documentation for firewatir-1.6.2... > C:\ >gem install watir -v 1.6.2 > Successfully installed watir-1.6.2 > 1 gem installed > Installing ri documentation for watir-1.6.2... > Installing RDoc documentation for watir-1.6.2... > So, to me it seems that there is a gem dependency in the firewatir install for commonwatir 1.6.5 (or maybe it's just the latest version). > What do you think? > Alan > For complete discussion, see http://groups.google.com/group/watir-general/browse_thread/thread/ee8e1abadb533b61?tvc=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Mon Oct 4 09:48:30 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Mon, 4 Oct 2010 08:48:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-403) JSSh documentation for Firefox Message-ID: <11969849.1134.1286200110584.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker closed WTR-403. ----------------------------- Resolution: Fixed Closing based on comments. > JSSh documentation for Firefox > ------------------------------ > > Key: WTR-403 > URL: http://jira.openqa.org/browse/WTR-403 > Project: Watir > Issue Type: Bug > Components: FireWatir > Affects Versions: Open QA Migration > Environment: any > Reporter: Zeljko > > - moved from http://code.google.com/p/firewatir/issues/detail?id=85 > Issue 85: JSSh documentation for Firefox > 1 person starred this issue and may be notified of changes. > Status: New > Owner: ---- > Reported by mdhv1974, Jun 28, 2009 > What steps will reproduce the problem? > 1. Search web for JSSh documentation and it points to > http://www.croczilla.com/jssh. The link when clicked, always > returns "Resource not found" > Can anyone help with the said documents or provide a link? > Regards > Babu -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From zeljko.filipin at wa-research.ch Mon Oct 4 10:16:07 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Mon, 4 Oct 2010 16:16:07 +0200 Subject: [Wtr-development] [wtr-general] Watir 1.6.6 final released In-Reply-To: References: Message-ID: On Sun, Oct 3, 2010 at 8:35 PM, Charley Baker wrote: > We are happy to announce that a (very) long-waited (Fire)Watir > 1.6.6 final gem is out! Feel free to spread the word: http://watir.com/2010/10/04/watir-1-6-6-final-released/ http://twitter.com/#!/watir/status/26364215500 ?eljko -- watir.com - community manager watirpodcast.com - host testingpodcast.com - audio podcasts on software testing. all of them -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Mon Oct 4 10:47:29 2010 From: jarmo.p at gmail.com (Jarmo) Date: Mon, 4 Oct 2010 17:47:29 +0300 Subject: [Wtr-development] [wtr-general] Watir 1.6.6 final released In-Reply-To: References: Message-ID: Ok, congratulations to everyone! So, maybe it's time to think about agenda of 1.6.7? I have these things in my mind: 1) remove ActiveSupport dependency in FireWatir 2) add convenience methods for waiting by Jari (http://github.com/jarib/watir-webdriver/blob/master/lib/watir-webdriver/extensions/wait.rb) 3) add support for newer rubies... this could be bigger goal and done in step-by-step because it won't be too easy to do i'm afraid 4) fix/close bugs in jira :) 5) cleanup repos That's all i can think of right now. Any other ideas/propositions? Jarmo On Mon, Oct 4, 2010 at 5:16 PM, ?eljko Filipin wrote: > On Sun, Oct 3, 2010 at 8:35 PM, Charley Baker > wrote: >> We are happy to announce that a (very) long-waited (Fire)Watir >> 1.6.6 final gem is out! > > Feel free to spread the word: > > http://watir.com/2010/10/04/watir-1-6-6-final-released/ > http://twitter.com/#!/watir/status/26364215500 > > ?eljko > -- > watir.com - community manager > watirpodcast.com - host > testingpodcast.com - audio podcasts on software testing. all of them > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From zeljko.filipin at wa-research.ch Mon Oct 4 11:06:57 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Mon, 4 Oct 2010 17:06:57 +0200 Subject: [Wtr-development] doc folder In-Reply-To: References: Message-ID: On Wed, Sep 29, 2010 at 12:48 PM, Jarmo wrote: > But without checking that it isn't really anywhere in use > i cannot guarantee that it really isn't. There might be some sneaky > rake task or whatever :) Deleted doc folder. Found two references: http://github.com/bret/watir/blob/master/watir/rakefile.rb http://github.com/bret/watir/blob/master/watir/installer/watir_installer.nsi Fixed rakefile, ignoring installer since I plan to delete it next. http://github.com/bret/watir/pull/10 ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Mon Oct 4 11:10:15 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Mon, 4 Oct 2010 17:10:15 +0200 Subject: [Wtr-development] source cleanup In-Reply-To: References: Message-ID: On Fri, Oct 1, 2010 at 7:46 PM, Bret Pettichord wrote: > The transform result was used for the CI results. I don't think there are any plans to resuscitate this. My company has servers. Maybe we could host CI for Watir. What do we need for that? ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Mon Oct 4 11:11:36 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Mon, 4 Oct 2010 17:11:36 +0200 Subject: [Wtr-development] source cleanup In-Reply-To: References: Message-ID: On Sat, Oct 2, 2010 at 11:29 AM, Jarmo wrote: > I forgot to mention that if we want to deal with these license > problems properly then it's not as easy as asking from just license > holders since we have there 2 types of licenses - BSD and MIT. I will take a closer look at licenses. I thought they were just copy/pasted. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Mon Oct 4 11:16:45 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Mon, 4 Oct 2010 17:16:45 +0200 Subject: [Wtr-development] source cleanup In-Reply-To: References: Message-ID: On Fri, Oct 1, 2010 at 7:46 PM, Bret Pettichord wrote: >> 2) Should we delete installer folder? >> >> http://github.com/bret/watir/tree/1.6.5.rc2/watir/installer/ > > Yes http://github.com/bret/watir/pull/11 ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Mon Oct 4 13:48:30 2010 From: watirjira at gmail.com (Ethan (JIRA)) Date: Mon, 4 Oct 2010 12:48:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-154) Remove :beforeText and :afterText Message-ID: <6284427.1137.1286214510719.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19895#action_19895 ] Ethan commented on WTR-154: --------------------------- These methods are named quite the opposite of what's intuitive. beforeText does not return the text before the element, it returns the text after the end of the element (implementation is getAdjacentText("afterEnd")) and afterText returns the text before the element (getAdjacentText("beforeBegin")). makes no sense and they should be deprecated. the functionality itself is useful, and you'll get complaints if it's removed. I've reimplemented this in vapir with names that make sense, see: http://github.com/vapir/vapir/blob/3791a7a1f6d3c760cf94387f19bfb19b8ccb33e5/vapir-ie/lib/vapir-ie/element.rb#L44 lines 44-70. > Remove :beforeText and :afterText > --------------------------------- > > Key: WTR-154 > URL: http://jira.openqa.org/browse/WTR-154 > Project: Watir > Issue Type: Improvement > Components: HTML Controls > Reporter: Bret Pettichord > Fix For: Soon > > > These don't seem to work the way people expect and won't port to Firewatir, etc anyway. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From bret at pettichord.com Mon Oct 4 14:10:52 2010 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 4 Oct 2010 13:10:52 -0500 Subject: [Wtr-development] [wtr-general] Watir 1.6.6 final released In-Reply-To: References: Message-ID: I would like to help out with the cleanup. Much of this is old stuff, and stuff that I remember adding or at least being around when it was added, so can probably be helpful in deciding whether to remove it. I am seeing that this clutter interferes with getting new people to understand our code, so am thus motivated to help clean house, and review pull requests in this area. So, that's about reducing the clutter from the repo -- removing stuff we aren't using any more, and reducing duplication. But there is also the matter of old methods that mostly aren't being use. We need to look at deprecating these. I'd like to help with this, either removing marginal functionality or marking as deprecated, to see if anyone still cares about it. The other thing I want to do is to complete the merge of the convio version of watir -- both the stuff in the branch (which is already merged, i think) and the stuff in the extensions. I expect to have time for this in November, so I'm not sure if that fits in 1.6.7 or a later version. Bret On Mon, Oct 4, 2010 at 9:47 AM, Jarmo wrote: > Ok, congratulations to everyone! > > So, maybe it's time to think about agenda of 1.6.7? > > I have these things in my mind: > 1) remove ActiveSupport dependency in FireWatir > 2) add convenience methods for waiting by Jari > ( > http://github.com/jarib/watir-webdriver/blob/master/lib/watir-webdriver/extensions/wait.rb > ) > 3) add support for newer rubies... this could be bigger goal and done > in step-by-step because it won't be too easy to do i'm afraid > 4) fix/close bugs in jira :) > 5) cleanup repos > > That's all i can think of right now. Any other ideas/propositions? > > Jarmo > > On Mon, Oct 4, 2010 at 5:16 PM, ?eljko Filipin > wrote: > > On Sun, Oct 3, 2010 at 8:35 PM, Charley Baker > > wrote: > >> We are happy to announce that a (very) long-waited (Fire)Watir > >> 1.6.6 final gem is out! > > > > Feel free to spread the word: > > > > http://watir.com/2010/10/04/watir-1-6-6-final-released/ > > http://twitter.com/#!/watir/status/26364215500 > > > > ?eljko > > -- > > watir.com - community manager > > watirpodcast.com - host > > testingpodcast.com - audio podcasts on software testing. all of them > > > > > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Mon Oct 4 15:46:31 2010 From: watirjira at gmail.com (Jeff Fry (JIRA)) Date: Mon, 4 Oct 2010 14:46:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-166) Document how to use the add_checker method to add custom wait logic to Watir Message-ID: <26093806.1141.1286221591922.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19896#action_19896 ] Jeff Fry commented on WTR-166: ------------------------------ Jarmo, in situations where what you're waiting for on each page is a different condition, that's the right choice...but there's another way to go, and that's what this was filed to handle. If an application chooses to expose whether or not there's an XHR or timer running, as a testability feature, it's at least theoretically possible to just have Wait() Do The Right Thing. Doing this can make automation much simpler. We've done this for Freebase.com. For an example, * go to http://www.sandbox-freebase.com/view/book/book * open up firebug (FF) or Dev Tools (Chrome), and note the tag * start typing in one of the filter fields, e.g. type 'testing' into 'Filter by Name' * note that there's now an 'ajax' attribute . When an XHR or timer kicks off on the page, we set . When it completes, if this was the last ajax process running on the page, we set . This allows me to check for *one* condition, rather than guessing what are all the asych things that could be happening on the page. Bret, if you've got a way to do this today, I think it's *absolutely* worth documenting it. I'm not using Watir for work currently, but would be happy to test the change on Freebase. > Document how to use the add_checker method to add custom wait logic to Watir > ---------------------------------------------------------------------------- > > Key: WTR-166 > URL: http://jira.openqa.org/browse/WTR-166 > Project: Watir > Issue Type: New Feature > Components: Wait > Affects Versions: 1.5.0/1.5.1 > Environment: x > Reporter: Jeff Fry > Assignee: Bret Pettichord > Priority: Major > Fix For: Next > > > Watir.wait() listens to whether IE thinks its done loading, and then checks to see that the main document and any sub documents/frames have finished loading. More and more, there are pages that on load also kick off various XHRs and timers. For me - and possibly for a growing number of folks, testing more AJAXy applications - it would be great to expand wait() to check if there are any XHRs or timers pending, in additional to the checks it currently makes. > Note, I don't know, but there may be applications where an XHR is intentionally left open at all times. If this happens I would guess that it's rare, but if we change the default behavior of watir.wait() to wait for pending XHRs and timers, we might want to give a config option that turns this off as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From zeljko.filipin at wa-research.ch Tue Oct 5 05:24:38 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 5 Oct 2010 11:24:38 +0200 Subject: [Wtr-development] FireWatir Message-ID: What are the plans for FireWatir? We can not support Firefox 4 with JSSH: http://groups.google.com/group/watir-general/browse_thread/thread/17fa95d02e376250/ Is the future in deprecating FireWatir gem and using watir-webdriver to drive Firefox? ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Tue Oct 5 05:45:46 2010 From: alister.scott at gmail.com (Alister Scott) Date: Tue, 5 Oct 2010 19:45:46 +1000 Subject: [Wtr-development] FireWatir In-Reply-To: References: Message-ID: The bigger question I guess is when is watir-webdriver going to be 'official', and will watir-webdriver driving IE ever replace vanilla watir? It seems a wasted effort to throw away the work Angrez has done, but if JSSH is no longer supported, then I guess we have to. Cheers, Alister On Tue, Oct 5, 2010 at 7:24 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > What are the plans for FireWatir? > > We can not support Firefox 4 with JSSH: > > > http://groups.google.com/group/watir-general/browse_thread/thread/17fa95d02e376250/ > > Is the future in deprecating FireWatir gem and using watir-webdriver to > drive Firefox? > > ?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 Tue Oct 5 05:50:29 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 5 Oct 2010 11:50:29 +0200 Subject: [Wtr-development] FireWatir In-Reply-To: References: Message-ID: On Tue, Oct 5, 2010 at 11:45 AM, Alister Scott wrote: > will watir-webdriver driving IE ever replace vanilla watir? We could decide about IE in a few years when watir-webdriver has better support for it, but FF 4 should be out soon and we would not be able to support it with JSSH (as I understood Angrez). ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Tue Oct 5 06:04:30 2010 From: jarmo.p at gmail.com (Jarmo) Date: Tue, 5 Oct 2010 13:04:30 +0300 Subject: [Wtr-development] FireWatir In-Reply-To: References: Message-ID: Few years? No way. I'd say if watir-webdriver has watirspec specs passing then we could release 2.0 soon, where watir-webdriver would become watir with support for ie, firefox, chrome, opera, safari... i don't see much of a point keeping two separate implementations in active development... at one point we'd have to look upon differences of these two and try to remove some gaps... of course we could keep Watir 1.x branch alive by fixing bugs and such, but not adding any new features... just like with some other projects like Rails by having 2.x and 3.x currently. Just my two cents. I'd be very happy if all this would happen sooner than "in few years" :) Of course other's opinions are welcome. Jarmo On Tue, Oct 5, 2010 at 12:50 PM, ?eljko Filipin wrote: > On Tue, Oct 5, 2010 at 11:45 AM, Alister Scott > wrote: >> will watir-webdriver driving IE ever replace vanilla watir? > > We could decide about IE in a few years when watir-webdriver has better > support for it, but FF 4 should be out soon and we would not be able to > support it with JSSH (as I understood Angrez). > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From zeljko.filipin at wa-research.ch Tue Oct 5 06:29:57 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 5 Oct 2010 12:29:57 +0200 Subject: [Wtr-development] Watir Podcast #37: Jeff Lusenhop on Janova Message-ID: Charley and I talk with Jeff on Janova (part 1 of 3): http://watirpodcast.com/37-jeff-lusenhop-on-janova/ http://twitter.com/#!/watirpodcast/status/26444373519 Feel free to spread the word and comment (here, at watirpodcast.com or at Twitter). :) ?eljko -- watir.com - community manager watirpodcast.com - host testingpodcast.com - audio podcasts on software testing. all of them -------------- next part -------------- An HTML attachment was scrubbed... URL: From angrez at gmail.com Tue Oct 5 07:27:01 2010 From: angrez at gmail.com (Angrez Singh) Date: Tue, 5 Oct 2010 16:57:01 +0530 Subject: [Wtr-development] FireWatir In-Reply-To: References: Message-ID: > > We could decide about IE in a few years when watir-webdriver has better > support for it, but FF 4 should be out soon and we would not be able to > support it with JSSH (as I understood Angrez). > Thats what I got it from the Bugzilla for Firefox that it will not be supported. I am still watching the thread and see if some one else is working on it. But for the time being its yes JSSH is not supported by FF 4 - Angrez -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Tue Oct 5 08:06:04 2010 From: alister.scott at gmail.com (Alister Scott) Date: Tue, 5 Oct 2010 22:06:04 +1000 Subject: [Wtr-development] FireWatir In-Reply-To: References: Message-ID: Where is the best place to raise watir-webdriver bugs? Cheers, Alister On Tue, Oct 5, 2010 at 8:04 PM, Jarmo wrote: > Few years? No way. I'd say if watir-webdriver has watirspec specs > passing then we could release 2.0 soon, where watir-webdriver would > become watir with support for ie, firefox, chrome, opera, safari... i > don't see much of a point keeping two separate implementations in > active development... > > at one point we'd have to look upon differences of these two and try > to remove some gaps... > > of course we could keep Watir 1.x branch alive by fixing bugs and > such, but not adding any new features... just like with some other > projects like Rails by having 2.x and 3.x currently. Just my two > cents. > > I'd be very happy if all this would happen sooner than "in few years" :) > > Of course other's opinions are welcome. > > Jarmo > > On Tue, Oct 5, 2010 at 12:50 PM, ?eljko Filipin > wrote: > > On Tue, Oct 5, 2010 at 11:45 AM, Alister Scott > > wrote: > >> will watir-webdriver driving IE ever replace vanilla watir? > > > > We could decide about IE in a few years when watir-webdriver has better > > support for it, but FF 4 should be out soon and we would not be able to > > support it with JSSH (as I understood Angrez). > > > > ?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 jarmo.p at gmail.com Tue Oct 5 08:24:03 2010 From: jarmo.p at gmail.com (Jarmo) Date: Tue, 5 Oct 2010 15:24:03 +0300 Subject: [Wtr-development] FireWatir In-Reply-To: References: Message-ID: http://github.com/jarib/watir-webdriver/issues On Tue, Oct 5, 2010 at 3:06 PM, Alister Scott wrote: > Where is the best place to raise watir-webdriver bugs? > > Cheers, Alister From simon.m.stewart at gmail.com Tue Oct 5 08:28:57 2010 From: simon.m.stewart at gmail.com (Simon Stewart) Date: Tue, 5 Oct 2010 13:28:57 +0100 Subject: [Wtr-development] FireWatir In-Reply-To: References: Message-ID: This is the best place: http://code.google.com/p/selenium/issues/list If you mention that it's needed for better watir compatibility, then that really helps us when it comes to prioritizing issues. BTW, if anyone's interested in contributing to help narrow the gap between what's expected and what actually happens, I'll be happy to work with you to get the commit bit. As would Jari, I'm sure. Simon On Tue, Oct 5, 2010 at 1:06 PM, Alister Scott wrote: > Where is the best place to raise watir-webdriver bugs? > > Cheers, Alister > > On Tue, Oct 5, 2010 at 8:04 PM, Jarmo wrote: >> >> Few years? No way. I'd say if watir-webdriver has watirspec specs >> passing then we could release 2.0 soon, where watir-webdriver would >> become watir with support for ie, firefox, chrome, opera, safari... i >> don't see much of a point keeping two separate implementations in >> active development... >> >> at one point we'd have to look upon differences of these two and try >> to remove some gaps... >> >> of course we could keep Watir 1.x branch alive by fixing bugs and >> such, but not adding any new features... just like with some other >> projects like Rails by having 2.x and 3.x currently. Just my two >> cents. >> >> I'd be very happy if all this would happen sooner than "in few years" :) >> >> Of course other's opinions are welcome. >> >> Jarmo >> >> On Tue, Oct 5, 2010 at 12:50 PM, ?eljko Filipin >> wrote: >> > On Tue, Oct 5, 2010 at 11:45 AM, Alister Scott >> > wrote: >> >> will watir-webdriver driving IE ever replace vanilla watir? >> > >> > We could decide about IE in a few years when watir-webdriver has better >> > support for it, but FF 4 should be out soon and we would not be able to >> > support it with JSSH (as I understood Angrez). >> > >> > ?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 > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From zeljko.filipin at wa-research.ch Tue Oct 5 08:38:40 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 5 Oct 2010 14:38:40 +0200 Subject: [Wtr-development] FireWatir In-Reply-To: References: Message-ID: On Tue, Oct 5, 2010 at 2:06 PM, Alister Scott wrote: > Where is the best place to raise watir-webdriver bugs? http://github.com/jarib/watir-webdriver/issues ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From jari.bakken at gmail.com Tue Oct 5 09:04:48 2010 From: jari.bakken at gmail.com (Jari Bakken) Date: Tue, 5 Oct 2010 15:04:48 +0200 Subject: [Wtr-development] FireWatir In-Reply-To: References: Message-ID: On Tue, Oct 5, 2010 at 2:06 PM, Alister Scott wrote: > Where is the best place to raise watir-webdriver bugs? > If you believe the problem is in the watir-webdriver code base, use the tracker on GitHub. If you think it's in Selenium2/WebDriver, use the tracker on Google Code. If you have no idea, put it in the GitHub tracker and I'll move it if necessary. From jari.bakken at gmail.com Tue Oct 5 09:05:15 2010 From: jari.bakken at gmail.com (Jari Bakken) Date: Tue, 5 Oct 2010 15:05:15 +0200 Subject: [Wtr-development] FireWatir In-Reply-To: References: Message-ID: On Tue, Oct 5, 2010 at 2:28 PM, Simon Stewart wrote: > BTW, if anyone's interested in contributing to help narrow the gap > between what's expected and what actually happens, I'll be happy to > work with you to get the commit bit. As would Jari, I'm sure. > Absolutely! From charley.baker at gmail.com Tue Oct 5 10:20:47 2010 From: charley.baker at gmail.com (Charley Baker) Date: Tue, 5 Oct 2010 08:20:47 -0600 Subject: [Wtr-development] FireWatir In-Reply-To: References: Message-ID: Firefox support and the challenges behind JSSH were the initial impetus behind moving to support and work with Webdriver. I saw the signs more than a year ago and decided we should move in that direction. Fortunately, Jari had the time and skill to take on that work and has done an amazing job. Webdriver also has the advantage of the inimitable Simon Stewart. :) As Jarmo mentioned, Webdriver for all browsers is the plan for Watir 2.0 and 1.x will mostly fall into a maintenance mode, similar to Rails, Ruby, etc. There are enough outstanding gaps and issues in the current Watir codebase that I'd like to fix those before coming to an official stance of pure maintenance mode - the 1.6.6 release is an important milestone since it comprises fixes and features from the past year and sets the way for making it easier going forward for additional rolling releases. We still do need to focus on closing the gap between Watir 2.0 and 1.x, adding compatibility where possible, eventually docs, etc so that people who choose to migrate have a reasonable path. All of that said, the Watir userbase for 1.x is pretty substantial, so it is possible that development will continue by people who have a vested interest, hopefully focussed on backporting features from 2.0 in the future. I find myself in the unusual spot right now of having time off, so I'm not officially supporting either version of Watir for an active work related project. I do, however, keep in touch with the Gap, Facebook and other teams using Watir, all currently on 1.6.x. I'm hoping to spend some of my "free time" on Watir 2.0 as well. I think it's important that the core developers meet up and further nail down a more detailed road map soon. Anyhow, that's my 2 cents. :) Cheers, Charley Baker Lead Developer, Watir, http://watir.com On Tue, Oct 5, 2010 at 7:05 AM, Jari Bakken wrote: > On Tue, Oct 5, 2010 at 2:28 PM, Simon Stewart wrote: >> BTW, if anyone's interested in contributing to help narrow the gap >> between what's expected and what actually happens, I'll be happy to >> work with you to get the commit bit. As would Jari, I'm sure. >> > > Absolutely! > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From zeljko.filipin at wa-research.ch Tue Oct 5 10:46:29 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 5 Oct 2010 16:46:29 +0200 Subject: [Wtr-development] source cleanup In-Reply-To: References: Message-ID: On Fri, Oct 1, 2010 at 7:46 PM, Bret Pettichord wrote: >> 3) Should we delete watir-simple? >> >> http://github.com/bret/watir/blob/master/watir/lib/watir/watir_simple.rb > > Yes http://github.com/bret/watir/pull/12 ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Tue Oct 5 11:03:00 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 5 Oct 2010 17:03:00 +0200 Subject: [Wtr-development] source cleanup In-Reply-To: References: Message-ID: Deleted other unused files: http://github.com/bret/watir/pull/13 ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjq.999 at gmail.com Tue Oct 5 10:47:32 2010 From: cjq.999 at gmail.com (Wesley Chen) Date: Tue, 5 Oct 2010 22:47:32 +0800 Subject: [Wtr-development] [wtr-general] Welcome Jarmo Pertman to the core Watir team In-Reply-To: References: Message-ID: Welcome Pertman, another great guy! I think Watir will be more powerful and attractive! Wesley. For life, the easier, the better. On Mon, Sep 27, 2010 at 4:56 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > Jarmo, > > welcome to the team! :) > > One comment inline. > > > On Fri, Sep 24, 2010 at 11:26 PM, Charley Baker > wrote: > > I'd recommend anyone doing Watir testing to also do a podcast with > Zeljko > > +1 :) > > ?eljko > > -- > Before posting, please read http://watir.com/support. In short: search > before you ask, be nice. > > watir-general at googlegroups.com > > http://groups.google.com/group/watir-general > watir-general+unsubscribe at googlegroups.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Wed Oct 6 09:24:51 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 6 Oct 2010 15:24:51 +0200 Subject: [Wtr-development] source cleanup In-Reply-To: References: Message-ID: On Sat, Oct 2, 2010 at 11:29 AM, Jarmo wrote: > I forgot to mention that if we want to deal with these license > problems properly then it's not as easy as asking from just license > holders since we have there 2 types of licenses - BSD and MIT. I took a look at licenses. Original files: http://github.com/bret/watir/blob/master/watir/lib/watir/ie.rb http://github.com/bret/watir/blob/master/firewatir/LICENSE http://github.com/bret/watir/blob/master/commonwatir/LICENSE http://github.com/bret/watir/blob/master/watir/lib/license.rb http://github.com/bret/watir/blob/master/watir/lib/watir/winClicker.rb I have moved all files to root and renamed them so I could track them. I have fixed just the formatting, so it is easier to compare. I did not change anything in license text (feel free to diff). New files: http://github.com/zeljkofilipin/watir/blob/license/license-ie http://github.com/zeljkofilipin/watir/blob/license/license-firewatir http://github.com/zeljkofilipin/watir/blob/license/license-commonwatir http://github.com/zeljkofilipin/watir/blob/license/license-rb http://github.com/zeljkofilipin/watir/blob/license/license-winclicker My Mac file compare app (/Developer/Applications/Utilities/FileMerge.app) says there is almost no difference between the files). Commonwatir has MIT instead of BSD license, but Bret said he did it by mistake: http://rubyforge.org/pipermail/wtr-development/2010-March/001632.html I suggest we delete all license text from original files and use just this file: http://github.com/zeljkofilipin/watir/blob/license/LICENSE Line 23 is longer than 80 characters, I did not want to mess with that at the moment to make it easier to diff. License text is almost identical, there is missing word here and there: "nor" "any other", "All rights reserved.", "other". Feel free to diff. Files have different copyright headers, so LICENSE file has all of them. Source of each line is in parenthesis, that should be cleaned up, but I am not sure what to do. Bret, Paul, Angrez, what should I do? Should we update copyright years? The latest is 2009. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Wed Oct 6 11:08:08 2010 From: jarmo.p at gmail.com (Jarmo) Date: Wed, 6 Oct 2010 18:08:08 +0300 Subject: [Wtr-development] recent merges and CHANGES Message-ID: Hi! I've noticed quite many pull requests and merges lately (mostly made by ?eljko). I'd like to remind all of you that it would be easier to add those things into CHANGES right now than later. Especially these changes which might affect end user (like deleting watir-simple) and so on. Jarmo From bret at pettichord.com Wed Oct 6 12:13:56 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 6 Oct 2010 11:13:56 -0500 Subject: [Wtr-development] FireWatir In-Reply-To: References: Message-ID: Well put. Bret On Tue, Oct 5, 2010 at 9:20 AM, Charley Baker wrote: > Firefox support and the challenges behind JSSH were the initial > impetus behind moving to support and work with Webdriver. I saw the > signs more than a year ago and decided we should move in that > direction. Fortunately, Jari had the time and skill to take on that > work and has done an amazing job. Webdriver also has the advantage of > the inimitable Simon Stewart. :) > > As Jarmo mentioned, Webdriver for all browsers is the plan for Watir > 2.0 and 1.x will mostly fall into a maintenance mode, similar to > Rails, Ruby, etc. There are enough outstanding gaps and issues in the > current Watir codebase that I'd like to fix those before coming to an > official stance of pure maintenance mode - the 1.6.6 release is an > important milestone since it comprises fixes and features from the > past year and sets the way for making it easier going forward for > additional rolling releases. > > We still do need to focus on closing the gap between Watir 2.0 and > 1.x, adding compatibility where possible, eventually docs, etc so that > people who choose to migrate have a reasonable path. > > All of that said, the Watir userbase for 1.x is pretty substantial, > so it is possible that development will continue by people who have a > vested interest, hopefully focussed on backporting features from 2.0 > in the future. > > I find myself in the unusual spot right now of having time off, so > I'm not officially supporting either version of Watir for an active > work related project. I do, however, keep in touch with the Gap, > Facebook and other teams using Watir, all currently on 1.6.x. I'm > hoping to spend some of my "free time" on Watir 2.0 as well. I think > it's important that the core developers meet up and further nail down > a more detailed road map soon. > > Anyhow, that's my 2 cents. :) > > Cheers, > > Charley Baker > Lead Developer, Watir, http://watir.com > > > > On Tue, Oct 5, 2010 at 7:05 AM, Jari Bakken wrote: > > On Tue, Oct 5, 2010 at 2:28 PM, Simon Stewart > wrote: > >> BTW, if anyone's interested in contributing to help narrow the gap > >> between what's expected and what actually happens, I'll be happy to > >> work with you to get the commit bit. As would Jari, I'm sure. > >> > > > > Absolutely! > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Wed Oct 6 14:18:53 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 6 Oct 2010 13:18:53 -0500 Subject: [Wtr-development] recent merges and CHANGES In-Reply-To: References: Message-ID: This is good advice, which I know I need to follow as well. To help get us to be more disciplined, let's all agree not to merge in pull requests that don't include appropriate updates to CHANGES. Bret On Wed, Oct 6, 2010 at 10:08 AM, Jarmo wrote: > Hi! > > I've noticed quite many pull requests and merges lately (mostly made > by ?eljko). I'd like to remind all of you that it would be easier to > add those things into CHANGES right now than later. Especially these > changes which might affect end user (like deleting watir-simple) and > so on. > > Jarmo > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Wed Oct 6 14:35:46 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 6 Oct 2010 13:35:46 -0500 Subject: [Wtr-development] source cleanup In-Reply-To: References: Message-ID: Use this: Copyright (c) 2004 - 2006, Paul Rogers Copyright (c) 2006 - 2007, Angrez Singh Copyright (c) 2004 - 2010, Bret Pettichord On Wed, Oct 6, 2010 at 8:24 AM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Sat, Oct 2, 2010 at 11:29 AM, Jarmo wrote: > > I forgot to mention that if we want to deal with these license > > problems properly then it's not as easy as asking from just license > > holders since we have there 2 types of licenses - BSD and MIT. > > I took a look at licenses. Original files: > > > http://github.com/bret/watir/blob/master/watir/lib/watir/ie.rb > http://github.com/bret/watir/blob/master/firewatir/LICENSE > http://github.com/bret/watir/blob/master/commonwatir/LICENSE > http://github.com/bret/watir/blob/master/watir/lib/license.rb > http://github.com/bret/watir/blob/master/watir/lib/watir/winClicker.rb > > I have moved all files to root and renamed them so I could track them. I > have fixed just the formatting, so it is easier to compare. I did not change > anything in license text (feel free to diff). New files: > > http://github.com/zeljkofilipin/watir/blob/license/license-ie > http://github.com/zeljkofilipin/watir/blob/license/license-firewatir > http://github.com/zeljkofilipin/watir/blob/license/license-commonwatir > http://github.com/zeljkofilipin/watir/blob/license/license-rb > http://github.com/zeljkofilipin/watir/blob/license/license-winclicker > > My Mac file compare app (/Developer/Applications/Utilities/FileMerge.app) > says there is almost no difference between the files). Commonwatir has MIT > instead of BSD license, but Bret said he did it by mistake: > > http://rubyforge.org/pipermail/wtr-development/2010-March/001632.html > > I suggest we delete all license text from original files and use just this > file: > > http://github.com/zeljkofilipin/watir/blob/license/LICENSE > > Line 23 is longer than 80 characters, I did not want to mess with that at > the moment to make it easier to diff. > > License text is almost identical, there is missing word here and there: > "nor" "any other", "All rights reserved.", "other". Feel free to diff. > > Files have different copyright headers, so LICENSE file has all of them. > Source of each line is in parenthesis, that should be cleaned up, but I am > not sure what to do. > > Bret, Paul, Angrez, what should I do? Should we update copyright years? The > latest is 2009. > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Wed Oct 6 15:15:10 2010 From: jarmo.p at gmail.com (Jarmo) Date: Wed, 6 Oct 2010 22:15:10 +0300 Subject: [Wtr-development] recent merges and CHANGES In-Reply-To: References: Message-ID: Or we (and you) can add those CHANGES also. It's not that hard if you've reviewed the commits anyway and everything should not end up in CHANGES anyway (i mean, who cares that CVS revisions have been removed from the files, for example) so i think that it's not that good idea to force it or anything. Just saying that it's easier to keep it up to date right now than start filling in the gaps later. Jarmo On Wed, Oct 6, 2010 at 9:18 PM, Bret Pettichord wrote: > This is good advice, which I know I need to follow as well. > > To help get us to be more disciplined, let's all agree not to merge in pull > requests that don't include appropriate updates to CHANGES. > > Bret > > On Wed, Oct 6, 2010 at 10:08 AM, Jarmo wrote: >> >> Hi! >> >> I've noticed quite many pull requests and merges lately (mostly made >> by ?eljko). I'd like to remind all of you that it would be easier to >> add those things into CHANGES right now than later. Especially these >> changes which might affect end user (like deleting watir-simple) and >> so on. >> >> Jarmo >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From charley.baker at gmail.com Wed Oct 6 15:38:55 2010 From: charley.baker at gmail.com (Charley Baker) Date: Wed, 6 Oct 2010 13:38:55 -0600 Subject: [Wtr-development] recent merges and CHANGES In-Reply-To: References: Message-ID: Agreed. This is something I need to remind myself of as well. Charley Baker Lead Developer, Watir, http://watir.com On Wed, Oct 6, 2010 at 1:15 PM, Jarmo wrote: > Or we (and you) can add those CHANGES also. It's not that hard if > you've reviewed the commits anyway and everything should not end up in > CHANGES anyway (i mean, who cares that CVS revisions have been removed > from the files, for example) so i think that it's not that good idea > to force it or anything. Just saying that it's easier to keep it up to > date right now than start filling in the gaps later. > > Jarmo > > On Wed, Oct 6, 2010 at 9:18 PM, Bret Pettichord wrote: >> This is good advice, which I know I need to follow as well. >> >> To help get us to be more disciplined, let's all agree not to merge in pull >> requests that don't include appropriate updates to CHANGES. >> >> Bret >> >> On Wed, Oct 6, 2010 at 10:08 AM, Jarmo wrote: >>> >>> Hi! >>> >>> I've noticed quite many pull requests and merges lately (mostly made >>> by ?eljko). I'd like to remind all of you that it would be easier to >>> add those things into CHANGES right now than later. Especially these >>> changes which might affect end user (like deleting watir-simple) and >>> so on. >>> >>> Jarmo >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >> >> >> -- >> Bret Pettichord >> Lead Developer, Watir, www.watir.com >> >> Blog, www.io.com/~wazmo/blog >> Twitter, www.twitter.com/bpettichord >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development From bret at pettichord.com Wed Oct 6 15:48:55 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 6 Oct 2010 14:48:55 -0500 Subject: [Wtr-development] recent merges and CHANGES In-Reply-To: References: Message-ID: OK On Wed, Oct 6, 2010 at 2:15 PM, Jarmo wrote: > Or we (and you) can add those CHANGES also. It's not that hard if > you've reviewed the commits anyway and everything should not end up in > CHANGES anyway (i mean, who cares that CVS revisions have been removed > from the files, for example) so i think that it's not that good idea > to force it or anything. Just saying that it's easier to keep it up to > date right now than start filling in the gaps later. > > Jarmo > > On Wed, Oct 6, 2010 at 9:18 PM, Bret Pettichord > wrote: > > This is good advice, which I know I need to follow as well. > > > > To help get us to be more disciplined, let's all agree not to merge in > pull > > requests that don't include appropriate updates to CHANGES. > > > > Bret > > > > On Wed, Oct 6, 2010 at 10:08 AM, Jarmo wrote: > >> > >> Hi! > >> > >> I've noticed quite many pull requests and merges lately (mostly made > >> by ?eljko). I'd like to remind all of you that it would be easier to > >> add those things into CHANGES right now than later. Especially these > >> changes which might affect end user (like deleting watir-simple) and > >> so on. > >> > >> Jarmo > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > > > -- > > Bret Pettichord > > Lead Developer, Watir, www.watir.com > > > > Blog, www.io.com/~wazmo/blog > > Twitter, www.twitter.com/bpettichord > > > > > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Wed Oct 6 17:35:30 2010 From: watirjira at gmail.com (Shaivya Mahajan (JIRA)) Date: Wed, 6 Oct 2010 16:35:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-235) Xpath.exist returns different results in Watir and Firewatir. Message-ID: <2890572.1163.1286400930900.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19898#action_19898 ] Shaivya Mahajan commented on WTR-235: ------------------------------------- I was having some trouble with firewatir and xpath giving unexpected results. Found this page when searching for answer, and I was able to reproduce this issue with the following code (running waiter 1.6.5): ------------ require "watir" site = "http://cukes.info" ie = Watir::IE.new ff = FireWatir::Firefox.new ie.goto site ff.goto site puts "IE: ",ie.div(:xpath, "//div[@class='inner']/").exists? puts "FF: ",ff.div(:xpath, "//div[@class='inner']/").exists? ------------ output i get is: IE: true FF: false > Xpath.exist returns different results in Watir and Firewatir. > ------------------------------------------------------------- > > Key: WTR-235 > URL: http://jira.openqa.org/browse/WTR-235 > Project: Watir > Issue Type: Bug > Components: FireWatir > Environment: WinXP Prof SP2, Ruby 1.8, Watir 1.5.6 and Firewatir 1.2.0 > Reporter: Manish Harkut > Priority: Major > Fix For: 1.6.0 > > > iIndex = 1 > $ie.div(:xpath,'/html/body/div[18]/div[3]/div[2]/div[7]/div/div/div[' + iIndex.to_s + ']').exists? > The Watir and FireWatir returns different values for the above statement. > If FireWatir it retuen true which is right and test aare executed properly However in Watir even if when the objects exists it returns false and test fails. -- 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 Oct 7 03:49:31 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Thu, 7 Oct 2010 02:49:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Reopened: (WTR-235) Xpath.exist returns different results in Watir and Firewatir. Message-ID: <29677367.1168.1286437771310.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zeljko reopened WTR-235: ------------------------ > Xpath.exist returns different results in Watir and Firewatir. > ------------------------------------------------------------- > > Key: WTR-235 > URL: http://jira.openqa.org/browse/WTR-235 > Project: Watir > Issue Type: Bug > Components: FireWatir > Environment: WinXP Prof SP2, Ruby 1.8, Watir 1.5.6 and Firewatir 1.2.0 > Reporter: Manish Harkut > Priority: Major > Fix For: 1.6.0 > > > iIndex = 1 > $ie.div(:xpath,'/html/body/div[18]/div[3]/div[2]/div[7]/div/div/div[' + iIndex.to_s + ']').exists? > The Watir and FireWatir returns different values for the above statement. > If FireWatir it retuen true which is right and test aare executed properly However in Watir even if when the objects exists it returns false and test fails. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From zeljko.filipin at wa-research.ch Thu Oct 7 06:02:13 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 7 Oct 2010 12:02:13 +0200 Subject: [Wtr-development] Building Watir Message-ID: I am just testing changes I made in my license branch[1] and I tried building Watir on Mac according to instructions from Building Watir wiki page [2] and got this: $ rake gems (in /Users/zeljko/Documents/projekt/watir) /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/fileutils.rb:1420: command not found: rake.bat gem /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/fileutils.rb:1420: command not found: rake.bat gem /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/fileutils.rb:1420: command not found: rake.bat gem `rake gems` works just fine on Windows. Am I doing something wrong or (building Watir with) Rake does not work on Mac? (Google did not help so far.) ?eljko -- [1] http://github.com/zeljkofilipin/watir/tree/license [2] http://wiki.openqa.org/display/WTR/Building+Watir -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Thu Oct 7 06:41:24 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 7 Oct 2010 12:41:24 +0200 Subject: [Wtr-development] source cleanup In-Reply-To: References: Message-ID: On Wed, Oct 6, 2010 at 8:35 PM, Bret Pettichord wrote: > Use this: > > Copyright (c) 2004 - 2006, Paul Rogers > Copyright (c) 2006 - 2007, Angrez Singh > Copyright (c) 2004 - 2010, Bret Pettichord Done: http://github.com/bret/watir/pull/15 `rake gems` now fails: C:\watir>rake gems (in C:/watir) mv watir-1.6.6.gem pkg/watir-1.6.6.gem (in C:/watir/watir) Successfully built RubyGem Name: watir Version: 1.6.6 File: watir-1.6.6.gem mv firewatir-1.6.6.gem pkg/firewatir-1.6.6.gem (in C:/watir/firewatir) Successfully built RubyGem Name: firewatir Version: 1.6.6 File: firewatir-1.6.6.gem rake aborted! Don't know how to build task 'LICENSE' (See full trace by running task with --trace) (in C:/watir/commonwatir) I took a look at commonwatir.gemspec (line 13), but I am not sure why it complains about "LICENSE" when firewatir.gemspec also has 'LICENSE' (line 8) and it works. (I am new to rake.) Any help in debugging this is appreciated. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Thu Oct 7 07:36:49 2010 From: jarmo.p at gmail.com (Jarmo) Date: Thu, 7 Oct 2010 11:36:49 +0000 Subject: [Wtr-development] Building Watir In-Reply-To: References: Message-ID: Nope, this is a known thing. Alan Shields has also made a pull request for this, but haven't had any time to review it enough. Gonna do it in a next few days probably. Currently you can build gems manually on non-Windows machines by `cd firewatir; rake gem` and so on. Jarmo On Thu, Oct 7, 2010 at 10:02 AM, ?eljko Filipin wrote: > I am just testing changes I made in my license branch[1] and I tried > building Watir on Mac according to instructions from Building Watir wiki > page [2] and got this: > > $ rake gems > (in /Users/zeljko/Documents/projekt/watir) > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/fileutils.rb:1420: > command not found: rake.bat gem > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/fileutils.rb:1420: > command not found: rake.bat gem > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/fileutils.rb:1420: > command not found: rake.bat gem > > `rake gems` works just fine on Windows. > > Am I doing something wrong or (building Watir with) Rake does not work on > Mac? (Google did not help so far.) > > ?eljko > -- > > [1] http://github.com/zeljkofilipin/watir/tree/license > [2] http://wiki.openqa.org/display/WTR/Building+Watir > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From jarmo.p at gmail.com Thu Oct 7 07:42:20 2010 From: jarmo.p at gmail.com (Jarmo) Date: Thu, 7 Oct 2010 11:42:20 +0000 Subject: [Wtr-development] Building Watir In-Reply-To: References: Message-ID: Right, you cannot make it manually either because VERSION, CHANGES and stuff are copied temporarily if `rake gems` is executed in root. Jarmo On Thu, Oct 7, 2010 at 11:36 AM, Jarmo wrote: > Nope, this is a known thing. Alan Shields has also made a pull request > for this, but haven't had any time to review it enough. Gonna do it in > a next few days probably. Currently you can build gems manually on > non-Windows machines by `cd firewatir; rake gem` and so on. > > Jarmo > > On Thu, Oct 7, 2010 at 10:02 AM, ?eljko Filipin > wrote: >> I am just testing changes I made in my license branch[1] and I tried >> building Watir on Mac according to instructions from Building Watir wiki >> page [2] and got this: >> >> $ rake gems >> (in /Users/zeljko/Documents/projekt/watir) >> /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/fileutils.rb:1420: >> command not found: rake.bat gem >> /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/fileutils.rb:1420: >> command not found: rake.bat gem >> /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/fileutils.rb:1420: >> command not found: rake.bat gem >> >> `rake gems` works just fine on Windows. >> >> Am I doing something wrong or (building Watir with) Rake does not work on >> Mac? (Google did not help so far.) >> >> ?eljko >> -- >> >> [1] http://github.com/zeljkofilipin/watir/tree/license >> [2] http://wiki.openqa.org/display/WTR/Building+Watir >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > From zeljko.filipin at wa-research.ch Thu Oct 7 08:03:17 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 7 Oct 2010 14:03:17 +0200 Subject: [Wtr-development] Building Watir In-Reply-To: References: Message-ID: On Thu, Oct 7, 2010 at 1:42 PM, Jarmo wrote: > Right, you cannot make it manually either because VERSION, CHANGES and > stuff are copied temporarily if `rake gems` is executed in root. Is this answering question I have asked in another thread? (I do not understand how it is related to building Watir on Mac.) ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Thu Oct 7 09:47:31 2010 From: watirjira at gmail.com (Shaivya Mahajan (JIRA)) Date: Thu, 7 Oct 2010 08:47:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-235) Xpath.exist returns different results in Watir and Firewatir. Message-ID: <22829342.1172.1286459251522.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shaivya Mahajan updated WTR-235: -------------------------------- Attachment: test.html xpath_bug.rb added test scripts + saved html for running locally > Xpath.exist returns different results in Watir and Firewatir. > ------------------------------------------------------------- > > Key: WTR-235 > URL: http://jira.openqa.org/browse/WTR-235 > Project: Watir > Issue Type: Bug > Components: FireWatir > Environment: WinXP Prof SP2, Ruby 1.8, Watir 1.5.6 and Firewatir 1.2.0 > Reporter: Manish Harkut > Priority: Major > Fix For: 1.6.0 > > Attachments: test.html, xpath_bug.rb > > > iIndex = 1 > $ie.div(:xpath,'/html/body/div[18]/div[3]/div[2]/div[7]/div/div/div[' + iIndex.to_s + ']').exists? > The Watir and FireWatir returns different values for the above statement. > If FireWatir it retuen true which is right and test aare executed properly However in Watir even if when the objects exists it returns false and test fails. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From bret at pettichord.com Thu Oct 7 10:29:08 2010 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 7 Oct 2010 09:29:08 -0500 Subject: [Wtr-development] Building Watir In-Reply-To: References: Message-ID: Jarmo is saying that actually his first answer won't work because of the recent work on consolidate CHANGES, README, etc. Bret On Thu, Oct 7, 2010 at 7:03 AM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Thu, Oct 7, 2010 at 1:42 PM, Jarmo wrote: > > Right, you cannot make it manually either because VERSION, CHANGES and > > stuff are copied temporarily if `rake gems` is executed in root. > > Is this answering question I have asked in another thread? (I do not > understand how it is related to building Watir on Mac.) > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Thu Oct 7 10:39:16 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 7 Oct 2010 16:39:16 +0200 Subject: [Wtr-development] Building Watir In-Reply-To: References: Message-ID: On Thu, Oct 7, 2010 at 4:29 PM, Bret Pettichord wrote: > Jarmo is saying that actually his first answer won't work because of the recent work on consolidate CHANGES, README, etc. I get it now, thanks. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Thu Oct 7 12:41:30 2010 From: jarmo.p at gmail.com (Jarmo) Date: Thu, 7 Oct 2010 16:41:30 +0000 Subject: [Wtr-development] source cleanup In-Reply-To: References: Message-ID: Merged and fixed `rake gems` problem below. Jarmo On Thu, Oct 7, 2010 at 10:41 AM, ?eljko Filipin wrote: > On Wed, Oct 6, 2010 at 8:35 PM, Bret Pettichord wrote: >> Use this: >> >> Copyright (c) 2004 - 2006, Paul Rogers >> Copyright (c) 2006 - 2007, Angrez Singh >> Copyright (c) 2004 - 2010, Bret Pettichord > > Done: > > http://github.com/bret/watir/pull/15 > > `rake gems` now fails: > > C:\watir>rake gems > (in C:/watir) > mv watir-1.6.6.gem pkg/watir-1.6.6.gem > (in C:/watir/watir) > ? Successfully built RubyGem > ? Name: watir > ? Version: 1.6.6 > ? File: watir-1.6.6.gem > mv firewatir-1.6.6.gem pkg/firewatir-1.6.6.gem > (in C:/watir/firewatir) > ? Successfully built RubyGem > ? Name: firewatir > ? Version: 1.6.6 > ? File: firewatir-1.6.6.gem > rake aborted! > Don't know how to build task 'LICENSE' > > (See full trace by running task with --trace) > (in C:/watir/commonwatir) > > I took a look at commonwatir.gemspec (line 13), but I am not sure why it > complains about "LICENSE" when firewatir.gemspec also has 'LICENSE' (line 8) > and it works. (I am new to rake.) > > Any help in debugging this is appreciated. > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From jarmo.p at gmail.com Thu Oct 7 13:38:26 2010 From: jarmo.p at gmail.com (Jarmo) Date: Thu, 7 Oct 2010 17:38:26 +0000 Subject: [Wtr-development] Fwd: [GitHub] Legal attribute name fix [bret/watir GH-5] In-Reply-To: <4ca4270a24f4b_7dea3fe233ab787c8e3@fe5.rs.github.com.tmail> References: <4ca4270a24f4b_7dea3fe233ab787c8e3@fe5.rs.github.com.tmail> Message-ID: I wonder if the same bug also exists in Watir. Anyone cares to try? Jarmo ---------- Forwarded message ---------- From: GitHub Date: Thu, Sep 30, 2010 at 5:58 AM Subject: [GitHub] Legal attribute name fix [bret/watir GH-5] To: jarmo.p at gmail.com alanshields wants someone to pull from alanshields:attribute_js_fix: HTML5 allows arbitrary attributes on elements provided that the attribute begins with "data-". Even before HTML5, this was done by a few people. Unfortunately, current code will fail, interpreting attribute_value("foo-bar") as "foo - bar". This has now been fixed and (more importantly) unit tested. Thank you, Alan Shields View Pull Request: http://github.com/bret/watir/pull/5 From notethan at gmail.com Thu Oct 7 14:32:03 2010 From: notethan at gmail.com (Ethan) Date: Thu, 7 Oct 2010 14:32:03 -0400 Subject: [Wtr-development] Fwd: [GitHub] Legal attribute name fix [bret/watir GH-5] In-Reply-To: References: <4ca4270a24f4b_7dea3fe233ab787c8e3@fe5.rs.github.com.tmail> Message-ID: presumably not - it's an issue with the rather poor method firewatir uses of passing values to javascript and back. watir doesn't do any passing around of unescaped strings that could have some particular meaning in js. On Thu, Oct 7, 2010 at 13:38, Jarmo wrote: > I wonder if the same bug also exists in Watir. Anyone cares to try? > > Jarmo > > > ---------- Forwarded message ---------- > From: GitHub > Date: Thu, Sep 30, 2010 at 5:58 AM > Subject: [GitHub] Legal attribute name fix [bret/watir GH-5] > To: jarmo.p at gmail.com > > > alanshields wants someone to pull from alanshields:attribute_js_fix: > > HTML5 allows arbitrary attributes on elements provided that the > attribute begins with "data-". Even before HTML5, this was done by a > few people. > > Unfortunately, current code will fail, interpreting > attribute_value("foo-bar") as "foo - bar". > > This has now been fixed and (more importantly) unit tested. > > Thank you, > Alan Shields > > View Pull Request: http://github.com/bret/watir/pull/5 > _______________________________________________ > 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 Fri Oct 8 00:26:30 2010 From: watirjira at gmail.com (Kevin DeRossett (JIRA)) Date: Thu, 7 Oct 2010 23:26:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Created: (WTR-455) link.src generates link.rb:42:in `method_missing': unknown property or method: `src' (NoMethodError) HRESULT error code:0x80070057 Message-ID: <17158468.1176.1286511990701.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> link.src generates link.rb:42:in `method_missing': unknown property or method: `src' (NoMethodError) HRESULT error code:0x80070057 ---------------------------------------------------------------------------------------------------------------------------------- Key: WTR-455 URL: http://jira.openqa.org/browse/WTR-455 Project: Watir Issue Type: Bug Components: HTML Controls Affects Versions: 1.6.5 Environment: ruby 1.9.1 and 1.9.2 mingw from http://rubyinstaller.org/ with devkit Reporter: Kevin DeRossett Priority: Critical My Fix for Watir::Link.src in link.rb at line 39'ish @o.getElementsByTagName("IMG")[0.to_s] was failing/not returning a # so calling .src failes def src assert_exists imgsrc = "" @o.getElementsByTagName("IMG").each { |img| imgsrc = img.src break } return imgsrc end -- 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 Oct 8 00:36:33 2010 From: watirjira at gmail.com (Kevin DeRossett (JIRA)) Date: Thu, 7 Oct 2010 23:36:33 -0500 (CDT) Subject: [Wtr-development] [JIRA] Created: (WTR-456) Firewatir fails to start firefox Message-ID: <11156732.1179.1286512593133.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Firewatir fails to start firefox -------------------------------- Key: WTR-456 URL: http://jira.openqa.org/browse/WTR-456 Project: Watir Issue Type: Bug Components: FireWatir Affects Versions: 1.6.5 Environment: ruby 1.8.6, 1.9.1 and ruby 1.9.2 mingw from http://rubyinstaller.org/ Reporter: Kevin DeRossett Priority: Critical path_from_registry in firefox.rb line 1027ish is: return entry.last but should be: return "\"#{entry.last}\"" without the quotes firefox will not start from the path c:\Program Files\... or c:\Program Files (x86)\... the default location. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From jarmo.p at gmail.com Fri Oct 8 04:02:14 2010 From: jarmo.p at gmail.com (Jarmo) Date: Fri, 8 Oct 2010 08:02:14 +0000 Subject: [Wtr-development] about rdoc Message-ID: Hi! Where's the official place for holding rdoc for watir? I know about this place - http://wtr.rubyforge.org/rdoc/ There seems to be also link from watir.com to this. I guess these rdocs need to be created manually after each release, right? I have a proposition - ditch these rdocs from the above location and point documentation links to rubydoc.info instead. The latest version for watir would be available from http://rubydoc.info/gems/watir (i'm not sure if it will generate doc automatically for 1.6.7 unless anyone has selected 1.6.7 from the main page from rubygems, but it's still better than current solution i guess). And the older versions could be available from http://rubydoc.info/gems/watir/1.6.5 I'm not sure why the CHANGES file isn't visible from there yet, maybe gemspecs need some tweaking... Jarmo From zeljko.filipin at wa-research.ch Fri Oct 8 16:58:26 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Fri, 8 Oct 2010 22:58:26 +0200 Subject: [Wtr-development] source cleanup In-Reply-To: References: Message-ID: On Thu, Oct 7, 2010 at 6:41 PM, Jarmo wrote: > Merged and fixed `rake gems` problem below. Thanks. :) ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Fri Oct 8 18:42:31 2010 From: watirjira at gmail.com (Yogesh Prajapati (JIRA)) Date: Fri, 8 Oct 2010 17:42:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Created: (WTR-457) FileField.set("") hangs inconsistently and not guranteed to work all the time, better workaround/fix included here Message-ID: <29076443.1186.1286577751204.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> FileField.set("") hangs inconsistently and not guranteed to work all the time, better workaround/fix included here ----------------------------------------------------------------------------------------------------------------------------- Key: WTR-457 URL: http://jira.openqa.org/browse/WTR-457 Project: Watir Issue Type: Improvement Components: Inputs Affects Versions: 1.6.5, 1.6.2 Environment: Windows XP SP2, (Ruby 1.8.26, Watir 1.6.2) OR (Ruby 1.8.7-p299, Watir 1.6.5) Reporter: Yogesh Prajapati Priority: Blocker Attachments: input_elements.rb When trying trying to upload a file using file input field, I am using the WATIR api $ie.file_field(:id, "fileupload").set("#{aFileName.to_s}"), the sometimes IE seemed to open "file open" dialog, it will set the file path correctly and close the "file open" dialog box fine and the file input field get populated correctly with expected file path, but majority of the times the dialog box will stay open (hanging) and no file name/path set in "File Name" edit field and nothing happens there after. I kind of played around changing sleep time in "input_elements.rb:FileField.set()" method to make it work. What I noticed that higher sleeping time made the problem worse. By understanding little bit more about what the "set()" is trying to do, it seemed like a callback method (after file open dialog box pops up). So as it says on the line for sleep commands, "it takes some time for popup to appear", it sounded like that it is too early to make a sleep call i.e. before launching a separate new process to set the file location in dialog. It is apparent that the wait (sleep) should rather be done within the new process launched by making 'system' call instead of putting the enclosing thread to wait even before starting the new process. Having said that, by putting the thread to wait before launching new process, file open dialog box pops up and entire ruby process waits for manually input (to me it meant broken automated workflow) and that's not acceptable. So the fix to issue of hanging file open dialog box move line "sleep 1..." withing system call (i.e. "system %{ruby -e '...." ) just below line 'require "win32ole"' and may be increase sleep time to 2 or 4 seconds depending up fast or slow machine. The fix for me with 4 seconds sleep time worked equally good on both slow (Pentium4, WinXP SP2) and fast (Core2Duo, WinXP SP2) machines. Please find the updated "input_elements.rb" attached here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 9 05:23:31 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Sat, 9 Oct 2010 04:23:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-457) FileField.set("") hangs inconsistently and not guranteed to work all the time, better workaround/fix included here In-Reply-To: <29076443.1186.1286577751204.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <29610328.1190.1286616211355.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19900#action_19900 ] Jarmo Pertman commented on WTR-457: ----------------------------------- Thank you for reporting this. I've been aware of this problem myself and don't find using "sleep" to be a good solution due to the fact that sometimes 4 seconds could be too small or too big, depending of the machine and it's load. Current FileField#set is really fragile and i've had it on my mind to fix it altogether. I will leave that ticket open for now, but not gonna use the solution provided in here. Good it fixed the problem for you though. > FileField.set("") hangs inconsistently and not guranteed to work all the time, better workaround/fix included here > ----------------------------------------------------------------------------------------------------------------------------- > > Key: WTR-457 > URL: http://jira.openqa.org/browse/WTR-457 > Project: Watir > Issue Type: Improvement > Components: Inputs > Affects Versions: 1.6.2, 1.6.5 > Environment: Windows XP SP2, (Ruby 1.8.26, Watir 1.6.2) OR (Ruby 1.8.7-p299, Watir 1.6.5) > Reporter: Yogesh Prajapati > Priority: Blocker > Attachments: input_elements.rb > > > When trying trying to upload a file using file input field, I am using the WATIR api $ie.file_field(:id, "fileupload").set("#{aFileName.to_s}"), the sometimes IE seemed to open "file open" dialog, it will set the file path correctly and close the "file open" dialog box fine and the file input field get populated correctly with expected file path, but majority of the times the dialog box will stay open (hanging) and no file name/path set in "File Name" edit field and nothing happens there after. > I kind of played around changing sleep time in "input_elements.rb:FileField.set()" method to make it work. What I noticed that higher sleeping time made the problem worse. > By understanding little bit more about what the "set()" is trying to do, it seemed like a callback method (after file open dialog box pops up). So as it says on the line for sleep commands, "it takes some time for popup to appear", it sounded like that it is too early to make a sleep call i.e. before launching a separate new process to set the file location in dialog. It is apparent that the wait (sleep) should rather be done within the new process launched by making 'system' call instead of putting the enclosing thread to wait even before starting the new process. > Having said that, by putting the thread to wait before launching new process, file open dialog box pops up and entire ruby process waits for manually input (to me it meant broken automated workflow) and that's not acceptable. > So the fix to issue of hanging file open dialog box move line "sleep 1..." withing system call (i.e. "system %{ruby -e '...." ) just below line 'require "win32ole"' and may be increase sleep time to 2 or 4 seconds depending up fast or slow machine. > The fix for me with 4 seconds sleep time worked equally good on both slow (Pentium4, WinXP SP2) and fast (Core2Duo, WinXP SP2) machines. Please find the updated "input_elements.rb" attached here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 9 05:25:30 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Sat, 9 Oct 2010 04:25:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Assigned: (WTR-457) FileField.set("") hangs inconsistently and not guranteed to work all the time, better workaround/fix included here In-Reply-To: <29076443.1186.1286577751204.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <1061085.1193.1286616330689.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarmo Pertman reassigned WTR-457: --------------------------------- Assignee: Jarmo Pertman > FileField.set("") hangs inconsistently and not guranteed to work all the time, better workaround/fix included here > ----------------------------------------------------------------------------------------------------------------------------- > > Key: WTR-457 > URL: http://jira.openqa.org/browse/WTR-457 > Project: Watir > Issue Type: Improvement > Components: Inputs > Affects Versions: 1.6.2, 1.6.5 > Environment: Windows XP SP2, (Ruby 1.8.26, Watir 1.6.2) OR (Ruby 1.8.7-p299, Watir 1.6.5) > Reporter: Yogesh Prajapati > Assignee: Jarmo Pertman > Priority: Blocker > Attachments: input_elements.rb > > > When trying trying to upload a file using file input field, I am using the WATIR api $ie.file_field(:id, "fileupload").set("#{aFileName.to_s}"), the sometimes IE seemed to open "file open" dialog, it will set the file path correctly and close the "file open" dialog box fine and the file input field get populated correctly with expected file path, but majority of the times the dialog box will stay open (hanging) and no file name/path set in "File Name" edit field and nothing happens there after. > I kind of played around changing sleep time in "input_elements.rb:FileField.set()" method to make it work. What I noticed that higher sleeping time made the problem worse. > By understanding little bit more about what the "set()" is trying to do, it seemed like a callback method (after file open dialog box pops up). So as it says on the line for sleep commands, "it takes some time for popup to appear", it sounded like that it is too early to make a sleep call i.e. before launching a separate new process to set the file location in dialog. It is apparent that the wait (sleep) should rather be done within the new process launched by making 'system' call instead of putting the enclosing thread to wait even before starting the new process. > Having said that, by putting the thread to wait before launching new process, file open dialog box pops up and entire ruby process waits for manually input (to me it meant broken automated workflow) and that's not acceptable. > So the fix to issue of hanging file open dialog box move line "sleep 1..." withing system call (i.e. "system %{ruby -e '...." ) just below line 'require "win32ole"' and may be increase sleep time to 2 or 4 seconds depending up fast or slow machine. > The fix for me with 4 seconds sleep time worked equally good on both slow (Pentium4, WinXP SP2) and fast (Core2Duo, WinXP SP2) machines. Please find the updated "input_elements.rb" attached here. -- 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 Sat Oct 9 12:00:08 2010 From: charley.baker at gmail.com (Charley Baker) Date: Sat, 9 Oct 2010 10:00:08 -0600 Subject: [Wtr-development] about rdoc In-Reply-To: References: Message-ID: +1, I believe the docs are generated by a post hook on github, though I can't tell since I don't have admin rights. On Fri, Oct 8, 2010 at 2:02 AM, Jarmo wrote: > Hi! > > Where's the official place for holding rdoc for watir? I know about > this place - http://wtr.rubyforge.org/rdoc/ There seems to be also > link from watir.com to this. I guess these rdocs need to be created > manually after each release, right? > > I have a proposition - ditch these rdocs from the above location and > point documentation links to rubydoc.info instead. > > The latest version for watir would be available from > http://rubydoc.info/gems/watir (i'm not sure if it will generate doc > automatically for 1.6.7 unless anyone has selected 1.6.7 from the main > page from rubygems, but it's still better than current solution i > guess). > > And the older versions could be available from > http://rubydoc.info/gems/watir/1.6.5 > > I'm not sure why the CHANGES file isn't visible from there yet, maybe > gemspecs need some tweaking... > > Jarmo > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From jarmo.p at gmail.com Sat Oct 9 12:31:32 2010 From: jarmo.p at gmail.com (Jarmo) Date: Sat, 9 Oct 2010 19:31:32 +0300 Subject: [Wtr-development] about rdoc In-Reply-To: References: Message-ID: Yes, you can generate them by a post hook on github, but you can also generate them from the gems. Check out on the main page of rubydoc.info there is a "Rubygems" tab with Featured and GitHub tabs. Jarmo On Sat, Oct 9, 2010 at 7:00 PM, Charley Baker wrote: > +1, I believe the docs are generated by a post hook on github, though > I can't tell since I don't have admin rights. > > > On Fri, Oct 8, 2010 at 2:02 AM, Jarmo wrote: >> Hi! >> >> Where's the official place for holding rdoc for watir? I know about >> this place - http://wtr.rubyforge.org/rdoc/ There seems to be also >> link from watir.com to this. I guess these rdocs need to be created >> manually after each release, right? >> >> I have a proposition - ditch these rdocs from the above location and >> point documentation links to rubydoc.info instead. >> >> The latest version for watir would be available from >> http://rubydoc.info/gems/watir (i'm not sure if it will generate doc >> automatically for 1.6.7 unless anyone has selected 1.6.7 from the main >> page from rubygems, but it's still better than current solution i >> guess). >> >> And the older versions could be available from >> http://rubydoc.info/gems/watir/1.6.5 >> >> I'm not sure why the CHANGES file isn't visible from there yet, maybe >> gemspecs need some tweaking... >> >> Jarmo >> _______________________________________________ >> 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 watirjira at gmail.com Sat Oct 9 14:19:31 2010 From: watirjira at gmail.com (Ethan (JIRA)) Date: Sat, 9 Oct 2010 13:19:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-457) FileField.set("") hangs inconsistently and not guranteed to work all the time, better workaround/fix included here In-Reply-To: <29076443.1186.1286577751204.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <20518203.1197.1286648371290.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19901#action_19901 ] Ethan commented on WTR-457: --------------------------- It certainly needs a rewrite. You might take a look at vapir's implementation, using WinWindow library. http://github.com/vapir/vapir/blob/vapir-1.7.1/vapir-ie/lib/vapir-ie/input_elements.rb#L107 http://github.com/vapir/vapir/blob/vapir-1.7.1/vapir-ie/lib/vapir-ie/scripts/select_file.rb#L1 > FileField.set("") hangs inconsistently and not guranteed to work all the time, better workaround/fix included here > ----------------------------------------------------------------------------------------------------------------------------- > > Key: WTR-457 > URL: http://jira.openqa.org/browse/WTR-457 > Project: Watir > Issue Type: Improvement > Components: Inputs > Affects Versions: 1.6.2, 1.6.5 > Environment: Windows XP SP2, (Ruby 1.8.26, Watir 1.6.2) OR (Ruby 1.8.7-p299, Watir 1.6.5) > Reporter: Yogesh Prajapati > Assignee: Jarmo Pertman > Priority: Blocker > Attachments: input_elements.rb > > > When trying trying to upload a file using file input field, I am using the WATIR api $ie.file_field(:id, "fileupload").set("#{aFileName.to_s}"), the sometimes IE seemed to open "file open" dialog, it will set the file path correctly and close the "file open" dialog box fine and the file input field get populated correctly with expected file path, but majority of the times the dialog box will stay open (hanging) and no file name/path set in "File Name" edit field and nothing happens there after. > I kind of played around changing sleep time in "input_elements.rb:FileField.set()" method to make it work. What I noticed that higher sleeping time made the problem worse. > By understanding little bit more about what the "set()" is trying to do, it seemed like a callback method (after file open dialog box pops up). So as it says on the line for sleep commands, "it takes some time for popup to appear", it sounded like that it is too early to make a sleep call i.e. before launching a separate new process to set the file location in dialog. It is apparent that the wait (sleep) should rather be done within the new process launched by making 'system' call instead of putting the enclosing thread to wait even before starting the new process. > Having said that, by putting the thread to wait before launching new process, file open dialog box pops up and entire ruby process waits for manually input (to me it meant broken automated workflow) and that's not acceptable. > So the fix to issue of hanging file open dialog box move line "sleep 1..." withing system call (i.e. "system %{ruby -e '...." ) just below line 'require "win32ole"' and may be increase sleep time to 2 or 4 seconds depending up fast or slow machine. > The fix for me with 4 seconds sleep time worked equally good on both slow (Pentium4, WinXP SP2) and fast (Core2Duo, WinXP SP2) machines. Please find the updated "input_elements.rb" attached here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sun Oct 10 01:23:31 2010 From: watirjira at gmail.com (Ethan (JIRA)) Date: Sun, 10 Oct 2010 00:23:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-455) link.src generates link.rb:42:in `method_missing': unknown property or method: `src' (NoMethodError) HRESULT error code:0x80070057 In-Reply-To: <17158468.1176.1286511990701.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <12680218.1200.1286688211171.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19902#action_19902 ] Ethan commented on WTR-455: --------------------------- Link#src should be deprecated anyway. src isn't an attribute of a link and shouldn't be on that class. > link.src generates link.rb:42:in `method_missing': unknown property or method: `src' (NoMethodError) HRESULT error code:0x80070057 > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WTR-455 > URL: http://jira.openqa.org/browse/WTR-455 > Project: Watir > Issue Type: Bug > Components: HTML Controls > Affects Versions: 1.6.5 > Environment: ruby 1.9.1 and 1.9.2 mingw from http://rubyinstaller.org/ with devkit > Reporter: Kevin DeRossett > Priority: Critical > > My Fix for Watir::Link.src in link.rb at line 39'ish > @o.getElementsByTagName("IMG")[0.to_s] was failing/not returning a # > so calling .src failes > def src > assert_exists > imgsrc = "" > @o.getElementsByTagName("IMG").each { |img| > imgsrc = img.src > break > } > return imgsrc > end -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sun Oct 10 15:40:30 2010 From: watirjira at gmail.com (Kevin DeRossett (JIRA)) Date: Sun, 10 Oct 2010 14:40:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-455) link.src generates link.rb:42:in `method_missing': unknown property or method: `src' (NoMethodError) HRESULT error code:0x80070057 In-Reply-To: <17158468.1176.1286511990701.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <26851619.1203.1286739630731.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19903#action_19903 ] Kevin DeRossett commented on WTR-455: ------------------------------------- I got burned by Link#to_s which calls Link#src > link.src generates link.rb:42:in `method_missing': unknown property or method: `src' (NoMethodError) HRESULT error code:0x80070057 > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WTR-455 > URL: http://jira.openqa.org/browse/WTR-455 > Project: Watir > Issue Type: Bug > Components: HTML Controls > Affects Versions: 1.6.5 > Environment: ruby 1.9.1 and 1.9.2 mingw from http://rubyinstaller.org/ with devkit > Reporter: Kevin DeRossett > Priority: Critical > > My Fix for Watir::Link.src in link.rb at line 39'ish > @o.getElementsByTagName("IMG")[0.to_s] was failing/not returning a # > so calling .src failes > def src > assert_exists > imgsrc = "" > @o.getElementsByTagName("IMG").each { |img| > imgsrc = img.src > break > } > return imgsrc > end -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Mon Oct 11 04:33:30 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Mon, 11 Oct 2010 03:33:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-455) link.src generates link.rb:42:in `method_missing': unknown property or method: `src' (NoMethodError) HRESULT error code:0x80070057 In-Reply-To: <17158468.1176.1286511990701.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <15681216.1206.1286786010791.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19904#action_19904 ] Zeljko commented on WTR-455: ---------------------------- to_s could be removed in the near future (maybe even today) > link.src generates link.rb:42:in `method_missing': unknown property or method: `src' (NoMethodError) HRESULT error code:0x80070057 > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WTR-455 > URL: http://jira.openqa.org/browse/WTR-455 > Project: Watir > Issue Type: Bug > Components: HTML Controls > Affects Versions: 1.6.5 > Environment: ruby 1.9.1 and 1.9.2 mingw from http://rubyinstaller.org/ with devkit > Reporter: Kevin DeRossett > Priority: Critical > > My Fix for Watir::Link.src in link.rb at line 39'ish > @o.getElementsByTagName("IMG")[0.to_s] was failing/not returning a # > so calling .src failes > def src > assert_exists > imgsrc = "" > @o.getElementsByTagName("IMG").each { |img| > imgsrc = img.src > break > } > return imgsrc > end -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From zeljko.filipin at wa-research.ch Mon Oct 11 06:31:36 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Mon, 11 Oct 2010 12:31:36 +0200 Subject: [Wtr-development] about rdoc In-Reply-To: References: Message-ID: On Fri, Oct 8, 2010 at 10:02 AM, Jarmo wrote: > I have a proposition - ditch these rdocs from the above location and > point documentation links to rubydoc.info instead. +1 I will make the change, probably today. If somebody disagrees, now is the time to say something. ?eljko -- watir.com - community manager watirpodcast.com - host testingpodcast.com - audio podcasts on software testing. all of them -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Mon Oct 11 09:00:06 2010 From: jarmo.p at gmail.com (Jarmo) Date: Mon, 11 Oct 2010 16:00:06 +0300 Subject: [Wtr-development] about rdoc In-Reply-To: References: Message-ID: There are some minor inconsistencies between rdoc and yard, but i don't see any problems with that currently. Maybe someone takes a look at that generated documentation and compares it to rdoc to see what's the biggest differences. Jarmo On Mon, Oct 11, 2010 at 1:31 PM, ?eljko Filipin wrote: > On Fri, Oct 8, 2010 at 10:02 AM, Jarmo wrote: >> I have a proposition - ditch these rdocs from the above location and >> point documentation links to rubydoc.info instead. > > +1 > > I will make the change, probably today. > > If somebody disagrees, now is the time to say something. > > ?eljko > -- > watir.com - community manager > watirpodcast.com - host > testingpodcast.com - audio podcasts on software testing. all of them > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From bret at pettichord.com Mon Oct 11 21:41:44 2010 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 11 Oct 2010 20:41:44 -0500 Subject: [Wtr-development] AWTA workshop in Austin Message-ID: Every couple of years, I've been holding a 3-day workshop in Austin called AWTA. http://awta.wikispaces.com/AWTA+2009 We are discussing whether to hold another such event, sometime early next year. I'd be particularly keen to hold the event if I were able to attract several of the active Watir contributors. There is no cost to attend the event for people traveling from overseas, except for your travel/room etc (which can be considerable). Could you please let me know if this is something you might be able to attend? Bret -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Tue Oct 12 03:04:01 2010 From: alister.scott at gmail.com (Alister Scott) Date: Tue, 12 Oct 2010 17:04:01 +1000 Subject: [Wtr-development] about rdoc In-Reply-To: References: Message-ID: As we seem to all agree on rdoc.info/rubydoc.info, I have updated watir.com/documentation to point to: http://rdoc.info/gems/watir/1.6.6/frames The frames part on the end makes a nice table of contents and scrollable bit. 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 Mon, Oct 11, 2010 at 11:00 PM, Jarmo wrote: > There are some minor inconsistencies between rdoc and yard, but i > don't see any problems with that currently. > > Maybe someone takes a look at that generated documentation and > compares it to rdoc to see what's the biggest differences. > > Jarmo > > On Mon, Oct 11, 2010 at 1:31 PM, ?eljko Filipin > wrote: > > On Fri, Oct 8, 2010 at 10:02 AM, Jarmo wrote: > >> I have a proposition - ditch these rdocs from the above location and > >> point documentation links to rubydoc.info instead. > > > > +1 > > > > I will make the change, probably today. > > > > If somebody disagrees, now is the time to say something. > > > > ?eljko > > -- > > watir.com - community manager > > watirpodcast.com - host > > testingpodcast.com - audio podcasts on software testing. all of them > > > > > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Tue Oct 12 03:54:17 2010 From: jarmo.p at gmail.com (Jarmo) Date: Tue, 12 Oct 2010 10:54:17 +0300 Subject: [Wtr-development] about rdoc In-Reply-To: References: Message-ID: Nice :) Thanks! Jarmo On Tue, Oct 12, 2010 at 10:04 AM, Alister Scott wrote: > As we seem to all agree on rdoc.info/rubydoc.info, I have updated > watir.com/documentation to point to: > http://rdoc.info/gems/watir/1.6.6/frames > > The frames part on the end makes a nice table of contents and scrollable > bit. > > 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 Mon, Oct 11, 2010 at 11:00 PM, Jarmo wrote: >> >> There are some minor inconsistencies between rdoc and yard, but i >> don't see any problems with that currently. >> >> Maybe someone takes a look at that generated documentation and >> compares it to rdoc to see what's the biggest differences. >> >> Jarmo >> >> On Mon, Oct 11, 2010 at 1:31 PM, ?eljko Filipin >> wrote: >> > On Fri, Oct 8, 2010 at 10:02 AM, Jarmo wrote: >> >> I have a proposition - ditch these rdocs from the above location and >> >> point documentation links to rubydoc.info instead. >> > >> > +1 >> > >> > I will make the change, probably today. >> > >> > If somebody disagrees, now is the time to say something. >> > >> > ?eljko >> > -- >> > watir.com - community manager >> > watirpodcast.com - host >> > testingpodcast.com - audio podcasts on software testing. all of them >> > >> > >> > _______________________________________________ >> > Wtr-development mailing list >> > Wtr-development at rubyforge.org >> > http://rubyforge.org/mailman/listinfo/wtr-development >> > >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From zeljko.filipin at wa-research.ch Tue Oct 12 04:55:06 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 12 Oct 2010 10:55:06 +0200 Subject: [Wtr-development] AWTA workshop in Austin In-Reply-To: References: Message-ID: On Tue, Oct 12, 2010 at 3:41 AM, Bret Pettichord wrote: > Could you please let me know if this is something you might be able to attend? I would do my best to be there. :) ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Tue Oct 12 05:18:55 2010 From: alister.scott at gmail.com (Alister Scott) Date: Tue, 12 Oct 2010 19:18:55 +1000 Subject: [Wtr-development] AWTA workshop in Austin In-Reply-To: References: Message-ID: <-391526066479601542@unknownmsgid> I would love to attend and can help organize. Cheers, Alister Scott Brisbane, Australia Watir Wiki Master: http://watir.com Blog: http://watirmelon.com Google: http://www.google.com/profiles/alister.scott LinkedIn: http://www.linkedin.com/in/alisterscott On 12/10/2010, at 11:46 AM, Bret Pettichord wrote: Every couple of years, I've been holding a 3-day workshop in Austin called AWTA. http://awta.wikispaces.com/AWTA+2009 We are discussing whether to hold another such event, sometime early next year. I'd be particularly keen to hold the event if I were able to attract several of the active Watir contributors. There is no cost to attend the event for people traveling from overseas, except for your travel/room etc (which can be considerable). Could you please let me know if this is something you might be able to attend? Bret -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord _______________________________________________ Wtr-development mailing list Wtr-development at rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-development -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Tue Oct 12 12:18:20 2010 From: watirjira at gmail.com (Jason McInerney (JIRA)) Date: Tue, 12 Oct 2010 11:18:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-165) Watir's new wait logic doesn't always wait for all frames to load Message-ID: <28177287.6.1286900300404.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19910#action_19910 ] Jason McInerney commented on WTR-165: ------------------------------------- I just came across this issue after installing 1.6.6, on Windows XP, IE6 unknown property or method `value' HRESULT error code:0x80070005 Access is denied. (WIN32OLERuntimeError) ======================== Steps to reproduce. ========================= Go to the page, Select a value from a dropdown that executes this: onchange="javascript:setTimeout('__doPostBack(\'ApplicationViewPageBanner1$selAltUsers\',\'\')', 0)" I get the error because the page has not loaded yet. The page has 0 frames when I do a show_frames. script: ================= require 'watir' url = 'https://appurl/' Watir::IE.new.goto(url) ie = Watir::IE.attach(:title, /titlehere/) ie.select_list(:index, 1).set(/TestUser03/) ie.text_field(:id, 'txtECN').set('123456789') C:/Ruby187/lib/ruby/gems/1.8/gems/watir-1.6.6/lib/watir/input_elements.rb:411:in `method_missing': unknown property or method `value' (WIN32OLERuntimeError) HRESULT error code:0x80070005 Access is denied. from C:/Ruby187/lib/ruby/gems/1.8/gems/watir-1.6.6/lib/watir/input_elements.rb:411:in `type_by_character' from C:/Ruby187/lib/ruby/gems/1.8/gems/watir-1.6.6/lib/watir/input_elements.rb:424:in `characters_in' from C:/Ruby187/lib/ruby/gems/1.8/gems/watir-1.6.6/lib/watir/input_elements.rb:409:in `type_by_character' from C:/Ruby187/lib/ruby/gems/1.8/gems/watir-1.6.6/lib/watir/input_elements.rb:375:in `set' from C:/workspace/AppName/trunk/lib/scratch2.rb:6 > Watir's new wait logic doesn't always wait for all frames to load > ----------------------------------------------------------------- > > Key: WTR-165 > URL: http://jira.openqa.org/browse/WTR-165 > Project: Watir > Issue Type: Bug > Components: Frame, Wait > Affects Versions: 1.5.0/1.5.1 > Environment: Win XP Pro > IE 7 > Watir Gem 1.5.1.1166 > ruby 1.8.5.21 > Reporter: David Brown > Fix For: Soon > > > I've been using the development gem 1.5.1.1166 which includes the > re-written wait logic to test a complex SAP web application. The main > content that I am automating is nested 4 frames deep. Up until this > past Friday this version of watir seemed to handle waiting for all of > the inner frames to load properly. Now however this wait logic isn't > always waiting until the pages load completely which causes my scripts > to fail. I don't think there have been any changes in the web app I'm > testing which would cause this. I did happen to install the > important/critical Microsoft security patches for June which could have > effected watir? > http://www.microsoft.com/technet/security/bulletin/ms07-jun.mspx > Has any one else experienced this problem with the new wait logic not > waiting quite long enough when there are many nested frames? > I wish this was a public web-app so I could provide an example w/html to > look at but it's not. > > Gems prior to 1.5.1.1166 would either give me the access denied errors > > as it tried to wait for the inner frames to load - or if those were > > suppressed, I had to put in a manual wait whenever I navigated to a new > > page: "sleep 0.1 until some_element_on_inner_frame.exists?". After > > installing 1166 all of these delay problems were fixed... Until now. > > > > Now that this issue has surfaced I'm forced to put the manual delays in > > again. It is not a big deal to do this, but, it's always cleaner if > > watir handles the delays properly. > In order to help narrow down the issue i've included a test script below which adds some extra logging to the watir wait method, and provides an example of the output I get when running it against my application. > ###############TEST SCRIPT ################ > require 'watir' > module Watir > class IE > # Block execution until the page has loaded. > # =nodoc > # Note: This code needs to be prepared for the ie object to be closed at > # any moment! > def wait(no_sleep=false) > @rexmlDomobject = nil > @down_load_time = 0.0 > a_moment = 0.2 # seconds > start_load_time = Time.now > begin > while @ie.busy # XXX need to add time out > sleep a_moment > end > until @ie.readyState == READYSTATE_COMPLETE do > sleep a_moment > end > sleep a_moment > until @ie.document do > sleep a_moment > end > docNum = 0 > documents_to_wait_for = [@ie.document] > rescue WIN32OLERuntimeError # IE window must have been closed > @down_load_time = Time.now - start_load_time > sleep @defaultSleepTime unless no_sleep > return @down_load_time > end > while doc = documents_to_wait_for.shift > docNum +=1 > begin > tsleep = Time.now > until doc.readyState == "complete" do > sleep a_moment > end > tsleep = Time.now - tsleep > puts "** waited #{tsleep} seconds for doc['#{docNum}'].readyState == 'complete'" > numFrames = doc.frames.length > @url_list << doc.url unless @url_list.include?(doc.url) > doc.frames.length.times do |n| > begin > documents_to_wait_for << doc.frames[n.to_s].document > puts "\t ** Adding Frame #{n+1} of #{numFrames} of document:'#{docNum}' as doc['#{docNum + n+1}']" > rescue WIN32OLERuntimeError > puts "\t ** WIN32OLERuntimeError Raised and Handled when Adding Frame #{n+1} of #{numFrames} of document:'#{docNum}' as doc['#{docNum + n+1}'] \n #{$!} \n\n" > end > end > rescue WIN32OLERuntimeError > puts "WIN32OLERuntimeError Raised and Handled when processing frames for doc['#{docNum}'] \n#{$!} \n #{$@.join("\n")} \n\n" > end > end > @down_load_time = Time.now - start_load_time > run_error_checks > sleep @defaultSleepTime unless no_sleep > @down_load_time > end > end > end > ie = Watir::IE.attach(:title,/SAP Netweaver/i) > puts "\n\n\n ****** Going to Accounts Screen Now ********" > ie.link(:text,'Accounts').click > dtime = ie.down_load_time > t = Time.now > #wait until the content of the innner frame is realy done loading. > sleep 0.1 until ie.frame(:name,/Desktop/).frame(:id,'isolatedWorkArea').frame(:name, 'crmA').frame(:name,/_B/).cell(:text,'Accounts').exists? > t = Time.now - t > puts "Navigated to Accounts: Watir waited:#{dtime} seconds - Inner Frame content wasn't available for another #{t} seconds" > ########SCRIPT OUTPUT############### > ****** Going to Accounts Screen Now ******** > ** waited 0.0 seconds for doc['1'].readyState == 'complete' > ** Adding Frame 1 of 3 of document:'1' as doc['2'] > ** Adding Frame 2 of 3 of document:'1' as doc['3'] > ** Adding Frame 3 of 3 of document:'1' as doc['4'] > ** waited 0.0 seconds for doc['2'].readyState == 'complete' > ** waited 0.0 seconds for doc['3'].readyState == 'complete' > ** waited 0.656 seconds for doc['4'].readyState == 'complete' > ** Adding Frame 1 of 2 of document:'4' as doc['5'] > ** Adding Frame 2 of 2 of document:'4' as doc['6'] > ** waited 0.0 seconds for doc['5'].readyState == 'complete' > ** waited 0.625 seconds for doc['6'].readyState == 'complete' > ** Adding Frame 1 of 1 of document:'6' as doc['7'] > ** waited 0.0 seconds for doc['7'].readyState == 'complete' > ** WIN32OLERuntimeError Raised and Handled when Adding Frame 1 of 2 of document:'7' as doc['8'] > document > OLE error code:80070005 in > Access is denied. > HRESULT error code:0x80020009 > Exception occurred. > ** Adding Frame 2 of 2 of document:'7' as doc['9'] > WIN32OLERuntimeError Raised and Handled when processing frames for doc['8'] > unknown property or method `readyState' > HRESULT error code:0x80070005 > Access is denied. > test_wait.rb:38:in `method_missing' > test_wait.rb:38:in `wait' > c:/ruby/lib/ruby/gems/1.8/gems/watir-1.5.1.1166/./watir.rb:2574:in `click' > test_wait.rb:69 > Navigated to Accounts: Watir waited:6.936 seconds - Inner Frame content wasn't available for another 1.297 seconds > ####################Frame info ################# > $ie.show_frames > there are 3 frames > frame index: 1 name: sapPopupMainId_X0 > frame index: 2 name: obnNavIFrame > frame index: 3 name: Desktop Innerpage > > ie.frame(:index,3).show_frames > there are 2 frames > frame index: 1 name: sapPopupMainId_X0 > frame index: 2 name: isolatedWorkArea > ie.frame(:index,3).frame(:index,2).show_frames > there are 1 frames > frame index: 1 name: crmA > ie.frame(:index,3).frame(:index,2).frame(:index,1).show_frames > there are 2 frames > frame index: 1 Access Denied, see http://wiki.openqa.org/display/WTR/FAQ#access-denied > frame index: 2 name: 4678CFD23E1209F4E100000093225E68_B ####### THIS IS THE FRAME THAT HAS THE CONTENT that watir isn't waiting for to load. ####### -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Tue Oct 12 12:23:19 2010 From: watirjira at gmail.com (Jason McInerney (JIRA)) Date: Tue, 12 Oct 2010 11:23:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-457) FileField.set("") hangs inconsistently and not guranteed to work all the time, better workaround/fix included here In-Reply-To: <29076443.1186.1286577751204.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <8201963.9.1286900599821.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19911#action_19911 ] Jason McInerney commented on WTR-457: ------------------------------------- I have this issue with 1.6.5 on IE6, Windows XP Interestingly, the first time a test uses this, it hangs. Then every test afterward works fine. I will add more to comment if I can find anything else. > FileField.set("") hangs inconsistently and not guranteed to work all the time, better workaround/fix included here > ----------------------------------------------------------------------------------------------------------------------------- > > Key: WTR-457 > URL: http://jira.openqa.org/browse/WTR-457 > Project: Watir > Issue Type: Improvement > Components: Inputs > Affects Versions: 1.6.2, 1.6.5 > Environment: Windows XP SP2, (Ruby 1.8.26, Watir 1.6.2) OR (Ruby 1.8.7-p299, Watir 1.6.5) > Reporter: Yogesh Prajapati > Assignee: Jarmo Pertman > Priority: Blocker > Attachments: input_elements.rb > > > When trying trying to upload a file using file input field, I am using the WATIR api $ie.file_field(:id, "fileupload").set("#{aFileName.to_s}"), the sometimes IE seemed to open "file open" dialog, it will set the file path correctly and close the "file open" dialog box fine and the file input field get populated correctly with expected file path, but majority of the times the dialog box will stay open (hanging) and no file name/path set in "File Name" edit field and nothing happens there after. > I kind of played around changing sleep time in "input_elements.rb:FileField.set()" method to make it work. What I noticed that higher sleeping time made the problem worse. > By understanding little bit more about what the "set()" is trying to do, it seemed like a callback method (after file open dialog box pops up). So as it says on the line for sleep commands, "it takes some time for popup to appear", it sounded like that it is too early to make a sleep call i.e. before launching a separate new process to set the file location in dialog. It is apparent that the wait (sleep) should rather be done within the new process launched by making 'system' call instead of putting the enclosing thread to wait even before starting the new process. > Having said that, by putting the thread to wait before launching new process, file open dialog box pops up and entire ruby process waits for manually input (to me it meant broken automated workflow) and that's not acceptable. > So the fix to issue of hanging file open dialog box move line "sleep 1..." withing system call (i.e. "system %{ruby -e '...." ) just below line 'require "win32ole"' and may be increase sleep time to 2 or 4 seconds depending up fast or slow machine. > The fix for me with 4 seconds sleep time worked equally good on both slow (Pentium4, WinXP SP2) and fast (Core2Duo, WinXP SP2) machines. Please find the updated "input_elements.rb" attached here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Tue Oct 12 12:34:19 2010 From: watirjira at gmail.com (Ning Cao (JIRA)) Date: Tue, 12 Oct 2010 11:34:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Created: (WTR-458) Watir version 1.6.6 doesn't show correct version number Message-ID: <20139552.12.1286901259841.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Watir version 1.6.6 doesn't show correct version number ------------------------------------------------------- Key: WTR-458 URL: http://jira.openqa.org/browse/WTR-458 Project: Watir Issue Type: Bug Components: Gem installer Affects Versions: 1.6.6 Environment: Windows XP, IE8 Reporter: Ning Cao Priority: Major I'm running Watir on Windows XP and just updated to version 1.6.6, after the installation I wanted to check the version by using ruby -e 'require "watir"; puts Watir::IE::VERSION' [expected]Should show version number 1.6.6 [actual]The output was: -e:1: warning: toplevel constant VERSION referenced by Watir::IE::VERSION 1.8.6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Tue Oct 12 14:57:20 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Tue, 12 Oct 2010 13:57:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-165) Watir's new wait logic doesn't always wait for all frames to load Message-ID: <20898303.15.1286909840079.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19912#action_19912 ] Jarmo Pertman commented on WTR-165: ----------------------------------- Unfortunately the code provided by you is not reproducable since no-one else except you has this __doPostBack method with those arguments. If you could give some more abstract or general code with reproducible problem, then we could help. Does it work fine with 1.6.5? > Watir's new wait logic doesn't always wait for all frames to load > ----------------------------------------------------------------- > > Key: WTR-165 > URL: http://jira.openqa.org/browse/WTR-165 > Project: Watir > Issue Type: Bug > Components: Frame, Wait > Affects Versions: 1.5.0/1.5.1 > Environment: Win XP Pro > IE 7 > Watir Gem 1.5.1.1166 > ruby 1.8.5.21 > Reporter: David Brown > Fix For: Soon > > > I've been using the development gem 1.5.1.1166 which includes the > re-written wait logic to test a complex SAP web application. The main > content that I am automating is nested 4 frames deep. Up until this > past Friday this version of watir seemed to handle waiting for all of > the inner frames to load properly. Now however this wait logic isn't > always waiting until the pages load completely which causes my scripts > to fail. I don't think there have been any changes in the web app I'm > testing which would cause this. I did happen to install the > important/critical Microsoft security patches for June which could have > effected watir? > http://www.microsoft.com/technet/security/bulletin/ms07-jun.mspx > Has any one else experienced this problem with the new wait logic not > waiting quite long enough when there are many nested frames? > I wish this was a public web-app so I could provide an example w/html to > look at but it's not. > > Gems prior to 1.5.1.1166 would either give me the access denied errors > > as it tried to wait for the inner frames to load - or if those were > > suppressed, I had to put in a manual wait whenever I navigated to a new > > page: "sleep 0.1 until some_element_on_inner_frame.exists?". After > > installing 1166 all of these delay problems were fixed... Until now. > > > > Now that this issue has surfaced I'm forced to put the manual delays in > > again. It is not a big deal to do this, but, it's always cleaner if > > watir handles the delays properly. > In order to help narrow down the issue i've included a test script below which adds some extra logging to the watir wait method, and provides an example of the output I get when running it against my application. > ###############TEST SCRIPT ################ > require 'watir' > module Watir > class IE > # Block execution until the page has loaded. > # =nodoc > # Note: This code needs to be prepared for the ie object to be closed at > # any moment! > def wait(no_sleep=false) > @rexmlDomobject = nil > @down_load_time = 0.0 > a_moment = 0.2 # seconds > start_load_time = Time.now > begin > while @ie.busy # XXX need to add time out > sleep a_moment > end > until @ie.readyState == READYSTATE_COMPLETE do > sleep a_moment > end > sleep a_moment > until @ie.document do > sleep a_moment > end > docNum = 0 > documents_to_wait_for = [@ie.document] > rescue WIN32OLERuntimeError # IE window must have been closed > @down_load_time = Time.now - start_load_time > sleep @defaultSleepTime unless no_sleep > return @down_load_time > end > while doc = documents_to_wait_for.shift > docNum +=1 > begin > tsleep = Time.now > until doc.readyState == "complete" do > sleep a_moment > end > tsleep = Time.now - tsleep > puts "** waited #{tsleep} seconds for doc['#{docNum}'].readyState == 'complete'" > numFrames = doc.frames.length > @url_list << doc.url unless @url_list.include?(doc.url) > doc.frames.length.times do |n| > begin > documents_to_wait_for << doc.frames[n.to_s].document > puts "\t ** Adding Frame #{n+1} of #{numFrames} of document:'#{docNum}' as doc['#{docNum + n+1}']" > rescue WIN32OLERuntimeError > puts "\t ** WIN32OLERuntimeError Raised and Handled when Adding Frame #{n+1} of #{numFrames} of document:'#{docNum}' as doc['#{docNum + n+1}'] \n #{$!} \n\n" > end > end > rescue WIN32OLERuntimeError > puts "WIN32OLERuntimeError Raised and Handled when processing frames for doc['#{docNum}'] \n#{$!} \n #{$@.join("\n")} \n\n" > end > end > @down_load_time = Time.now - start_load_time > run_error_checks > sleep @defaultSleepTime unless no_sleep > @down_load_time > end > end > end > ie = Watir::IE.attach(:title,/SAP Netweaver/i) > puts "\n\n\n ****** Going to Accounts Screen Now ********" > ie.link(:text,'Accounts').click > dtime = ie.down_load_time > t = Time.now > #wait until the content of the innner frame is realy done loading. > sleep 0.1 until ie.frame(:name,/Desktop/).frame(:id,'isolatedWorkArea').frame(:name, 'crmA').frame(:name,/_B/).cell(:text,'Accounts').exists? > t = Time.now - t > puts "Navigated to Accounts: Watir waited:#{dtime} seconds - Inner Frame content wasn't available for another #{t} seconds" > ########SCRIPT OUTPUT############### > ****** Going to Accounts Screen Now ******** > ** waited 0.0 seconds for doc['1'].readyState == 'complete' > ** Adding Frame 1 of 3 of document:'1' as doc['2'] > ** Adding Frame 2 of 3 of document:'1' as doc['3'] > ** Adding Frame 3 of 3 of document:'1' as doc['4'] > ** waited 0.0 seconds for doc['2'].readyState == 'complete' > ** waited 0.0 seconds for doc['3'].readyState == 'complete' > ** waited 0.656 seconds for doc['4'].readyState == 'complete' > ** Adding Frame 1 of 2 of document:'4' as doc['5'] > ** Adding Frame 2 of 2 of document:'4' as doc['6'] > ** waited 0.0 seconds for doc['5'].readyState == 'complete' > ** waited 0.625 seconds for doc['6'].readyState == 'complete' > ** Adding Frame 1 of 1 of document:'6' as doc['7'] > ** waited 0.0 seconds for doc['7'].readyState == 'complete' > ** WIN32OLERuntimeError Raised and Handled when Adding Frame 1 of 2 of document:'7' as doc['8'] > document > OLE error code:80070005 in > Access is denied. > HRESULT error code:0x80020009 > Exception occurred. > ** Adding Frame 2 of 2 of document:'7' as doc['9'] > WIN32OLERuntimeError Raised and Handled when processing frames for doc['8'] > unknown property or method `readyState' > HRESULT error code:0x80070005 > Access is denied. > test_wait.rb:38:in `method_missing' > test_wait.rb:38:in `wait' > c:/ruby/lib/ruby/gems/1.8/gems/watir-1.5.1.1166/./watir.rb:2574:in `click' > test_wait.rb:69 > Navigated to Accounts: Watir waited:6.936 seconds - Inner Frame content wasn't available for another 1.297 seconds > ####################Frame info ################# > $ie.show_frames > there are 3 frames > frame index: 1 name: sapPopupMainId_X0 > frame index: 2 name: obnNavIFrame > frame index: 3 name: Desktop Innerpage > > ie.frame(:index,3).show_frames > there are 2 frames > frame index: 1 name: sapPopupMainId_X0 > frame index: 2 name: isolatedWorkArea > ie.frame(:index,3).frame(:index,2).show_frames > there are 1 frames > frame index: 1 name: crmA > ie.frame(:index,3).frame(:index,2).frame(:index,1).show_frames > there are 2 frames > frame index: 1 Access Denied, see http://wiki.openqa.org/display/WTR/FAQ#access-denied > frame index: 2 name: 4678CFD23E1209F4E100000093225E68_B ####### THIS IS THE FRAME THAT HAS THE CONTENT that watir isn't waiting for to load. ####### -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Tue Oct 12 15:06:19 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Tue, 12 Oct 2010 14:06:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-458) Watir version 1.6.6 doesn't show correct version number In-Reply-To: <20139552.12.1286901259841.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <14684230.17.1286910379851.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19913#action_19913 ] Jarmo Pertman commented on WTR-458: ----------------------------------- That's because there's not a constant Watir::IE::VERSION starting from 1.6.6 anymore. See the following irb session: irb(main):001:0> require "watir" => true irb(main):003:0> Watir::IE.constants.grep /VERSION/ => [] irb(main):004:0> VERSION => "1.8.6" irb(main):005:0> Watir::IE::VERSION (irb):5: warning: toplevel constant VERSION referenced by Watir::IE::VERSION => "1.8.6" So, actually a VERSION constant, which is a top-level one - a Ruby one, will be outputted. Is there any actual use-case where this version should be accessible? > Watir version 1.6.6 doesn't show correct version number > ------------------------------------------------------- > > Key: WTR-458 > URL: http://jira.openqa.org/browse/WTR-458 > Project: Watir > Issue Type: Bug > Components: Gem installer > Affects Versions: 1.6.6 > Environment: Windows XP, IE8 > Reporter: Ning Cao > Priority: Major > > I'm running Watir on Windows XP and just updated to version 1.6.6, after the installation I wanted to check the version by using > ruby -e 'require "watir"; puts Watir::IE::VERSION' > [expected]Should show version number 1.6.6 > [actual]The output was: > -e:1: warning: toplevel constant VERSION referenced by Watir::IE::VERSION > 1.8.6 -- 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 Tue Oct 12 15:22:31 2010 From: paul.rogers at shaw.ca (Paul Rogers) Date: Tue, 12 Oct 2010 13:22:31 -0600 Subject: [Wtr-development] Fwd: Watir Advertising In-Reply-To: <20101012120140.mwps8kx12c8w88o0@box580.bluehost.com> References: <20100824124730.4r7k61i1usosgcw4@box580.bluehost.com> <20101012120140.mwps8kx12c8w88o0@box580.bluehost.com> Message-ID: hardly seems worth it...... ---------- Forwarded message ---------- From: Date: Tue, Oct 12, 2010 at 12:01 PM Subject: Re: Watir Advertising To: Paul Rogers Hi Paul, My client is interested in banner advertising. Would it be possible to put a one year long banner for $60? Thanks, Alexia Quoting Paul Rogers : > Hi Alexia, > > Im assuming you mean watir.com? What kind of things would yoju be > advertising and how much would it pay? > > Thanks > > Paul > > On Tue, Aug 24, 2010 at 12:47 PM, wrote: > >> Hi Paul, >> >> I came across your site and I found it really interesting. The reason I'm >> contacting you today is that a client of mine is looking to advertise and I >> thought your website would be a great fit. I was wondering whether you had >> any advertising opportunities available? >> >> Thanks, >> Alexia >> >> >> > From watirjira at gmail.com Wed Oct 13 08:01:19 2010 From: watirjira at gmail.com (problem_child (JIRA)) Date: Wed, 13 Oct 2010 07:01:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Created: (WTR-459) click_no_wait does not work in ruby 1.8.6 (2007-09-24 patchlevel 111) Message-ID: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> click_no_wait does not work in ruby 1.8.6 (2007-09-24 patchlevel 111) --------------------------------------------------------------------- Key: WTR-459 URL: http://jira.openqa.org/browse/WTR-459 Project: Watir Issue Type: Bug Components: Wait Affects Versions: 1.6.6 Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 Reporter: problem_child Priority: Blocker click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 $frame.button(:name, "button1").click_no_wait =>nil If I use $frame.button(:name, "button1").click it works so it is finding the object. But using click_no_wait results in nill using IRB. An error is not reported otherwise. -- 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 Oct 13 08:15:19 2010 From: watirjira at gmail.com (Alister Scott (JIRA)) Date: Wed, 13 Oct 2010 07:15:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-459) click_no_wait does not work in ruby 1.8.6 (2007-09-24 patchlevel 111) In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <2129472.26.1286972119841.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19915#action_19915 ] Alister Scott commented on WTR-459: ----------------------------------- I thought this was fixed by http://jira.openqa.org/browse/WTR-320 > click_no_wait does not work in ruby 1.8.6 (2007-09-24 patchlevel 111) > --------------------------------------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- 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 Oct 13 08:27:19 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 13 Oct 2010 07:27:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-459) click_no_wait does not work in ruby 1.8.6 (2007-09-24 patchlevel 111) In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <8112676.28.1286972839831.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19916#action_19916 ] Jarmo Pertman commented on WTR-459: ----------------------------------- set $DEBUG to true right before click_no_wait and copy here the results: $DEBUG = true $frame.button(:name, "button1").click_no_wait $DEBUG = false > click_no_wait does not work in ruby 1.8.6 (2007-09-24 patchlevel 111) > --------------------------------------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- 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 Oct 13 08:52:20 2010 From: watirjira at gmail.com (problem_child (JIRA)) Date: Wed, 13 Oct 2010 07:52:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-459) click_no_wait does not work in ruby 1.8.6 (2007-09-24 patchlevel 111) In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <7910210.30.1286974340234.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19917#action_19917 ] problem_child commented on WTR-459: ----------------------------------- #click_no_wait command: ruby -e "require 'rubygems';require 'C:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.6/lib/watir/core';Watir::Button.new(Watir::IE.attach(:hwnd, 4654902).frame(:name, \"frmMain\"), :unique_number, 1).click!" Exception `WIN32OLERuntimeError' at C:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.6/lib/watir/element.rb:207 - OLE error code:0 in HRESULT error code:0x80070057 The parameter is incorrect. C:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.6/lib/watir/container.rb:104:in `frame': uninitialized constant Watir::Container::Frame (NameError) from -e:1 => nil > click_no_wait does not work in ruby 1.8.6 (2007-09-24 patchlevel 111) > --------------------------------------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- 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 Oct 13 09:06:20 2010 From: watirjira at gmail.com (problem_child (JIRA)) Date: Wed, 13 Oct 2010 08:06:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-459) click_no_wait does not work in ruby 1.8.6 (2007-09-24 patchlevel 111) In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <3826493.32.1286975180116.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19918#action_19918 ] problem_child commented on WTR-459: ----------------------------------- Alister: WTR-320 was tested with : ruby 1.8.7 I am using the recommended ruby environment 1.8.6 p111 using windows XP > click_no_wait does not work in ruby 1.8.6 (2007-09-24 patchlevel 111) > --------------------------------------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From zeljko.filipin at wa-research.ch Wed Oct 13 10:50:35 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 13 Oct 2010 16:50:35 +0200 Subject: [Wtr-development] inspect Message-ID: I am looking at output of inspect method for page elements and it looks like this: #"file.txt"} what=nil> 1) Instead of `how={:text=>"file.txt"} what=nil` there should be `how=:text what="file.txt"` (I plan to fix it in the near future.) 2) what does `located=true` mean? I would delete it, but I guess somebody needs it, since we have it. ?eljko -- watir.com - community manager watirpodcast.com - host testingpodcast.com - audio podcasts on software testing. all of them -------------- next part -------------- An HTML attachment was scrubbed... URL: From jari.bakken at gmail.com Wed Oct 13 11:07:27 2010 From: jari.bakken at gmail.com (Jari Bakken) Date: Wed, 13 Oct 2010 17:07:27 +0200 Subject: [Wtr-development] inspect In-Reply-To: References: Message-ID: On Wed, Oct 13, 2010 at 4:50 PM, ?eljko Filipin wrote: > > 2) what does `located=true` mean? I would delete it, but I guess somebody > needs it, since we have it. > Elements in Watir are lazily located, that means we don't actually look for the element on the page when you call browser.link(:text => "file.txt") We just return an object that knows *how to find* the element. When you try to use the object (i.e. Element#exists?, Link#href, etc.) do we actully look for the element on the page - and that's what will raise UnknownObjectExceptions et al. So the output will be located=false before you call a method on the object, then located=true after you've used it. From notethan at gmail.com Wed Oct 13 11:38:52 2010 From: notethan at gmail.com (Ethan) Date: Wed, 13 Oct 2010 11:38:52 -0400 Subject: [Wtr-development] inspect In-Reply-To: References: Message-ID: what would it look like for an element specified with multiple hash values, like container.text_field(:text => 'file.txt', :class => 'fooclass'}) ? On Wed, Oct 13, 2010 at 10:50, ?eljko Filipin wrote: > I am looking at output of inspect method for page elements and it looks > like this: > > #"file.txt"} what=nil> > > 1) Instead of `how={:text=>"file.txt"} what=nil` there should be `how=:text > what="file.txt"` (I plan to fix it in the near future.) > > 2) what does `located=true` mean? I would delete it, but I guess somebody > needs it, since we have it. > > ?eljko > -- > watir.com - community manager > watirpodcast.com - host > testingpodcast.com - audio podcasts on software testing. all of them > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jari.bakken at gmail.com Wed Oct 13 12:52:24 2010 From: jari.bakken at gmail.com (Jari Bakken) Date: Wed, 13 Oct 2010 18:52:24 +0200 Subject: [Wtr-development] inspect In-Reply-To: References: Message-ID: On Wed, Oct 13, 2010 at 5:38 PM, Ethan wrote: > what would it look like for an element specified with multiple hash values, > like container.text_field(:text => 'file.txt', :class => 'fooclass'}) ? In watir-webdriver, I have this: #"foo", :text=>"bar", :tag_name=>"div"}> :tag_name being part of the selector is admittedly an implementation detail. From jarmo.p at gmail.com Wed Oct 13 12:52:14 2010 From: jarmo.p at gmail.com (Jarmo) Date: Wed, 13 Oct 2010 19:52:14 +0300 Subject: [Wtr-development] inspect In-Reply-To: References: Message-ID: On Wed, Oct 13, 2010 at 6:38 PM, Ethan wrote: > what would it look like for an element specified with multiple hash values, > like container.text_field(:text => 'file.txt', :class => 'fooclass'}) ? That's exactly the question i would've asked. Jarmo From watirjira at gmail.com Wed Oct 13 14:14:20 2010 From: watirjira at gmail.com (Ning Cao (JIRA)) Date: Wed, 13 Oct 2010 13:14:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-458) Watir version 1.6.6 doesn't show correct version number In-Reply-To: <20139552.12.1286901259841.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <20183527.35.1286993660504.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19919#action_19919 ] Ning Cao commented on WTR-458: ------------------------------ I'm not actually using this version for any testing, just simply wanted to check the Watir version number installed on my system, if the above command not working, what is the correct commande to check installed Watir version? > Watir version 1.6.6 doesn't show correct version number > ------------------------------------------------------- > > Key: WTR-458 > URL: http://jira.openqa.org/browse/WTR-458 > Project: Watir > Issue Type: Bug > Components: Gem installer > Affects Versions: 1.6.6 > Environment: Windows XP, IE8 > Reporter: Ning Cao > Priority: Major > > I'm running Watir on Windows XP and just updated to version 1.6.6, after the installation I wanted to check the version by using > ruby -e 'require "watir"; puts Watir::IE::VERSION' > [expected]Should show version number 1.6.6 > [actual]The output was: > -e:1: warning: toplevel constant VERSION referenced by Watir::IE::VERSION > 1.8.6 -- 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 Oct 13 14:54:20 2010 From: watirjira at gmail.com (Ethan (JIRA)) Date: Wed, 13 Oct 2010 13:54:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-458) Watir version 1.6.6 doesn't show correct version number In-Reply-To: <20139552.12.1286901259841.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <2504037.37.1286996060020.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19920#action_19920 ] Ethan commented on WTR-458: --------------------------- I think that programatically checking the version can be useful, in general (not specifically to watir, but certainly applies). I've worked around bugs in certain versions of libraries by checking version, for example. It's possible to get the installed version via rubygems, but not really trivial. I think having a version constant is useful. > Watir version 1.6.6 doesn't show correct version number > ------------------------------------------------------- > > Key: WTR-458 > URL: http://jira.openqa.org/browse/WTR-458 > Project: Watir > Issue Type: Bug > Components: Gem installer > Affects Versions: 1.6.6 > Environment: Windows XP, IE8 > Reporter: Ning Cao > Priority: Major > > I'm running Watir on Windows XP and just updated to version 1.6.6, after the installation I wanted to check the version by using > ruby -e 'require "watir"; puts Watir::IE::VERSION' > [expected]Should show version number 1.6.6 > [actual]The output was: > -e:1: warning: toplevel constant VERSION referenced by Watir::IE::VERSION > 1.8.6 -- 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 Oct 13 15:59:20 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 13 Oct 2010 14:59:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-458) Watir version 1.6.6 doesn't show correct version number In-Reply-To: <20139552.12.1286901259841.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <26782271.39.1286999960209.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19921#action_19921 ] Charley Baker commented on WTR-458: ----------------------------------- It's standard, easy enough to do and should be fixed for the next version. > Watir version 1.6.6 doesn't show correct version number > ------------------------------------------------------- > > Key: WTR-458 > URL: http://jira.openqa.org/browse/WTR-458 > Project: Watir > Issue Type: Bug > Components: Gem installer > Affects Versions: 1.6.6 > Environment: Windows XP, IE8 > Reporter: Ning Cao > Priority: Major > > I'm running Watir on Windows XP and just updated to version 1.6.6, after the installation I wanted to check the version by using > ruby -e 'require "watir"; puts Watir::IE::VERSION' > [expected]Should show version number 1.6.6 > [actual]The output was: > -e:1: warning: toplevel constant VERSION referenced by Watir::IE::VERSION > 1.8.6 -- 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 Oct 13 16:06:20 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 13 Oct 2010 15:06:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-459) click_no_wait does not work in ruby 1.8.6 (2007-09-24 patchlevel 111) In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <20697912.41.1287000380241.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19922#action_19922 ] Jarmo Pertman commented on WTR-459: ----------------------------------- There was indeed a bug with using #click_no_wait with frames caused by their difference from other elements and not loading Watir::Frame class for #click_no_wait process. It will be fixed in 1.6.7, but you can fix it locally by adding require "watir/frame" into watir/core.rb right after require "page-container". If this fixes your problem then it's good. If not, then check what other error messages do you get when using $DEBUG = true. It could be also possible that you'd need to edit Frame#attach_command as seen from the commit link below. Commit, which fixes the problem is seen here: http://github.com/bret/watir/commit/5b942c7569c47155bb1d9ccbf3f5aa030e48a9da > click_no_wait does not work in ruby 1.8.6 (2007-09-24 patchlevel 111) > --------------------------------------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- 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 Oct 13 16:06:20 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 13 Oct 2010 15:06:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-459) click_no_wait does not work with frames In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <18502224.44.1287000380307.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarmo Pertman updated WTR-459: ------------------------------ Assignee: Jarmo Pertman Summary: click_no_wait does not work with frames (was: click_no_wait does not work in ruby 1.8.6 (2007-09-24 patchlevel 111)) > click_no_wait does not work with frames > --------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Assignee: Jarmo Pertman > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- 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 Oct 13 16:24:19 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 13 Oct 2010 15:24:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-458) Watir version 1.6.6 doesn't show correct version number In-Reply-To: <20139552.12.1286901259841.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <7016697.46.1287001459798.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19923#action_19923 ] Jarmo Pertman commented on WTR-458: ----------------------------------- I still don't see much of a point having that as a constant. As Ethan pointed out then you can do it with Rubygems and it's nothing hard to do either! Gem.loaded_specs["watir"].version.to_s # => "1.6.6" Do we still need the constant itself? I deleted it purposefully at the time, but can add it back if it's really-really-really needed. Working around bugs could be also done with Rubygems with "gem 'gem', '=version'" instead of using some if-statements to read some values of some constants. > Watir version 1.6.6 doesn't show correct version number > ------------------------------------------------------- > > Key: WTR-458 > URL: http://jira.openqa.org/browse/WTR-458 > Project: Watir > Issue Type: Bug > Components: Gem installer > Affects Versions: 1.6.6 > Environment: Windows XP, IE8 > Reporter: Ning Cao > Priority: Major > > I'm running Watir on Windows XP and just updated to version 1.6.6, after the installation I wanted to check the version by using > ruby -e 'require "watir"; puts Watir::IE::VERSION' > [expected]Should show version number 1.6.6 > [actual]The output was: > -e:1: warning: toplevel constant VERSION referenced by Watir::IE::VERSION > 1.8.6 -- 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 Wed Oct 13 16:24:03 2010 From: jarmo.p at gmail.com (Jarmo) Date: Wed, 13 Oct 2010 23:24:03 +0300 Subject: [Wtr-development] AWTA workshop in Austin In-Reply-To: <-391526066479601542@unknownmsgid> References: <-391526066479601542@unknownmsgid> Message-ID: I'd love to come also, but i think that it will be too expensive for me unfortunately. Jarmo On Tue, Oct 12, 2010 at 12:18 PM, Alister Scott wrote: > I would love to attend and can help organize. > Cheers, > > Alister Scott > Brisbane, Australia > Watir Wiki Master: http://watir.com > Blog: http://watirmelon.com > Google: http://www.google.com/profiles/alister.scott > LinkedIn: http://www.linkedin.com/in/alisterscott > On 12/10/2010, at 11:46 AM, Bret Pettichord wrote: > > Every couple of years, I've been holding a 3-day workshop in Austin called > AWTA. > http://awta.wikispaces.com/AWTA+2009 > > We are discussing whether to hold another such event, sometime early next > year. > > I'd be particularly keen to hold the event if I were able to attract several > of the active Watir contributors. > > There is no cost to attend the event for people traveling from overseas, > except for your travel/room etc (which can be considerable). > > Could you please let me know if this is something you might be able to > attend? > > Bret > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From bret at pettichord.com Wed Oct 13 17:59:23 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 13 Oct 2010 16:59:23 -0500 Subject: [Wtr-development] AWTA workshop in Austin In-Reply-To: References: <-391526066479601542@unknownmsgid> Message-ID: I've never been to Europe. Maybe I should plan a trip there next summer. Bret On Wed, Oct 13, 2010 at 3:24 PM, Jarmo wrote: > I'd love to come also, but i think that it will be too expensive for > me unfortunately. > > Jarmo > > On Tue, Oct 12, 2010 at 12:18 PM, Alister Scott > wrote: > > I would love to attend and can help organize. > > Cheers, > > > > Alister Scott > > Brisbane, Australia > > Watir Wiki Master: http://watir.com > > Blog: http://watirmelon.com > > Google: http://www.google.com/profiles/alister.scott > > LinkedIn: http://www.linkedin.com/in/alisterscott > > On 12/10/2010, at 11:46 AM, Bret Pettichord wrote: > > > > Every couple of years, I've been holding a 3-day workshop in Austin > called > > AWTA. > > http://awta.wikispaces.com/AWTA+2009 > > > > We are discussing whether to hold another such event, sometime early next > > year. > > > > I'd be particularly keen to hold the event if I were able to attract > several > > of the active Watir contributors. > > > > There is no cost to attend the event for people traveling from overseas, > > except for your travel/room etc (which can be considerable). > > > > Could you please let me know if this is something you might be able to > > attend? > > > > Bret > > > > -- > > Bret Pettichord > > Lead Developer, Watir, www.watir.com > > > > Blog, www.io.com/~wazmo/blog > > Twitter, www.twitter.com/bpettichord > > > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Wed Oct 13 18:22:30 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 13 Oct 2010 17:22:30 -0500 Subject: [Wtr-development] inspect In-Reply-To: References: Message-ID: It looks like this: # 'file.txt', :class => 'fooclass'} what=nil> This would probably be better: # 'file.txt', :class_name => 'fooclass'}> The problem, I think, is that we don't normalize the specifiers until we try to locate the element, so this would only work for located elements. Also, I think that we don't save the normalized specifiers. We could refactor the code so that it inspected better.... Bret On Wed, Oct 13, 2010 at 10:38 AM, Ethan wrote: > what would it look like for an element specified with multiple hash values, > like container.text_field(:text => 'file.txt', :class => 'fooclass'}) ? > > On Wed, Oct 13, 2010 at 10:50, ?eljko Filipin < > zeljko.filipin at wa-research.ch> wrote: > >> I am looking at output of inspect method for page elements and it looks >> like this: >> >> #"file.txt"} what=nil> >> >> 1) Instead of `how={:text=>"file.txt"} what=nil` there should be >> `how=:text what="file.txt"` (I plan to fix it in the near future.) >> >> 2) what does `located=true` mean? I would delete it, but I guess somebody >> needs it, since we have it. >> >> ?eljko >> -- >> watir.com - community manager >> watirpodcast.com - host >> testingpodcast.com - audio podcasts on software testing. all of them >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Wed Oct 13 18:51:20 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 13 Oct 2010 17:51:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-458) Watir version 1.6.6 doesn't show correct version number In-Reply-To: <20139552.12.1286901259841.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <24263948.48.1287010280680.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19924#action_19924 ] Charley Baker commented on WTR-458: ----------------------------------- I'm suggesting adding it back, since it is a Ruby gem standard to have that. Is it of much use, probably not, but it doesn't hurt either. > Watir version 1.6.6 doesn't show correct version number > ------------------------------------------------------- > > Key: WTR-458 > URL: http://jira.openqa.org/browse/WTR-458 > Project: Watir > Issue Type: Bug > Components: Gem installer > Affects Versions: 1.6.6 > Environment: Windows XP, IE8 > Reporter: Ning Cao > Priority: Major > > I'm running Watir on Windows XP and just updated to version 1.6.6, after the installation I wanted to check the version by using > ruby -e 'require "watir"; puts Watir::IE::VERSION' > [expected]Should show version number 1.6.6 > [actual]The output was: > -e:1: warning: toplevel constant VERSION referenced by Watir::IE::VERSION > 1.8.6 -- 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 alex.ikhelis at gmail.com Wed Oct 13 19:36:49 2010 From: alex.ikhelis at gmail.com (Aliaksandr Ikhelis) Date: Thu, 14 Oct 2010 00:36:49 +0100 Subject: [Wtr-development] AWTA workshop in Austin In-Reply-To: References: <-391526066479601542@unknownmsgid> Message-ID: You are more then warmly welcome and awaited in Europe, Bret! Thank you, Aliaksandr Ikhelis On Wed, Oct 13, 2010 at 10:59 PM, Bret Pettichord wrote: > I've never been to Europe. Maybe I should plan a trip there next summer. > > Bret > > > On Wed, Oct 13, 2010 at 3:24 PM, Jarmo wrote: > >> I'd love to come also, but i think that it will be too expensive for >> me unfortunately. >> >> Jarmo >> >> On Tue, Oct 12, 2010 at 12:18 PM, Alister Scott >> wrote: >> > I would love to attend and can help organize. >> > Cheers, >> > >> > Alister Scott >> > Brisbane, Australia >> > Watir Wiki Master: http://watir.com >> > Blog: http://watirmelon.com >> > Google: http://www.google.com/profiles/alister.scott >> > LinkedIn: http://www.linkedin.com/in/alisterscott >> > On 12/10/2010, at 11:46 AM, Bret Pettichord >> wrote: >> > >> > Every couple of years, I've been holding a 3-day workshop in Austin >> called >> > AWTA. >> > http://awta.wikispaces.com/AWTA+2009 >> > >> > We are discussing whether to hold another such event, sometime early >> next >> > year. >> > >> > I'd be particularly keen to hold the event if I were able to attract >> several >> > of the active Watir contributors. >> > >> > There is no cost to attend the event for people traveling from overseas, >> > except for your travel/room etc (which can be considerable). >> > >> > Could you please let me know if this is something you might be able to >> > attend? >> > >> > Bret >> > >> > -- >> > Bret Pettichord >> > Lead Developer, Watir, www.watir.com >> > >> > Blog, www.io.com/~wazmo/blog >> > Twitter, www.twitter.com/bpettichord >> > >> > _______________________________________________ >> > Wtr-development mailing list >> > Wtr-development at rubyforge.org >> > http://rubyforge.org/mailman/listinfo/wtr-development >> > >> > _______________________________________________ >> > Wtr-development mailing list >> > Wtr-development at rubyforge.org >> > http://rubyforge.org/mailman/listinfo/wtr-development >> > >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Wed Oct 13 19:59:20 2010 From: watirjira at gmail.com (Yogesh Prajapati (JIRA)) Date: Wed, 13 Oct 2010 18:59:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-457) FileField.set("") hangs inconsistently and not guranteed to work all the time, better workaround/fix included here In-Reply-To: <29076443.1186.1286577751204.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <24128796.51.1287014360894.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19925#action_19925 ] Yogesh Prajapati commented on WTR-457: -------------------------------------- Thanks for looking into this. I am curious to see what better Windows API could be used to eliminate the issue completely, no workarounds... > FileField.set("") hangs inconsistently and not guranteed to work all the time, better workaround/fix included here > ----------------------------------------------------------------------------------------------------------------------------- > > Key: WTR-457 > URL: http://jira.openqa.org/browse/WTR-457 > Project: Watir > Issue Type: Improvement > Components: Inputs > Affects Versions: 1.6.2, 1.6.5 > Environment: Windows XP SP2, (Ruby 1.8.26, Watir 1.6.2) OR (Ruby 1.8.7-p299, Watir 1.6.5) > Reporter: Yogesh Prajapati > Assignee: Jarmo Pertman > Priority: Blocker > Attachments: input_elements.rb > > > When trying trying to upload a file using file input field, I am using the WATIR api $ie.file_field(:id, "fileupload").set("#{aFileName.to_s}"), the sometimes IE seemed to open "file open" dialog, it will set the file path correctly and close the "file open" dialog box fine and the file input field get populated correctly with expected file path, but majority of the times the dialog box will stay open (hanging) and no file name/path set in "File Name" edit field and nothing happens there after. > I kind of played around changing sleep time in "input_elements.rb:FileField.set()" method to make it work. What I noticed that higher sleeping time made the problem worse. > By understanding little bit more about what the "set()" is trying to do, it seemed like a callback method (after file open dialog box pops up). So as it says on the line for sleep commands, "it takes some time for popup to appear", it sounded like that it is too early to make a sleep call i.e. before launching a separate new process to set the file location in dialog. It is apparent that the wait (sleep) should rather be done within the new process launched by making 'system' call instead of putting the enclosing thread to wait even before starting the new process. > Having said that, by putting the thread to wait before launching new process, file open dialog box pops up and entire ruby process waits for manually input (to me it meant broken automated workflow) and that's not acceptable. > So the fix to issue of hanging file open dialog box move line "sleep 1..." withing system call (i.e. "system %{ruby -e '...." ) just below line 'require "win32ole"' and may be increase sleep time to 2 or 4 seconds depending up fast or slow machine. > The fix for me with 4 seconds sleep time worked equally good on both slow (Pentium4, WinXP SP2) and fast (Core2Duo, WinXP SP2) machines. Please find the updated "input_elements.rb" attached here. -- 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 Oct 14 00:24:19 2010 From: watirjira at gmail.com (Babitha Augusthy (JIRA)) Date: Wed, 13 Oct 2010 23:24:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Created: (WTR-460) DataHandler CSV code doesn't close the file opened Message-ID: <11332569.54.1287030259941.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> DataHandler CSV code doesn't close the file opened -------------------------------------------------- Key: WTR-460 URL: http://jira.openqa.org/browse/WTR-460 Project: Watir Issue Type: Bug Components: Other Affects Versions: 1.6.6, 1.6.5, 1.6.3, 1.6.2, 1.6.1, 1.6.0, 1.5.6, 1.5.5, 1.5.4, 1.5.3, 1.5.2, 1.5.0/1.5.1, Open QA Migration, 1.4.1, 1.4 Environment: All platforms Reporter: Babitha Augusthy Priority: Major The Datahandler.rb code for loading the data from an excel file or csv file, does not close the file if it is a CSV file. The excel instance stays in memory and retains a handle to the csv file opened, thereby rendering the file read-only until the excel instance is killed in Task Manager manually. -- 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 Oct 14 06:15:20 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Thu, 14 Oct 2010 05:15:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-460) DataHandler CSV code doesn't close the file opened In-Reply-To: <11332569.54.1287030259941.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <17432145.61.1287051320656.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19926#action_19926 ] Jarmo Pertman commented on WTR-460: ----------------------------------- Didn't even know that there's something like this part of Watir. Does it even have to be there? Aren't there more suitable gems for that like fastercsv and spreadsheet? Anyone up for deleting that from Watir completely? > DataHandler CSV code doesn't close the file opened > -------------------------------------------------- > > Key: WTR-460 > URL: http://jira.openqa.org/browse/WTR-460 > Project: Watir > Issue Type: Bug > Components: Other > Affects Versions: 1.4, 1.4.1, Open QA Migration, 1.5.0/1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.6.0, 1.6.1, 1.6.2, 1.6.3, 1.6.5, 1.6.6 > Environment: All platforms > Reporter: Babitha Augusthy > Priority: Major > > The Datahandler.rb code for loading the data from an excel file or csv file, does not close the file if it is a CSV file. The excel instance stays in memory and retains a handle to the csv file opened, thereby rendering the file read-only until the excel instance is killed in Task Manager manually. -- 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 Oct 14 06:58:20 2010 From: watirjira at gmail.com (problem_child (JIRA)) Date: Thu, 14 Oct 2010 05:58:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-459) click_no_wait does not work with frames In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <4280040.64.1287053900319.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19927#action_19927 ] problem_child commented on WTR-459: ----------------------------------- After inserting require "watir/frame" into core.rb any test step I take using Watir::IE results in: ($DEBUG = true) -NameError: uninitialized constant Watir::IE (Netbeans IDE) -NameError: uninitialized constant Watir::Frame::PageContainer > click_no_wait does not work with frames > --------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Assignee: Jarmo Pertman > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- 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 Oct 14 07:12:19 2010 From: watirjira at gmail.com (problem_child (JIRA)) Date: Thu, 14 Oct 2010 06:12:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-459) click_no_wait does not work with frames In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <23202233.67.1287054739967.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19928#action_19928 ] problem_child commented on WTR-459: ----------------------------------- After: inserting require "watir/frame" into core.rb. After: -def attach_command @container.page_container.attach_command + ".frame(#{@how.inspect}, #{@what.inspect})".gsub('"','\'') end ($DEGUB=true) ============= Exception `NoMethodError' at C:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.6/lib/watir/element.rb:228 - undefined method `eval_in_spawned_process' for # Exception `NoMethodError' at C:/ruby/lib/ruby/1.8/irb/workspace.rb:81 - undefined method `eval_in_spawned_process' for # NoMethodError: undefined method `eval_in_spawned_process' for # from C:/ruby/lib/ruby/gems/1.8/gems/watir-1.6.6/lib/watir/element.rb:228:in `click_no_wait' from (irb):36 from C:/ruby/lib/ruby/site_ruby/1.8/rubygems/exceptions.rb:42 > click_no_wait does not work with frames > --------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Assignee: Jarmo Pertman > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- 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 Oct 14 07:18:19 2010 From: watirjira at gmail.com (problem_child (JIRA)) Date: Thu, 14 Oct 2010 06:18:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-459) click_no_wait does not work with frames In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <28892933.70.1287055099907.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19929#action_19929 ] problem_child commented on WTR-459: ----------------------------------- @Jarmo When is 1.6.7 scheduled for release? > click_no_wait does not work with frames > --------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Assignee: Jarmo Pertman > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- 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 Oct 14 08:22:20 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Thu, 14 Oct 2010 07:22:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-459) click_no_wait does not work with frames In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <5394510.73.1287058940511.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19930#action_19930 ] Jarmo Pertman commented on WTR-459: ----------------------------------- Where did you insert that "require 'watir/frame'" exactly in core.rb? Did you put it somewhere AFTER "require 'watir/page-container'"? >From the error message it seems you didn't. > click_no_wait does not work with frames > --------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Assignee: Jarmo Pertman > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- 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 Oct 14 08:41:20 2010 From: watirjira at gmail.com (problem_child (JIRA)) Date: Thu, 14 Oct 2010 07:41:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-459) click_no_wait does not work with frames In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <10396058.76.1287060080638.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19931#action_19931 ] problem_child commented on WTR-459: ----------------------------------- require 'watir/core_ext' require 'watir/logger' require 'watir/container' require 'watir/locator' require 'watir/page-container' require 'watir/frame' require 'watir/ie-class' require 'watir/element' require 'watir/element_collections' require 'watir/form' require 'watir/non_control_elements' require 'watir/input_elements' require 'watir/table' require 'watir/image' require 'watir/link' require 'watir/html_element' > click_no_wait does not work with frames > --------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Assignee: Jarmo Pertman > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- 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 Oct 14 10:05:20 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Thu, 14 Oct 2010 09:05:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-460) DataHandler CSV code doesn't close the file opened In-Reply-To: <11332569.54.1287030259941.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <29398059.79.1287065120462.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19932#action_19932 ] Charley Baker commented on WTR-460: ----------------------------------- Wow, I looked at this once years ago. I vote for removing it. There are better libraries as you mention - FasterCSV, Roo, etc. There are no tests for this and I doubt we'll find anyone to support it. > DataHandler CSV code doesn't close the file opened > -------------------------------------------------- > > Key: WTR-460 > URL: http://jira.openqa.org/browse/WTR-460 > Project: Watir > Issue Type: Bug > Components: Other > Affects Versions: 1.4, 1.4.1, Open QA Migration, 1.5.0/1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.6.0, 1.6.1, 1.6.2, 1.6.3, 1.6.5, 1.6.6 > Environment: All platforms > Reporter: Babitha Augusthy > Priority: Major > > The Datahandler.rb code for loading the data from an excel file or csv file, does not close the file if it is a CSV file. The excel instance stays in memory and retains a handle to the csv file opened, thereby rendering the file read-only until the excel instance is killed in Task Manager manually. -- 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 Oct 14 11:48:20 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Thu, 14 Oct 2010 10:48:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-459) click_no_wait does not work with frames In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <11726472.82.1287071300536.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19933#action_19933 ] Jarmo Pertman commented on WTR-459: ----------------------------------- Ok, i tried the full cycle and got it working like this: 1) open watir-1.6.6\unittests\html\frame_buttons.html in IE 2) modify frame.rb attach_command as written above 3) add require "watir/frame" as above 4) run this script: require "watir" b = Watir::Browser.attach :url, // $DEBUG = true b.frame("buttonFrame").button(:id => "b2").click_no_wait output should be something like that: S:\>ruby blah.rb Exception `WIN32OLERuntimeError' at C:/ruby_186p398/lib/ruby/gems/1.8/gems/watir -1.6.6/lib/watir/element.rb:207 - OLE error code:0 in HRESULT error code:0x80070057 The parameter is incorrect. #click_no_wait command: ruby -e "require 'rubygems';require 'C:/ruby_186p398/lib/ruby/gems/1.8/gems/wati r-1.6.6/lib/watir/core';Watir::Button.new(Watir::IE.attach(:hwnd, 2425434).frame (:name, 'buttonFrame'), :unique_number, 1).click!" and in the browser the button is clicked. The WIN32OLERuntimeError is normal. And all of this worked for me fine. You are doing something wrong or have some wrong setup there since eval_in_spawned_process doesn't exist anywhere in 1.6.6. Try to `gem uninstall watir -v 1.6.6` and `gem install watir` to be sure you're at clean slate :) If you get some errors, then please paste full stacktrace. Thanks. > click_no_wait does not work with frames > --------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Assignee: Jarmo Pertman > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- 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 jari.bakken at gmail.com Thu Oct 14 12:37:28 2010 From: jari.bakken at gmail.com (Jari Bakken) Date: Thu, 14 Oct 2010 18:37:28 +0200 Subject: [Wtr-development] AWTA workshop in Austin In-Reply-To: References: Message-ID: On Tue, Oct 12, 2010 at 3:41 AM, Bret Pettichord wrote: > Could you please let me know if this is something you might be able to > attend? > I would love to come. If it time-wise corresponds with some other US conference or developer event, I'll have an easier time getting the trip financed. From watirjira at gmail.com Thu Oct 14 13:03:20 2010 From: watirjira at gmail.com (Ethan (JIRA)) Date: Thu, 14 Oct 2010 12:03:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-460) DataHandler CSV code doesn't close the file opened In-Reply-To: <11332569.54.1287030259941.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <26418841.85.1287075800556.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19934#action_19934 ] Ethan commented on WTR-460: --------------------------- this should definitely be removed. > DataHandler CSV code doesn't close the file opened > -------------------------------------------------- > > Key: WTR-460 > URL: http://jira.openqa.org/browse/WTR-460 > Project: Watir > Issue Type: Bug > Components: Other > Affects Versions: 1.4, 1.4.1, Open QA Migration, 1.5.0/1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.6.0, 1.6.1, 1.6.2, 1.6.3, 1.6.5, 1.6.6 > Environment: All platforms > Reporter: Babitha Augusthy > Priority: Major > > The Datahandler.rb code for loading the data from an excel file or csv file, does not close the file if it is a CSV file. The excel instance stays in memory and retains a handle to the csv file opened, thereby rendering the file read-only until the excel instance is killed in Task Manager manually. -- 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 Thu Oct 14 13:04:18 2010 From: charley.baker at gmail.com (Charley Baker) Date: Thu, 14 Oct 2010 11:04:18 -0600 Subject: [Wtr-development] AWTA workshop in Austin In-Reply-To: References: Message-ID: I, for one, would love to meet you in person, and there are enough local ruby confs around the country, as well as other events, that I don't think that would be too hard. -c On Thu, Oct 14, 2010 at 10:37 AM, Jari Bakken wrote: > On Tue, Oct 12, 2010 at 3:41 AM, Bret Pettichord wrote: >> Could you please let me know if this is something you might be able to >> attend? >> > > I would love to come. If it time-wise corresponds with some other US > conference or developer event, I'll have an easier time getting the > trip financed. > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From watirjira at gmail.com Thu Oct 14 13:09:19 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Thu, 14 Oct 2010 12:09:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Resolved: (WTR-460) DataHandler CSV code doesn't close the file opened In-Reply-To: <11332569.54.1287030259941.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <25054843.88.1287076159992.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker resolved WTR-460. ------------------------------- Assignee: Charley Baker Resolution: Fixed Fix Version/s: Next Removed file. > DataHandler CSV code doesn't close the file opened > -------------------------------------------------- > > Key: WTR-460 > URL: http://jira.openqa.org/browse/WTR-460 > Project: Watir > Issue Type: Bug > Components: Other > Affects Versions: 1.4, 1.4.1, Open QA Migration, 1.5.0/1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.6.0, 1.6.1, 1.6.2, 1.6.3, 1.6.5, 1.6.6 > Environment: All platforms > Reporter: Babitha Augusthy > Assignee: Charley Baker > Priority: Major > Fix For: Next > > > The Datahandler.rb code for loading the data from an excel file or csv file, does not close the file if it is a CSV file. The excel instance stays in memory and retains a handle to the csv file opened, thereby rendering the file read-only until the excel instance is killed in Task Manager manually. -- 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 abaird at bairdsnet.net Thu Oct 14 22:01:08 2010 From: abaird at bairdsnet.net (Alan Baird) Date: Thu, 14 Oct 2010 21:01:08 -0500 Subject: [Wtr-development] AWTA workshop in Austin In-Reply-To: References: Message-ID: Bret - After talking w/ my management, they told me that they could send me "probably". I think I would come even if I had to pay my way. Alan Baird -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Thu Oct 14 22:26:44 2010 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 14 Oct 2010 21:26:44 -0500 Subject: [Wtr-development] AWTA workshop in Austin In-Reply-To: References: Message-ID: Maybe the Ruby conference in Columbus? On Thu, Oct 14, 2010 at 12:04 PM, Charley Baker wrote: > I, for one, would love to meet you in person, and there are enough > local ruby confs around the country, as well as other events, that I > don't think that would be too hard. > > -c > > On Thu, Oct 14, 2010 at 10:37 AM, Jari Bakken > wrote: > > On Tue, Oct 12, 2010 at 3:41 AM, Bret Pettichord > wrote: > >> Could you please let me know if this is something you might be able to > >> attend? > >> > > > > I would love to come. If it time-wise corresponds with some other US > > conference or developer event, I'll have an easier time getting the > > trip financed. > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From charley.baker at gmail.com Thu Oct 14 22:30:44 2010 From: charley.baker at gmail.com (Charley Baker) Date: Thu, 14 Oct 2010 20:30:44 -0600 Subject: [Wtr-development] AWTA workshop in Austin In-Reply-To: References: Message-ID: I got unlucky and paid my way for multiple confs. Next job, that won't happen. :) On Thu, Oct 14, 2010 at 8:01 PM, Alan Baird wrote: > Bret - > After talking w/ my management, they told me that they could send me > "probably". ?I think I would come even if I had to pay my way. > Alan Baird > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From charley.baker at gmail.com Thu Oct 14 23:01:37 2010 From: charley.baker at gmail.com (Charley Baker) Date: Thu, 14 Oct 2010 21:01:37 -0600 Subject: [Wtr-development] AWTA workshop in Austin In-Reply-To: References: Message-ID: Jrubycon? That just happened and won't happen again till next year same time frame. There are a lot of confs and a lot people I can hook you up with if you want to follow Corey Haines example and spend a week here or there at various craftsmen's shops. Charley Baker Lead Developer, Watir, http://watir.com On Thu, Oct 14, 2010 at 8:26 PM, Bret Pettichord wrote: > Maybe the Ruby conference in Columbus? > > On Thu, Oct 14, 2010 at 12:04 PM, Charley Baker > wrote: >> >> I, for one, would love to meet you in person, and there are enough >> local ruby confs around the country, as well as other events, that I >> don't think that would be too hard. >> >> -c >> >> On Thu, Oct 14, 2010 at 10:37 AM, Jari Bakken >> wrote: >> > On Tue, Oct 12, 2010 at 3:41 AM, Bret Pettichord >> > wrote: >> >> Could you please let me know if this is something you might be able to >> >> attend? >> >> >> > >> > I would love to come. If it time-wise corresponds with some other US >> > conference or developer event, I'll have an easier time getting the >> > trip financed. >> > _______________________________________________ >> > Wtr-development mailing list >> > Wtr-development at rubyforge.org >> > http://rubyforge.org/mailman/listinfo/wtr-development >> > >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From watirjira at gmail.com Fri Oct 15 03:24:20 2010 From: watirjira at gmail.com (Babitha Augusthy (JIRA)) Date: Fri, 15 Oct 2010 02:24:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-460) DataHandler CSV code doesn't close the file opened In-Reply-To: <11332569.54.1287030259941.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <17270164.92.1287127460716.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19936#action_19936 ] Babitha Augusthy commented on WTR-460: -------------------------------------- But, please do know people like me have no prior experience with ruby/other ruby gems, and would like to have an integrated solution than installing many gems, and learning it. Also, lesser the number of gems to be installed, lesser the pain of getting a new tester system ready. > DataHandler CSV code doesn't close the file opened > -------------------------------------------------- > > Key: WTR-460 > URL: http://jira.openqa.org/browse/WTR-460 > Project: Watir > Issue Type: Bug > Components: Other > Affects Versions: 1.4, 1.4.1, Open QA Migration, 1.5.0/1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.6.0, 1.6.1, 1.6.2, 1.6.3, 1.6.5, 1.6.6 > Environment: All platforms > Reporter: Babitha Augusthy > Assignee: Charley Baker > Priority: Major > Fix For: Next > > > The Datahandler.rb code for loading the data from an excel file or csv file, does not close the file if it is a CSV file. The excel instance stays in memory and retains a handle to the csv file opened, thereby rendering the file read-only until the excel instance is killed in Task Manager manually. -- 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 Oct 15 06:05:21 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Fri, 15 Oct 2010 05:05:21 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-460) DataHandler CSV code doesn't close the file opened In-Reply-To: <11332569.54.1287030259941.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <27001503.95.1287137121179.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19937#action_19937 ] Zeljko commented on WTR-460: ---------------------------- You will have to learn how to use many tools. Watir is tool for driving browsers. If you need to access files, use Ruby or some Ruby gem. > DataHandler CSV code doesn't close the file opened > -------------------------------------------------- > > Key: WTR-460 > URL: http://jira.openqa.org/browse/WTR-460 > Project: Watir > Issue Type: Bug > Components: Other > Affects Versions: 1.4, 1.4.1, Open QA Migration, 1.5.0/1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.6.0, 1.6.1, 1.6.2, 1.6.3, 1.6.5, 1.6.6 > Environment: All platforms > Reporter: Babitha Augusthy > Assignee: Charley Baker > Priority: Major > Fix For: Next > > > The Datahandler.rb code for loading the data from an excel file or csv file, does not close the file if it is a CSV file. The excel instance stays in memory and retains a handle to the csv file opened, thereby rendering the file read-only until the excel instance is killed in Task Manager manually. -- 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 Oct 15 06:18:20 2010 From: watirjira at gmail.com (problem_child (JIRA)) Date: Fri, 15 Oct 2010 05:18:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-459) click_no_wait does not work with frames In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <9454979.98.1287137900417.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19938#action_19938 ] problem_child commented on WTR-459: ----------------------------------- Yep. That did it. Thank you! > click_no_wait does not work with frames > --------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Assignee: Jarmo Pertman > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- 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 Oct 15 06:42:20 2010 From: watirjira at gmail.com (problem_child (JIRA)) Date: Fri, 15 Oct 2010 05:42:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-459) click_no_wait does not work with frames In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <23006478.101.1287139340329.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19939#action_19939 ] problem_child commented on WTR-459: ----------------------------------- To add, tested in: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6, Windows XP > click_no_wait does not work with frames > --------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Assignee: Jarmo Pertman > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- 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 Oct 15 11:46:20 2010 From: watirjira at gmail.com (Ethan (JIRA)) Date: Fri, 15 Oct 2010 10:46:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-460) DataHandler CSV code doesn't close the file opened In-Reply-To: <11332569.54.1287030259941.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <3144398.108.1287157580732.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19940#action_19940 ] Ethan commented on WTR-460: --------------------------- Installing other gems shouldn't be painful. Learning how to use more stuff can be time-consuming, certainly, but no more so with any other gem than with the datahandler thing that was in watir. Probably less so; I'm sure other libraries have better APIs and better documentation than this thing. > DataHandler CSV code doesn't close the file opened > -------------------------------------------------- > > Key: WTR-460 > URL: http://jira.openqa.org/browse/WTR-460 > Project: Watir > Issue Type: Bug > Components: Other > Affects Versions: 1.4, 1.4.1, Open QA Migration, 1.5.0/1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.6.0, 1.6.1, 1.6.2, 1.6.3, 1.6.5, 1.6.6 > Environment: All platforms > Reporter: Babitha Augusthy > Assignee: Charley Baker > Priority: Major > Fix For: Next > > > The Datahandler.rb code for loading the data from an excel file or csv file, does not close the file if it is a CSV file. The excel instance stays in memory and retains a handle to the csv file opened, thereby rendering the file read-only until the excel instance is killed in Task Manager manually. -- 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 Oct 15 19:23:20 2010 From: watirjira at gmail.com (Alister Scott (JIRA)) Date: Fri, 15 Oct 2010 18:23:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-459) click_no_wait does not work with frames In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <23773581.111.1287185000598.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alister Scott closed WTR-459. ----------------------------- Resolution: Not a problem Closed as per comment. > click_no_wait does not work with frames > --------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Assignee: Jarmo Pertman > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 16 08:07:20 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Sat, 16 Oct 2010 07:07:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Reopened: (WTR-459) click_no_wait does not work with frames In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <7533910.115.1287230840545.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarmo Pertman reopened WTR-459: ------------------------------- > click_no_wait does not work with frames > --------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Assignee: Jarmo Pertman > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 16 08:09:20 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Sat, 16 Oct 2010 07:09:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-459) click_no_wait does not work with frames In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <27950015.121.1287230960136.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarmo Pertman closed WTR-459. ----------------------------- > click_no_wait does not work with frames > --------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Assignee: Jarmo Pertman > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Sat Oct 16 08:09:20 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Sat, 16 Oct 2010 07:09:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Resolved: (WTR-459) click_no_wait does not work with frames In-Reply-To: <22348296.24.1286971279825.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <27661120.118.1287230960030.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarmo Pertman resolved WTR-459. ------------------------------- Resolution: Fixed Reopened to close it with "Fixed" status, because #click_no_wait with frames doesn't work in 1.6.6 and will be fixed in 1.6.7. > click_no_wait does not work with frames > --------------------------------------- > > Key: WTR-459 > URL: http://jira.openqa.org/browse/WTR-459 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.6 > Environment: ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > Reporter: problem_child > Assignee: Jarmo Pertman > Priority: Blocker > > click_no_wait is not working in ruby 1.8.6 (2007-09-24 patchlevel 111), Watir 1.6.6 > $frame.button(:name, "button1").click_no_wait > =>nil > If I use $frame.button(:name, "button1").click it works so it is finding the object. > But using click_no_wait results in nill using IRB. > An error is not reported otherwise. -- 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 Sun Oct 17 08:11:25 2010 From: jarmo.p at gmail.com (Jarmo) Date: Sun, 17 Oct 2010 15:11:25 +0300 Subject: [Wtr-development] automatic waiting? Message-ID: Hi! I have been thinking about making Watir wait automatically before throwing Exceptions. I don't know how you are dealing currently with the pages with Ajax/JavaScript usage, but i find myself quite often using some wait_until or similar solution. It has happened quite often that i create a test and it's ok, but then at some CI machine it fails intermittently and i end up inserting some wait_until in between assertions or anything else. The problem is that sometimes JavaScript is used to redirect/refresh or change the DOM. All these things are not blocking #wait if i'm not mistaken. If JavaScript redirect/refresh is used then there is a possibility that there will be some random errors because Watir loads the page and thinks everything is ready and doesn't block in #wait anymore, but right then the redirect is issued and something might break or might not break - depending of the timing. So, i was thinking - why not add some 5-10 seconds wait_until into somewhere to not throw Exception right away if the object doesn't exist? Or if the object isn't visible? So, if the test is failing then it waits maximum of 5-10 seconds befor actually failing and if test is ok, then it doesn't add any extra waiting time. And there's no need to put all those wait_until's into every here and there. If there's some longer Ajax call or anything then you can still use a wait_until in your test with longer timeout. So it shouldn't break any backwards compatibility either. What do you guys think? Is there any reason why not to implement something like that? Jarmo From alister.scott at gmail.com Sun Oct 17 08:21:02 2010 From: alister.scott at gmail.com (Alister Scott) Date: Sun, 17 Oct 2010 22:21:02 +1000 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: <-3344143083728800104@unknownmsgid> I'd personally be all for it. I am currently having the same problem you've described testing an AJAX heavy app, and I have a lot of waits of up to 50 iterations of 0.2 seconds sleep (max 10 seconds wait). Something like you described would make my job a lot easier. Cheers, Alister Scott Brisbane, Australia Watir Wiki Master: http://watir.com Blog: http://watirmelon.com Google: http://www.google.com/profiles/alister.scott LinkedIn: http://www.linkedin.com/in/alisterscott On 17/10/2010, at 10:15 PM, Jarmo wrote: > Hi! > > I have been thinking about making Watir wait automatically before > throwing Exceptions. I don't know how you are dealing currently with > the pages with Ajax/JavaScript usage, but i find myself quite often > using some wait_until or similar solution. It has happened quite often > that i create a test and it's ok, but then at some CI machine it fails > intermittently and i end up inserting some wait_until in between > assertions or anything else. > > The problem is that sometimes JavaScript is used to redirect/refresh > or change the DOM. All these things are not blocking #wait if i'm not > mistaken. If JavaScript redirect/refresh is used then there is a > possibility that there will be some random errors because Watir loads > the page and thinks everything is ready and doesn't block in #wait > anymore, but right then the redirect is issued and something might > break or might not break - depending of the timing. > > So, i was thinking - why not add some 5-10 seconds wait_until into > somewhere to not throw Exception right away if the object doesn't > exist? Or if the object isn't visible? So, if the test is failing then > it waits maximum of 5-10 seconds befor actually failing and if test is > ok, then it doesn't add any extra waiting time. And there's no need to > put all those wait_until's into every here and there. If there's some > longer Ajax call or anything then you can still use a wait_until in > your test with longer timeout. So it shouldn't break any backwards > compatibility either. > > What do you guys think? Is there any reason why not to implement > something like that? > > Jarmo > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development From brettcsykes at gmail.com Sun Oct 17 18:33:52 2010 From: brettcsykes at gmail.com (brett sykes) Date: Sun, 17 Oct 2010 18:33:52 -0400 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: I'm a fan of this wait_until approach being built in as well. I've had this problem too where generally assert_exists randomly throws when I'm trying to interact with an element after I've checked to make sure that the page is definitely loaded and all of the XHRs have completed loading etc. I monkey patched my version to keep trying to locate the element without throwing for a period of time. So, I think the approach you are describing makes a lot of sense. --brett On Sun, Oct 17, 2010 at 8:11 AM, Jarmo wrote: > Hi! > > I have been thinking about making Watir wait automatically before > throwing Exceptions. I don't know how you are dealing currently with > the pages with Ajax/JavaScript usage, but i find myself quite often > using some wait_until or similar solution. It has happened quite often > that i create a test and it's ok, but then at some CI machine it fails > intermittently and i end up inserting some wait_until in between > assertions or anything else. > > The problem is that sometimes JavaScript is used to redirect/refresh > or change the DOM. All these things are not blocking #wait if i'm not > mistaken. If JavaScript redirect/refresh is used then there is a > possibility that there will be some random errors because Watir loads > the page and thinks everything is ready and doesn't block in #wait > anymore, but right then the redirect is issued and something might > break or might not break - depending of the timing. > > So, i was thinking - why not add some 5-10 seconds wait_until into > somewhere to not throw Exception right away if the object doesn't > exist? Or if the object isn't visible? So, if the test is failing then > it waits maximum of 5-10 seconds befor actually failing and if test is > ok, then it doesn't add any extra waiting time. And there's no need to > put all those wait_until's into every here and there. If there's some > longer Ajax call or anything then you can still use a wait_until in > your test with longer timeout. So it shouldn't break any backwards > compatibility either. > > What do you guys think? Is there any reason why not to implement > something like that? > > Jarmo > _______________________________________________ > 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 notethan at gmail.com Sun Oct 17 21:10:24 2010 From: notethan at gmail.com (Ethan) Date: Sun, 17 Oct 2010 21:10:24 -0400 Subject: [Wtr-development] automatic waiting? In-Reply-To: <-3344143083728800104@unknownmsgid> References: <-3344143083728800104@unknownmsgid> Message-ID: I've also been thinking about implementing that too. The downside is slowing things down significantly when something goes wrong, or when debugging - sitting around waiting for error messages to finally show up is annoying. I think it'd be good, provided two things. 1. it's configurable, so users can turn it off or adjust the amount of time it waits. 2. the default is short, not more than one second. waiting 5 seconds in irb whenever I try to access a nonexistent element would annoy me a lot. 1 second is plenty of time for javascript that doesn't interact with a server. it's not enough for AJAX stuff, but the user can set this to longer as needed, or use an explicit wait_until. I also think that this should happen in #initialize, and not in #assert_exists - it should only happen once at the beginning, not whenever you try to do anything with an element. that conflicts with watir's lazy locating, though. I think that should change too, personally - just seeing 'located=false' when inspecting an element is not useful. (vapir tries to locate in #initialize and shows 'exists?=false' on elements that don't exist, doesn't ever just say "I don't know, I haven't tried to find it yet"). -Ethan On Sun, Oct 17, 2010 at 08:21, Alister Scott wrote: > I'd personally be all for it. > I am currently having the same problem you've described testing an > AJAX heavy app, and I have a lot of waits of up to 50 iterations of > 0.2 seconds sleep (max 10 seconds wait). > > Something like you described would make my job a lot easier. > > Cheers, > > Alister Scott > Brisbane, Australia > Watir Wiki Master: http://watir.com > Blog: http://watirmelon.com > Google: http://www.google.com/profiles/alister.scott > LinkedIn: http://www.linkedin.com/in/alisterscott > > On 17/10/2010, at 10:15 PM, Jarmo wrote: > > > Hi! > > > > I have been thinking about making Watir wait automatically before > > throwing Exceptions. I don't know how you are dealing currently with > > the pages with Ajax/JavaScript usage, but i find myself quite often > > using some wait_until or similar solution. It has happened quite often > > that i create a test and it's ok, but then at some CI machine it fails > > intermittently and i end up inserting some wait_until in between > > assertions or anything else. > > > > The problem is that sometimes JavaScript is used to redirect/refresh > > or change the DOM. All these things are not blocking #wait if i'm not > > mistaken. If JavaScript redirect/refresh is used then there is a > > possibility that there will be some random errors because Watir loads > > the page and thinks everything is ready and doesn't block in #wait > > anymore, but right then the redirect is issued and something might > > break or might not break - depending of the timing. > > > > So, i was thinking - why not add some 5-10 seconds wait_until into > > somewhere to not throw Exception right away if the object doesn't > > exist? Or if the object isn't visible? So, if the test is failing then > > it waits maximum of 5-10 seconds befor actually failing and if test is > > ok, then it doesn't add any extra waiting time. And there's no need to > > put all those wait_until's into every here and there. If there's some > > longer Ajax call or anything then you can still use a wait_until in > > your test with longer timeout. So it shouldn't break any backwards > > compatibility either. > > > > What do you guys think? Is there any reason why not to implement > > something like that? > > > > Jarmo > > _______________________________________________ > > 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 Sun Oct 17 21:24:30 2010 From: jari.bakken at gmail.com (Jari Bakken) Date: Mon, 18 Oct 2010 03:24:30 +0200 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: On Sun, Oct 17, 2010 at 2:11 PM, Jarmo wrote: > > What do you guys think? Is there any reason why not to implement > something like that? > WebDriver got this feature recently, configurable as: driver.manage.timeouts.implicit_wait = 1.5 # seconds The default is not to wait at all. Capybara has its own implicit waiting turned on by default (not sure how long). Personally I'm a bigger fan of explicitly waiting where it's needed, but I can see that this is a useful feature. From bret at pettichord.com Sun Oct 17 21:33:12 2010 From: bret at pettichord.com (Bret Pettichord) Date: Sun, 17 Oct 2010 20:33:12 -0500 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: Jarmo, I'd like to see a more detailed proposal for this. Also I remember someone -- I think it was Jari -- showing me some code recently to implement the functionality you discuss here by adding an additional method. browser.button(:value, 'foo').waiting_for.click I don't remember the exact name, but it did an implicit wait for the element before calling the chained method ("click" in this case). If someone could share the code for that I think it would help this discussion. Bret On Sun, Oct 17, 2010 at 7:11 AM, Jarmo wrote: > Hi! > > I have been thinking about making Watir wait automatically before > throwing Exceptions. I don't know how you are dealing currently with > the pages with Ajax/JavaScript usage, but i find myself quite often > using some wait_until or similar solution. It has happened quite often > that i create a test and it's ok, but then at some CI machine it fails > intermittently and i end up inserting some wait_until in between > assertions or anything else. > > The problem is that sometimes JavaScript is used to redirect/refresh > or change the DOM. All these things are not blocking #wait if i'm not > mistaken. If JavaScript redirect/refresh is used then there is a > possibility that there will be some random errors because Watir loads > the page and thinks everything is ready and doesn't block in #wait > anymore, but right then the redirect is issued and something might > break or might not break - depending of the timing. > > So, i was thinking - why not add some 5-10 seconds wait_until into > somewhere to not throw Exception right away if the object doesn't > exist? Or if the object isn't visible? So, if the test is failing then > it waits maximum of 5-10 seconds befor actually failing and if test is > ok, then it doesn't add any extra waiting time. And there's no need to > put all those wait_until's into every here and there. If there's some > longer Ajax call or anything then you can still use a wait_until in > your test with longer timeout. So it shouldn't break any backwards > compatibility either. > > What do you guys think? Is there any reason why not to implement > something like that? > > Jarmo > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Sun Oct 17 21:35:01 2010 From: bret at pettichord.com (Bret Pettichord) Date: Sun, 17 Oct 2010 20:35:01 -0500 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: Yes, it could be dangerous feature. Many of the commercial tools added something like this without careful thought and as a result completely killed the performance of scripts. Several years ago we had several people tell us that Watir was 20 times faster than their Silk tests. I believe it was because Silk added some implicit, ubiquitous waiting without much care. Bret On Sun, Oct 17, 2010 at 8:24 PM, Jari Bakken wrote: > On Sun, Oct 17, 2010 at 2:11 PM, Jarmo wrote: > > > > What do you guys think? Is there any reason why not to implement > > something like that? > > > > WebDriver got this feature recently, configurable as: > > driver.manage.timeouts.implicit_wait = 1.5 # seconds > > The default is not to wait at all. Capybara has its own implicit > waiting turned on by default (not sure how long). > Personally I'm a bigger fan of explicitly waiting where it's needed, > but I can see that this is a useful feature. > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Mon Oct 18 13:10:26 2010 From: jarmo.p at gmail.com (Jarmo) Date: Mon, 18 Oct 2010 20:10:26 +0300 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: Jari: does that implicit wait in WD mean that 1.5 seconds is waited everytime before throwing out an Exception? This is not what i'd want. After giving some more thought about it then i cannot see any perfect solution to it and i'm starting to believe that there are none :( To give you a better picture of the current situation then this is what i have to do currently in my tests for example: button.click # some javascript work wait_until {div.exists?) button.click # some javascript work wait_until {div.visible?} button.click # some javascript work wait_until {div.text == "expected text"} button.click # some javascript work wait_until {not div.exists?} And i would like to do these examples like this with RSpec: button.click # some javascript work div.should exist button.click # some javascript work div.should be_visible button.click # some javascript work div.text.should == "expected text" button.click # some javascript work div.should_not exist In other words i wouldn't want to use any wait_until's or similar methods explicitly. And considering the examples above it seems to be impossible to achieve without changing something very drastically or changing Watir AND RSpec together. If you think about it then manual tester also waits something to happen, implicitly, but (s)he always (well, almost always) knows what to wait. (S)He also knows if there should something to disappear instead and waits for it. So if we could build some mind-reading AI then Watir would rock. Ethan: what would you do in #initialize? As you can see from the examples above then you cannot just wait until element exists - what if i want to wait until it doesn't exist? That's the problem. Also, i wouldn't want it to be limited to only "exists?" as written above. Bret: using Jari's #while_present doesn't help either because it is just in a matter of different syntax. In short, unless someone comes up with some fantastic idea, then this thing will be on hold. I'd like to see what Ethan (or anyone else) comes up with. Jarmo On Mon, Oct 18, 2010 at 4:35 AM, Bret Pettichord wrote: > Yes, it could be dangerous feature. Many of the commercial tools added > something like this without careful thought and as a result completely > killed the performance of scripts. > > Several years ago we had several people tell us that Watir was 20 times > faster than their Silk tests. I believe it was because Silk added some > implicit, ubiquitous waiting without much care. > > Bret > > On Sun, Oct 17, 2010 at 8:24 PM, Jari Bakken wrote: >> >> On Sun, Oct 17, 2010 at 2:11 PM, Jarmo wrote: >> > >> > What do you guys think? Is there any reason why not to implement >> > something like that? >> > >> >> WebDriver got this feature recently, configurable as: >> >> ? driver.manage.timeouts.implicit_wait = 1.5 # seconds >> >> The default is not to wait at all. Capybara has its own implicit >> waiting turned on by default (not sure how long). >> Personally I'm a bigger fan of explicitly waiting where it's needed, >> but I can see that this is a useful feature. >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From brettcsykes at gmail.com Mon Oct 18 17:03:30 2010 From: brettcsykes at gmail.com (brett sykes) Date: Mon, 18 Oct 2010 17:03:30 -0400 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: For this type of thing we wrapped the WATIR functions that cause AJAX events to fire in our app - set, click, clear, etc with a method that looks for a standard empty div we toss on the page when we are processing these events. This works well enough as things can get added or removed to the DOM and your code doesn't really care what they are until you do an assertion. A much better approach would have been for us to use the add_checker functionality in WATIR to do the same thing. You're definitely already aware of this way of doing things but I thought I would type it out anyway. I don't know currently of any fancy way for WATIR to do this automatically. Initially I thought you were talking about something else that I was seeing where there appears to be some sort of timing issue where the page reports as being loaded but assert_exists seems to (very very rarely) randomly throw. I need to track this down a little more but I found adding a little bit of polling time and retrying the locate method inside assert_exists seemed to make that problem disappear. I will try to figure it out a little more and get a reproducible test. --brett On Mon, Oct 18, 2010 at 1:10 PM, Jarmo wrote: > Jari: does that implicit wait in WD mean that 1.5 seconds is waited > everytime before throwing out an Exception? This is not what i'd want. > > After giving some more thought about it then i cannot see any perfect > solution to it and i'm starting to believe that there are none :( > > To give you a better picture of the current situation then this is > what i have to do currently in my tests for example: > button.click > # some javascript work > wait_until {div.exists?) > > button.click > # some javascript work > wait_until {div.visible?} > > button.click > # some javascript work > wait_until {div.text == "expected text"} > > button.click > # some javascript work > wait_until {not div.exists?} > > And i would like to do these examples like this with RSpec: > button.click > # some javascript work > div.should exist > > button.click > # some javascript work > div.should be_visible > > button.click > # some javascript work > div.text.should == "expected text" > > button.click > # some javascript work > div.should_not exist > > In other words i wouldn't want to use any wait_until's or similar > methods explicitly. And considering the examples above it seems to be > impossible to achieve without changing something very drastically or > changing Watir AND RSpec together. > > If you think about it then manual tester also waits something to > happen, implicitly, but (s)he always (well, almost always) knows what > to wait. (S)He also knows if there should something to disappear > instead and waits for it. So if we could build some mind-reading AI > then Watir would rock. > > Ethan: what would you do in #initialize? As you can see from the > examples above then you cannot just wait until element exists - what > if i want to wait until it doesn't exist? That's the problem. Also, i > wouldn't want it to be limited to only "exists?" as written above. > > Bret: using Jari's #while_present doesn't help either because it is > just in a matter of different syntax. > > In short, unless someone comes up with some fantastic idea, then this > thing will be on hold. > > I'd like to see what Ethan (or anyone else) comes up with. > > Jarmo > > On Mon, Oct 18, 2010 at 4:35 AM, Bret Pettichord > wrote: > > Yes, it could be dangerous feature. Many of the commercial tools added > > something like this without careful thought and as a result completely > > killed the performance of scripts. > > > > Several years ago we had several people tell us that Watir was 20 times > > faster than their Silk tests. I believe it was because Silk added some > > implicit, ubiquitous waiting without much care. > > > > Bret > > > > On Sun, Oct 17, 2010 at 8:24 PM, Jari Bakken > wrote: > >> > >> On Sun, Oct 17, 2010 at 2:11 PM, Jarmo wrote: > >> > > >> > What do you guys think? Is there any reason why not to implement > >> > something like that? > >> > > >> > >> WebDriver got this feature recently, configurable as: > >> > >> driver.manage.timeouts.implicit_wait = 1.5 # seconds > >> > >> The default is not to wait at all. Capybara has its own implicit > >> waiting turned on by default (not sure how long). > >> Personally I'm a bigger fan of explicitly waiting where it's needed, > >> but I can see that this is a useful feature. > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > > > > > -- > > Bret Pettichord > > Lead Developer, Watir, www.watir.com > > > > Blog, www.io.com/~wazmo/blog > > Twitter, www.twitter.com/bpettichord > > > > > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > 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 paul.rogers at shaw.ca Mon Oct 18 22:35:57 2010 From: paul.rogers at shaw.ca (Paul Rogers) Date: Mon, 18 Oct 2010 20:35:57 -0600 Subject: [Wtr-development] firewatir.com Message-ID: I own this domain and I think it points to watir.com. Its up for renewal, shall I renew it? Thanks Paul From zeljko.filipin at wa-research.ch Tue Oct 19 03:24:19 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 19 Oct 2010 09:24:19 +0200 Subject: [Wtr-development] firewatir.com In-Reply-To: References: Message-ID: On Tue, Oct 19, 2010 at 4:35 AM, Paul Rogers wrote: > I own this domain and I think it points to watir.com. Its up for > renewal, shall I renew it? I do not think we need firewatir.com domain. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Tue Oct 19 05:00:38 2010 From: jarmo.p at gmail.com (Jarmo) Date: Tue, 19 Oct 2010 12:00:38 +0300 Subject: [Wtr-development] firewatir.com In-Reply-To: References: Message-ID: Check out from Google Analytics how many users are coming from firewatir.com or from wordpress statistics or whenever. Jarmo On Tue, Oct 19, 2010 at 10:24 AM, ?eljko Filipin wrote: > On Tue, Oct 19, 2010 at 4:35 AM, Paul Rogers wrote: >> I own this domain and I think it points to watir.com. Its up for >> renewal, shall I renew it? > > I do not think we need firewatir.com domain. > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From zeljko.filipin at wa-research.ch Tue Oct 19 05:10:40 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 19 Oct 2010 11:10:40 +0200 Subject: [Wtr-development] firewatir.com In-Reply-To: References: Message-ID: On Tue, Oct 19, 2010 at 11:00 AM, Jarmo wrote: > Check out from Google Analytics how many users are coming from > firewatir.com or from wordpress statistics or whenever. Please let me know if you would like access to watir.com site, so you can take a look. This is what I have found. Wordpress.com stats (Referrers for all days ending 2010-10-19 Summarized) does not mention firewatir.com (dashboard > site stats > referrers > view all > all time): ReferrerViews openqa.org/6,528 opensourcetesting.org/functional.php5,397 en.wikipedia.org/wiki/Watir3,347 wiki.openqa.org/display/WTR/Quick Sta? 2,489 watin.sourceforge.net/1,836 wiki.openqa.org/display/WTR/Project H? 1,736 wiki.openqa.org/display/WTR/FAQ1,474 code.google.com/p/firewatir/1,394 rads.stackoverflow.com/ossads/220x2501,167 seleniumhq.org/clearspace.html 1,024 webresourcesdepot.com/15-free-functio? 907 softwareqatest.com/qatweb1.html819 cukes.info/801 celerity.rubyforge.org/703 layeredthoughts.com/automation/how-to? 637 wiki.openqa.org/display/WTR/Developme? 612 httpwatch.com/rubywatir/586 stackoverflow.com/questions/426190/se? 541 stackoverflow.com/questions/802225/me? 518 wiki.openqa.org/display/WTR/FireWatir510 wtr.rubyforge.org/rdoc/505 wtr.rubyforge.org/rdoc/1.6.5/files/RE? 474 wiki.github.com/aslakhellesoy/cucumbe? 472 wiki.github.com/aslakhellesoy/cucumbe? 466 wiki.github.com/brynary/webrat/437 blog.dynatrace.com/2009/11/04/5-steps? 431 martinfowler.com/articles/continuousI? 424 rubyforge.org/projects/wtr/416 sixapart.jp/techtalk/2008/06/watir.ht? 360 google.co.in/348 moongift.jp/2007/09/watir/336 watij.com/334 phpspot.org/blog/archives/2009/05/web? 317 www11.atwiki.jp/autotest/pages/14.htm? 286 watin.sourceforge.net/index.html285 stackoverflow.com/questions/125177/wh? 284 google.com/269 softwaretestinghelp.com/regression-te? 255 groups.google.com/group/watir-general236 boss.bekk.no/display/BOSS/CubicTest -? 234 ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Tue Oct 19 05:31:25 2010 From: jarmo.p at gmail.com (Jarmo) Date: Tue, 19 Oct 2010 12:31:25 +0300 Subject: [Wtr-development] firewatir.com In-Reply-To: References: Message-ID: strange that it doesn't mention it at all :P On Tue, Oct 19, 2010 at 12:10 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Tue, Oct 19, 2010 at 11:00 AM, Jarmo wrote: > > Check out from Google Analytics how many users are coming from > > firewatir.com or from wordpress statistics or whenever. > > Please let me know if you would like access to watir.com site, so you can > take a look. This is what I have found. > > Wordpress.com stats (Referrers for all days ending 2010-10-19 Summarized) > does not mention firewatir.com (dashboard > site stats > referrers > view > all > all time): > > ReferrerViews openqa.org/6,528 opensourcetesting.org/functional.php5,397 > en.wikipedia.org/wiki/Watir3,347 wiki.openqa.org/display/WTR/Quick Sta? > 2,489 watin.sourceforge.net/1,836 wiki.openqa.org/display/WTR/Project H? > 1,736 wiki.openqa.org/display/WTR/FAQ1,474 code.google.com/p/firewatir/ > 1,394 rads.stackoverflow.com/ossads/220x2501,167 > seleniumhq.org/clearspace.html1,024 webresourcesdepot.com/15-free-functio? > 907 softwareqatest.com/qatweb1.html819 cukes.info/801 > celerity.rubyforge.org/703 layeredthoughts.com/automation/how-to?637 > wiki.openqa.org/display/WTR/Developme? > 612 httpwatch.com/rubywatir/586 stackoverflow.com/questions/426190/se? > 541 stackoverflow.com/questions/802225/me? > 518 wiki.openqa.org/display/WTR/FireWatir510 wtr.rubyforge.org/rdoc/505 > wtr.rubyforge.org/rdoc/1.6.5/files/RE? > 474 wiki.github.com/aslakhellesoy/cucumbe? > 472 wiki.github.com/aslakhellesoy/cucumbe? > 466 wiki.github.com/brynary/webrat/437 > blog.dynatrace.com/2009/11/04/5-steps?431 > martinfowler.com/articles/continuousI? > 424 rubyforge.org/projects/wtr/416 sixapart.jp/techtalk/2008/06/watir.ht? > 360 google.co.in/348 moongift.jp/2007/09/watir/336 watij.com/334 > phpspot.org/blog/archives/2009/05/web? > 317 www11.atwiki.jp/autotest/pages/14.htm? > 286 watin.sourceforge.net/index.html285 > stackoverflow.com/questions/125177/wh? > 284 google.com/269 softwaretestinghelp.com/regression-te? > 255 groups.google.com/group/watir-general236 boss.bekk.no/display/BOSS/CubicTest > -? 234 > > ?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 Tue Oct 19 06:05:04 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 19 Oct 2010 12:05:04 +0200 Subject: [Wtr-development] firewatir.com In-Reply-To: References: Message-ID: On Tue, Oct 19, 2010 at 11:31 AM, Jarmo wrote: > strange that it doesn't mention it at all :P I did not know until today that the domain exists. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Tue Oct 19 06:15:21 2010 From: alister.scott at gmail.com (Alister Scott) Date: Tue, 19 Oct 2010 20:15:21 +1000 Subject: [Wtr-development] firewatir.com In-Reply-To: References: Message-ID: <-7320976697169308634@unknownmsgid> That list is referrers, not redirects, so watir.com and firewatir.com won't show. Alister Scott Brisbane, Australia Watir Wiki Master: http://watir.com Blog: http://watirmelon.com Google: http://www.google.com/profiles/alister.scott LinkedIn: http://www.linkedin.com/in/alisterscott On 19/10/2010, at 8:12 PM, "?eljko Filipin" wrote: On Tue, Oct 19, 2010 at 11:31 AM, Jarmo wrote: > strange that it doesn't mention it at all :P I did not know until today that the domain exists. ?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 Tue Oct 19 06:59:08 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 19 Oct 2010 12:59:08 +0200 Subject: [Wtr-development] firewatir.com In-Reply-To: <-7320976697169308634@unknownmsgid> References: <-7320976697169308634@unknownmsgid> Message-ID: On Tue, Oct 19, 2010 at 12:15 PM, Alister Scott wrote: > That list is referrers, not redirects, so watir.com and firewatir.comwon't show. Can I see redirects somewhere? ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From angrez at gmail.com Tue Oct 19 10:23:16 2010 From: angrez at gmail.com (Angrez Singh) Date: Tue, 19 Oct 2010 19:53:16 +0530 Subject: [Wtr-development] firewatir.com In-Reply-To: References: <-7320976697169308634@unknownmsgid> Message-ID: I didn't know that firewatir.com actually exists :) - Angrez On Tue, Oct 19, 2010 at 4:29 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Tue, Oct 19, 2010 at 12:15 PM, Alister Scott > wrote: > > That list is referrers, not redirects, so watir.com and firewatir.comwon't show. > > Can I see redirects somewhere? > > ?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 Tue Oct 19 13:05:59 2010 From: jarmo.p at gmail.com (Jarmo) Date: Tue, 19 Oct 2010 20:05:59 +0300 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: After given some more thought then there's a possibility to create dynamically some negative case methods like not_exists? for exists? and not_visible? for visible? and so on so it would be possible to wait some time for that condition to happen. This means you could do in Test::Unit assert div.not_exists? instead of assert !div.exists? With RSpec you'd have to use a slightly different syntax than usually: div.should not_exist # (normally you'd use div.should_not exist) But still the case: wait_until {div.text == "something"} doesn't have any solutions at all... one solution would make some #has_(no)_text?(text) method(s) on browser/element classes to support that and some other's too like #has_(no)_class?(css_class) and so on... i don't think that there's actually too many methods which might need these solutions. We could roll that functionality out without breaking any backwards compatibility by having that timeout configured as 0 - e.g. don't wait... Then it could be possible to set that timeout to let's say 2 seconds and you could use "div.should exist" which would wait maximum of 2 seconds before failing if the div doesn't exist. If div exists then it will take as much time as it is taking now. In the future we could start displaying deprecation warnings if timeout stays at 0 - this means that users are not taking advantage of that automatic waiting feature and after few versions we could set that timeout to something else than 0 by default. So, in short, there could be a way to ease some of the current pain by creating dynamically or not dynamically the negative counterparts to current "boolean" methods. I think that #exists? and #visible? are the most used with wait_until... What do you guys think about that not-so-perfect-solution? Do you have any better ideas? Jarmo From notethan at gmail.com Tue Oct 19 14:26:49 2010 From: notethan at gmail.com (Ethan) Date: Tue, 19 Oct 2010 14:26:49 -0400 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: On Tue, Oct 19, 2010 at 13:05, Jarmo wrote: > After given some more thought then there's a possibility to create > dynamically some negative case methods like not_exists? for exists? > and not_visible? for visible? and so on so it would be possible to > wait some time for that condition to happen. > > This means you could do in Test::Unit > assert div.not_exists? > > instead of > > assert !div.exists? > > With RSpec you'd have to use a slightly different syntax than usually: > div.should not_exist # (normally you'd use div.should_not exist) > It seems like it would be very confusing that a method #not_exists? would behave differently than !#exists? (or even need to be defined). I would avoid it. This goes back to what I was saying that I think this should happen in #initialize rather than in subsequent existence-checking. > But still the case: > wait_until {div.text == "something"} > > doesn't have any solutions at all... one solution would make some > #has_(no)_text?(text) method(s) on browser/element classes to support > that and some other's too like #has_(no)_class?(css_class) and so > on... i don't think that there's actually too many methods which might > need these solutions. > Implementing waiting versions of any given commonly-used method (and its negation, to boot) sounds like it would confuse the API a lot. Given that you can use any of those to specify locating a div, checking whether a div(:text, some_text).exists? seems preferable to checking div.has_text?(some_text) However, another idea is extending rspec with a waiting version of its checker. Implement an extension 'should_eventually' (or whatever name, that's just off the top of my head), such that: div.should_eventually exist will run a waiter checking div's existence, and fail if it doesn't come into existence within whatever timeout. You could use this with checking text or classname or whatever without implementing waiting versions of those methods. I don't know where an extension like that should live, exactly, it seems outside the scope of watir itself. but, it's an idea. We could roll that functionality out without breaking any backwards > compatibility by having that timeout configured as 0 - e.g. don't > wait... > Well, waiting should hopefully not break any compatibility - but potentially slow some things down significantly. For example, an application that uses watir that I work with takes a string and (sometimes) checks if there is an element with that id; if not checks if there is an element with that name; then tries for label with that text. If each of those added a few seconds, that'd be bad. Then it could be possible to set that timeout to let's say 2 seconds > and you could use "div.should exist" which would wait maximum of 2 > seconds before failing if the div doesn't exist. If div exists then it > will take as much time as it is taking now. > > In the future we could start displaying deprecation warnings if > timeout stays at 0 - this means that users are not taking advantage of > that automatic waiting feature and after few versions we could set > that timeout to something else than 0 by default. > I don't know. I think it's good functionality to have available, but I'm getting more and more hesitant about the idea of changing the default to wait any length of time - I do too much checking of maybe-nonexistent elements in various places. > So, in short, there could be a way to ease some of the current pain by > creating dynamically or not dynamically the negative counterparts to > current "boolean" methods. > > I think that #exists? and #visible? are the most used with wait_until... > > What do you guys think about that not-so-perfect-solution? Do you have > any better ideas? > > Jarmo > _______________________________________________ > 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 Tue Oct 19 16:03:10 2010 From: jarmo.p at gmail.com (Jarmo) Date: Tue, 19 Oct 2010 23:03:10 +0300 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: On Tue, Oct 19, 2010 at 9:26 PM, Ethan wrote: > It seems like it would be very confusing that a method #not_exists? would > behave differently than !#exists? (or even need to be defined). I would > avoid it. This goes back to what I was saying that I think this should > happen in #initialize rather than in subsequent existence-checking. The only thing that would behave differently would be the automatic waiting. Otherwise it would behave the same so i don't see much of a problem. Agreed though that it would make the API more complicated and possibly confusing. I still don't see any advantages of waiting automatically in #initialize due to the fact as you itself mentioned later on that you're checking also non-existance of an elements. > Implementing waiting versions of any given commonly-used method (and its > negation, to boot) sounds like it would confuse the API a lot. Given that > you can use any of those to specify locating a div, checking whether a > div(:text, some_text).exists? seems preferable to checking > div.has_text?(some_text) You just gave actually a great idea - instead of using wait_until {div.text == "something"} you could use wait_until {div(:text => "something").exists?}. This means that #exists? could in theory wait. I haven't used :text locator in these circumstances at all. This means also that the only possible automatically waiting methods could be #exists? and #visible? ... > However, another idea is extending rspec with a waiting version of its > checker. Implement an extension 'should_eventually' (or whatever name, > that's just off the top of my head), such that: > ??div.should_eventually exist > will run a waiter checking div's existence, and fail if it doesn't come into > existence within whatever timeout. You could use this with checking text or > classname or whatever without implementing waiting versions of those > methods. > I don't know where an extension like that should live, exactly, it seems > outside the scope of watir itself. but, it's an idea. Yup, i also thought about that, but this means that you'd have to create something like that in every testing framework you'd like to use. Best would be to have it done at one place - e.g. in Watir. > Well, waiting should hopefully not break any compatibility - but potentially > slow some things down significantly. For example, an application that uses > watir that I work with ?takes a string and (sometimes) checks if there is an > element with that id; if not checks if there is an element with that name; > then tries for label with that text. If each of those added a few seconds, > that'd be bad. My point was that it wouldn't break any backwards incompatibility nor slow down anything due to the fact that default timeout could be 0 as it currently practically is. I also have used similar solution to you by searching by multiple locators and allowing strings as a locator, but i've ditched it due to the possible problems (i wanted to find a different element, but ended up with something else due to some similar attribute) and actually making tests harder to read (of course it is a matter of taste). Also the main reason why i ditched that solution was due to the fact that it made tests considerably slower (what if you're always searching by something which is checked last?). That is especially true if some larger html pages with many elements are used. > I don't know. I think it's good functionality to have available, but I'm > getting more and more hesitant about the idea of changing the default to > wait any length of time - I do too much checking of maybe-nonexistent > elements in various places. So the only problem would remain if using some solution which allows a string as a locator and then searching by different locator types. You could in these methods to set timeout to 0 and after the method is done, revert the timeout back to it's original value so you wouldn't have to use wait_until's for "normal" checking for #exists? and such... So, in a light of this e-mail i see having only two additional methods - #not_exists? and #not_visible?. We could document then in RDoc properly to point out the differences between !exists? and not_exists?. I don't see any problems with that. With only these two changes it would be also quite easy to convert your existing test suites to work with a better way and remove many wait_until's by some global search & replace: !exists? => not_exists? not exists? => not_exists? !visible? => not_visible? not visible? => not_visible? I think that this is one of the functionalities where we'd have to make some compromises between adding two (could be little-bit confusing) methods + making tests a little more cleaner and using wait_until or something similar pretty heavily every here and there. I'm starting to like the former. Jari, Charley, Bret and anyone else, what are your thoughts on the subject (it would be better if you answered only if you've used Watir with AJAX/JavaScript heavy sites where is a need to use wait_until or something similar). Jarmo From watirjira at gmail.com Tue Oct 19 16:14:20 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Tue, 19 Oct 2010 15:14:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-449) making Element#click_no_wait faster and easier debuggable In-Reply-To: <16766026.183.1280354011131.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <17763659.142.1287519260375.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19946#action_19946 ] Jarmo Pertman commented on WTR-449: ----------------------------------- I realised now that rubygems is not actually needed in the spawned process as it was not before. It is possible to simplify the populating of $LOAD_PATH code a little and use watir-s libraries only. I also realised that populating $LOAD_PATH with junk didn't add any extra time (at least not anything considerable) due to the fact that the files themselves were not actually loaded (see my comment above, which tried to state otherwise). So, in short - it still could be possible to remove the loading of rubygems and speed up #click_no_wait even more. Adding this to my TODO-list :) > making Element#click_no_wait faster and easier debuggable > --------------------------------------------------------- > > Key: WTR-449 > URL: http://jira.openqa.org/browse/WTR-449 > Project: Watir > Issue Type: Improvement > Components: HTML Controls > Affects Versions: 1.6.5 > Environment: all environments > Reporter: Jarmo Pertman > Priority: Major > > I have been thinking of improving Element#click_no_wait for some time now. I can see the following problems with current solution: > 1) code is not good - method _code_that_copies_readonly_array with funny comment in main namespace, eval_in_spawned_process with TODO and not-TODO comments > 2) users have a lot of problems with click_no_wait (http://bit.ly/asirep) and current code doesn't allow easy debugging with monkey-patching or similar solutions > 3) in the spawned process used for click_no_wait, no rubygems is loaded thus it's possible that users without having RUBYOPT set to -rubygems can't use click_no_wait and since it's hard to debug (see point #2) then they don't even know what's the problem > 4) click_no_wait is just slow because it loads too many files/libraries in it's own process - it should just load all the necessary things and nothing else > 5) currently, in the unit tests click_no_wait process doesn't use development libraries > Here is a benchmark: > *click_no_wait_bench.rb:* > {noformat} > require "rubygems" > require "watir" > require "benchmark" > b = Watir::Browser.new > b.goto "http://www.google.com" > times = 5 > # almost original watir 1.6.5 code > # * added gsub to avoid bug for some ruby versions > # * using ruby instead of start rubyw to measure time > module Watir > module PageContainer > def eval_in_spawned_process(command) > command.strip! > load_path_code = _code_that_copies_readonly_array($LOAD_PATH, '$LOAD_PATH') > ruby_code = "require 'watir/ie'; " > # ruby_code = "$HIDE_IE = #{$HIDE_IE};" # This prevents attaching to a window from setting it visible. However modal dialogs cannot be attached to when not visible. > ruby_code << "pc = #{attach_command}; " # pc = page container > # IDEA: consider changing this to not use instance_eval (it makes the code hard to understand) > ruby_code << "pc.instance_eval(#{command.inspect})" > exec_string = "ruby -e #{(load_path_code + '; ' + ruby_code).inspect}".gsub("\\\"", "'") > system(exec_string) > end > end > end > Benchmark.bmbm do |x| > x.report("watir 1.6.5") {times.times {b.button(:name => "btnG").click_no_wait}} > end > =begin > Rehearsal ----------------------------------------------- > watir 1.6.5 0.031000 0.015000 0.046000 ( 26.136495) > -------------------------------------- total: 0.046000sec > user system total real > watir 1.6.5 0.000000 0.000000 0.000000 ( 23.600350) > =end > # improved section > # * simplified click_no_wait methods > # * requiring rubygems incase of missing RUBYOPT > # * extracted ruby_execute_command into method for easier monkey-patching for debugging and testing reasons > module Watir > class Element > def click_no_wait > assert_enabled > highlight(:set) > element = "#{self.class}.new(#{@page_container.attach_command}, :unique_number, #{self.unique_number})" > @page_container.click_no_wait(element) > highlight(:clear) > end > end > module PageContainer > def click_no_wait(element) > ruby_code = "require 'rubygems';" << > "require 'watir/ie';" << > "#{element}.click!" > system(spawned_click_no_wait_command(ruby_code)) > end > def spawned_click_no_wait_command(command) > "start rubyw -e #{command.inspect}" > end > private :spawned_click_no_wait_command > end > end > Benchmark.bmbm do |x| > x.report("watir improved - ie") {times.times {b.button(:name => "btnG").click_no_wait}} > end > =begin > Rehearsal ------------------------------------------------------- > watir improved - ie 0.032000 0.047000 0.079000 ( 20.141152) > ---------------------------------------------- total: 0.079000sec > user system total real > watir improved - ie 0.047000 0.016000 0.063000 ( 18.931083) > =end > # * loading watir/core.rb to reduce loading of unneeded files/libraries > module Watir > class Element > def click_no_wait > assert_enabled > highlight(:set) > element = "#{self.class}.new(#{@page_container.attach_command}, :unique_number, #{self.unique_number})" > @page_container.click_no_wait(element) > highlight(:clear) > end > end > module PageContainer > def click_no_wait(element) > ruby_code = "require 'rubygems';" << > "require '#{File.expand_path(File.dirname(__FILE__))}/watir/core';" << > "#{element}.click!" > system(spawned_click_no_wait_command(ruby_code)) > end > def spawned_click_no_wait_command(command) > unless $DEBUG > "start rubyw -e #{command.inspect}" > else > puts "#click_no_wait command:" > command = "ruby -e #{command.inspect}" > puts command > command > end > end > private :spawned_click_no_wait_command > end > end > Benchmark.bmbm do |x| > x.report("watir improved - click_no_wait") {times.times {b.button(:name => "btnG").click_no_wait}} > end > =begin > Rehearsal ------------------------------------------------------------------ > watir improved - click_no_wait 0.062000 0.015000 0.077000 ( 9.729557) > --------------------------------------------------------- total: 0.077000sec > user system total real > watir improved - click_no_wait 0.015000 0.047000 0.062000 ( 9.308532) > =end > b.close > {noformat} > *watir/core.rb:* > {noformat} > require 'watir/win32ole' > require 'logger' > require 'watir/exceptions' > require 'watir/matches' > require 'watir/core_ext' > require 'watir/logger' > require 'watir/container' > require 'watir/locator' > require 'watir/page-container' > require 'watir/ie-class' > require 'watir/element' > require 'watir/element_collections' > require 'watir/form' > require 'watir/non_control_elements' > require 'watir/input_elements' > require 'watir/table' > require 'watir/image' > require 'watir/link' > require 'watir/html_element' > require 'watir/waiter' > require 'watir/module' > {noformat} > As it's possible to see from the results then i got click_no_wait to perform faster about 2-3 times (of course this depends on the PC and so on, but these are the results from my machine, which is a quite average laptop)! > Results: > 1) removed all this unnecessary and funny-looking code which also had slight of a "criminal overengineering" smell on it (http://coderoom.wordpress.com/2010/06/23/criminal-overengineering/) > 2) it is now easy to debug #click_no_wait problems: > {noformat} > $DEBUG = true > element.click_no_wait > {noformat} > 3) requiring rubygems always, just in case, in the spawned process > 4) click_no_wait performs 2-3x faster! It might be possible to improve the performance even more by doing some larger changes with the require statements in watir/core.rb - unfortunately it is not possible anymore to make changes in smaller steps > 5) all click_no_wait invocations in unit tests use now development libraries > Fixes are in branch click_no_wait_patch: > http://github.com/jarmo/watir/tree/click_no_wait_patch -- 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 brettcsykes at gmail.com Tue Oct 19 16:39:55 2010 From: brettcsykes at gmail.com (brett sykes) Date: Tue, 19 Oct 2010 16:39:55 -0400 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: This seems like a really good idea. What I'm currently doing with our AJAX heavy site now feels very overcomplicated. On Tue, Oct 19, 2010 at 4:03 PM, Jarmo wrote: > On Tue, Oct 19, 2010 at 9:26 PM, Ethan wrote: > > It seems like it would be very confusing that a method #not_exists? would > > behave differently than !#exists? (or even need to be defined). I would > > avoid it. This goes back to what I was saying that I think this should > > happen in #initialize rather than in subsequent existence-checking. > > The only thing that would behave differently would be the automatic > waiting. Otherwise it would behave the same so i don't see much of a > problem. Agreed though that it would make the API more complicated and > possibly confusing. I still don't see any advantages of waiting > automatically in #initialize due to the fact as you itself mentioned > later on that you're checking also non-existance of an elements. > > > Implementing waiting versions of any given commonly-used method (and its > > negation, to boot) sounds like it would confuse the API a lot. Given that > > you can use any of those to specify locating a div, checking whether a > > div(:text, some_text).exists? seems preferable to checking > > div.has_text?(some_text) > > You just gave actually a great idea - instead of using wait_until > {div.text == "something"} you could use wait_until {div(:text => > "something").exists?}. This means that #exists? could in theory wait. > I haven't used :text locator in these circumstances at all. This means > also that the only possible automatically waiting methods could be > #exists? and #visible? ... > > > However, another idea is extending rspec with a waiting version of its > > checker. Implement an extension 'should_eventually' (or whatever name, > > that's just off the top of my head), such that: > > div.should_eventually exist > > will run a waiter checking div's existence, and fail if it doesn't come > into > > existence within whatever timeout. You could use this with checking text > or > > classname or whatever without implementing waiting versions of those > > methods. > > I don't know where an extension like that should live, exactly, it seems > > outside the scope of watir itself. but, it's an idea. > > Yup, i also thought about that, but this means that you'd have to > create something like that in every testing framework you'd like to > use. Best would be to have it done at one place - e.g. in Watir. > > > Well, waiting should hopefully not break any compatibility - but > potentially > > slow some things down significantly. For example, an application that > uses > > watir that I work with takes a string and (sometimes) checks if there is > an > > element with that id; if not checks if there is an element with that > name; > > then tries for label with that text. If each of those added a few > seconds, > > that'd be bad. > > My point was that it wouldn't break any backwards incompatibility nor > slow down anything due to the fact that default timeout could be 0 as > it currently practically is. > > I also have used similar solution to you by searching by multiple > locators and allowing strings as a locator, but i've ditched it due to > the possible problems (i wanted to find a different element, but ended > up with something else due to some similar attribute) and actually > making tests harder to read (of course it is a matter of taste). Also > the main reason why i ditched that solution was due to the fact that > it made tests considerably slower (what if you're always searching by > something which is checked last?). That is especially true if some > larger html pages with many elements are used. > > > I don't know. I think it's good functionality to have available, but I'm > > getting more and more hesitant about the idea of changing the default to > > wait any length of time - I do too much checking of maybe-nonexistent > > elements in various places. > > So the only problem would remain if using some solution which allows a > string as a locator and then searching by different locator types. You > could in these methods to set timeout to 0 and after the method is > done, revert the timeout back to it's original value so you wouldn't > have to use wait_until's for "normal" checking for #exists? and > such... > > So, in a light of this e-mail i see having only two additional methods > - #not_exists? and #not_visible?. We could document then in RDoc > properly to point out the differences between !exists? and > not_exists?. I don't see any problems with that. > > With only these two changes it would be also quite easy to convert > your existing test suites to work with a better way and remove many > wait_until's by some global search & replace: > !exists? => not_exists? > not exists? => not_exists? > > !visible? => not_visible? > not visible? => not_visible? > > I think that this is one of the functionalities where we'd have to > make some compromises between adding two (could be little-bit > confusing) methods + making tests a little more cleaner and using > wait_until or something similar pretty heavily every here and there. > I'm starting to like the former. > > Jari, Charley, Bret and anyone else, what are your thoughts on the > subject (it would be better if you answered only if you've used Watir > with AJAX/JavaScript heavy sites where is a need to use wait_until or > something similar). > > Jarmo > _______________________________________________ > 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 Tue Oct 19 16:53:14 2010 From: jarmo.p at gmail.com (Jarmo) Date: Tue, 19 Oct 2010 23:53:14 +0300 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: I wouldn't want to agree that it is overcomplicated by just using wait_until (or in 1.6.7 those other convenience methods), but it is just a nuisance and causes troubles here and there (oh damn, i forgot to put one wait here and now it's failing intermittently). It would be great to minimize these places (with the cost of making API a really little-tiny bit more complicated). The real question is if we're willing to pay that small price. I would be :) Jarmo On Tue, Oct 19, 2010 at 11:39 PM, brett sykes wrote: > This seems like a really good idea. What I'm currently doing with our AJAX > heavy site now feels very overcomplicated. From jari.bakken at gmail.com Tue Oct 19 17:38:27 2010 From: jari.bakken at gmail.com (Jari Bakken) Date: Tue, 19 Oct 2010 23:38:27 +0200 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: On Mon, Oct 18, 2010 at 3:10 AM, Ethan wrote: > I also think that this should happen in #initialize, and not in > #assert_exists - it should only happen once at the beginning, not whenever > you try to do anything with an element. Actually both watir-webdriver and celerity keeps the lazy locate semantics but will cache the result of #locate. So the lookup only happens once, not every time #assert_exists is called. I can't recall if this was ever added to Watir, but I guess not based on your comments here. The caching has some minor drawbacks (i.e. element objects becoming obsolete - which has caused suprisingly less confusion among users than I had anticipated), but it avoids the problem of repeatedly waiting. This could probably be the subject of a whole other thread though. On Mon, Oct 18, 2010 at 7:10 PM, Jarmo wrote: > Jari: does that implicit wait in WD mean that 1.5 seconds is waited > everytime before throwing out an Exception? This is not what i'd want. > I fell off around here. If the element never appears, then yes WebDriver will raise an exception. In watir(-webdriver), Element#exists? never raises any exceptions of course. Why is this not what you want? I don't think it's unreasonable to provide configurable implicit waits and let people use wait_until (or element.wait_while_present) when they want to make sure elements disappear. > After giving some more thought about it then i cannot see any perfect > solution to it and i'm starting to believe that there are none :( > > To give you a better picture of the current situation then this is > what i have to do currently in my tests for example: > button.click > # some javascript work > wait_until {div.exists?) > > button.click > # some javascript work > wait_until {div.visible?} > > button.click > # some javascript work > wait_until {div.text == "expected text"} > > button.click > # some javascript work > wait_until {not div.exists?} > Page objects would make the above much neater, since you can hide all the waiting logic in the pages/components where they are required. > And i would like to do these examples like this with RSpec: > button.click > # some javascript work > div.should exist > > button.click > # some javascript work > div.should be_visible > This is hiding too much for my taste - it's much better to be explicit about how/what to wait for when interacting with *the browser tool*. If this makes your tests look ugly, then it's time to add another abstraction - page objects - not try to make the browser tool guess what you're really after. I liked Ethan's idea of creating an RSpec matcher, i.e.: div.should eventually_exist div.should eventually_be_visible The implementation should be super simple (and a collection of such matchers could be provided in a separate gem). > button.click > # some javascript work > div.text.should == "expected text" > div(:text => "expected").should eventually_exist or using the existing wait stuff div.when_present.text.should == "expected text" > button.click > # some javascript work > div.should_not exist div.should eventually_not_exist In general, I dislike waiting for things to go away - it very often leads to hard-to-debug race conditions. Better to wait for the stuff you want to interact with to be present. It's not always possible, but should be much rarer than the opposite case. On Tue, Oct 19, 2010 at 7:05 PM, Jarmo wrote: > This means you could do in Test::Unit > assert div.not_exists? > > instead of > > assert !div.exists? > > With RSpec you'd have to use a slightly different syntax than usually: > div.should not_exist # (normally you'd use div.should_not exist) > Really? I agree with Ethan. This is just way too confusing - without adding very much value over what we have. > > Then it could be possible to set that timeout to let's say 2 seconds > and you could use "div.should exist" which would wait maximum of 2 > seconds before failing if the div doesn't exist. If div exists then it > will take as much time as it is taking now. > This is exactly what WebDriver does. > In the future we could start displaying deprecation warnings if > timeout stays at 0 - this means that users are not taking advantage of > that automatic waiting feature and after few versions we could set > that timeout to something else than 0 by default. Why would the default ever change from 0? I'm strongly against this - the default should encourage explicit waiting IMO, which are *always* more robust. > > What do you guys think about that not-so-perfect-solution? Do you have > any better ideas? > Be explicit about what you need from the browser. Use abstractions to make your test code communicate. Otherwise, I'm keen to keep the API as simple as possible, so if we need to add something for this I would rather have: Element#appears? Element#disappears? and some (custom) RSpec matchers: element.should appear element.should disappear Jari PS. I'll be travelling and won't be able to follow up this thread much in the coming days. From bret at pettichord.com Tue Oct 19 21:06:40 2010 From: bret at pettichord.com (Bret Pettichord) Date: Tue, 19 Oct 2010 20:06:40 -0500 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: On Tue, Oct 19, 2010 at 3:03 PM, Jarmo wrote: > Jari, Charley, Bret and anyone else, what are your thoughts on the > subject (it would be better if you answered only if you've used Watir > with AJAX/JavaScript heavy sites where is a need to use wait_until or > something similar). > I would like to see a proposal, first, for a new method that encapsulates your entire proposal. I'm seeing lots of interesting ideas and interesting objections and counter-proposals, so I'm still unclear if there is a crisp idea in your mind of what you want to do. This actually sounds like a good use case for Google Wave; too bad it died. To me, the core scenario is browser.element(:attribute, 'value').when_present.click (or set or whatever). By making this a new method, it allows us to focus on exactly how we would configure the when_present method (how long to wait, wait for visible? exists? both, other methods, too?). Like i said i would like a clear proposal on this. Because in itself this raises no issues of compatibility, it will be easier to reach consensus on what this needs to be to be most useful/understandable. To me you are struggling over the corner cases because you are jumping to step 2, which would be for Watir to always make calls to when_present. And do me there is a real question about whether you would always do this or perhaps only for some/most methods. Also it raises the issue about whether this level of "implicit" invokation would itself need to be configurable. The third step would be to talk about deprecation and forcing people to use this new scheme. To me it is premature to discuss such matters. Typically it takes us years after new methods are introduced before we can discuss deprecation and even then there are often many people who stick to the old ways. I also liked Jari's comments about how much of this might simply be avoided with proper use of page objects. Personally I always use page objects, but I don't think this technique is understood by the majority of the Watir community. Maybe we just need some better writing, explanation in this area. Or maybe someone should create a page object class/library/gem that itself includes the automatic waiting functionality that you are proposing. It might make sense to bundle that with some of the new rspec matchers that have been discussed here as well. Bret -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Tue Oct 19 21:39:20 2010 From: watirjira at gmail.com (Bret Pettichord (JIRA)) Date: Tue, 19 Oct 2010 20:39:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-458) Watir version 1.6.6 doesn't show correct version number In-Reply-To: <20139552.12.1286901259841.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <33041029.144.1287538760338.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret Pettichord updated WTR-458: -------------------------------- Priority: Minor (was: Major) > Watir version 1.6.6 doesn't show correct version number > ------------------------------------------------------- > > Key: WTR-458 > URL: http://jira.openqa.org/browse/WTR-458 > Project: Watir > Issue Type: Bug > Components: Gem installer > Affects Versions: 1.6.6 > Environment: Windows XP, IE8 > Reporter: Ning Cao > > I'm running Watir on Windows XP and just updated to version 1.6.6, after the installation I wanted to check the version by using > ruby -e 'require "watir"; puts Watir::IE::VERSION' > [expected]Should show version number 1.6.6 > [actual]The output was: > -e:1: warning: toplevel constant VERSION referenced by Watir::IE::VERSION > 1.8.6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Tue Oct 19 21:44:20 2010 From: watirjira at gmail.com (Bret Pettichord (JIRA)) Date: Tue, 19 Oct 2010 20:44:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-449) making Element#click_no_wait faster and easier debuggable In-Reply-To: <16766026.183.1280354011131.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <28074756.146.1287539060179.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19947#action_19947 ] Bret Pettichord commented on WTR-449: ------------------------------------- OK. So i wrote the original code. The only reason for the criminal overengineering of replicating the loadpath was to ensure that the same version of watir was being used in the spawned process. This was important for me in testing it originally. Without this, it would use the installed Watir, not the development watir (unless i made sure to install it before testing). As long as you understand this, i don't have a problem with these changes. Actually we don't use any of this code at Convio any more any way. Instead we spawn a process once and then just connect to it in each call to click_no_wait. This is even faster. > making Element#click_no_wait faster and easier debuggable > --------------------------------------------------------- > > Key: WTR-449 > URL: http://jira.openqa.org/browse/WTR-449 > Project: Watir > Issue Type: Improvement > Components: HTML Controls > Affects Versions: 1.6.5 > Environment: all environments > Reporter: Jarmo Pertman > Priority: Major > > I have been thinking of improving Element#click_no_wait for some time now. I can see the following problems with current solution: > 1) code is not good - method _code_that_copies_readonly_array with funny comment in main namespace, eval_in_spawned_process with TODO and not-TODO comments > 2) users have a lot of problems with click_no_wait (http://bit.ly/asirep) and current code doesn't allow easy debugging with monkey-patching or similar solutions > 3) in the spawned process used for click_no_wait, no rubygems is loaded thus it's possible that users without having RUBYOPT set to -rubygems can't use click_no_wait and since it's hard to debug (see point #2) then they don't even know what's the problem > 4) click_no_wait is just slow because it loads too many files/libraries in it's own process - it should just load all the necessary things and nothing else > 5) currently, in the unit tests click_no_wait process doesn't use development libraries > Here is a benchmark: > *click_no_wait_bench.rb:* > {noformat} > require "rubygems" > require "watir" > require "benchmark" > b = Watir::Browser.new > b.goto "http://www.google.com" > times = 5 > # almost original watir 1.6.5 code > # * added gsub to avoid bug for some ruby versions > # * using ruby instead of start rubyw to measure time > module Watir > module PageContainer > def eval_in_spawned_process(command) > command.strip! > load_path_code = _code_that_copies_readonly_array($LOAD_PATH, '$LOAD_PATH') > ruby_code = "require 'watir/ie'; " > # ruby_code = "$HIDE_IE = #{$HIDE_IE};" # This prevents attaching to a window from setting it visible. However modal dialogs cannot be attached to when not visible. > ruby_code << "pc = #{attach_command}; " # pc = page container > # IDEA: consider changing this to not use instance_eval (it makes the code hard to understand) > ruby_code << "pc.instance_eval(#{command.inspect})" > exec_string = "ruby -e #{(load_path_code + '; ' + ruby_code).inspect}".gsub("\\\"", "'") > system(exec_string) > end > end > end > Benchmark.bmbm do |x| > x.report("watir 1.6.5") {times.times {b.button(:name => "btnG").click_no_wait}} > end > =begin > Rehearsal ----------------------------------------------- > watir 1.6.5 0.031000 0.015000 0.046000 ( 26.136495) > -------------------------------------- total: 0.046000sec > user system total real > watir 1.6.5 0.000000 0.000000 0.000000 ( 23.600350) > =end > # improved section > # * simplified click_no_wait methods > # * requiring rubygems incase of missing RUBYOPT > # * extracted ruby_execute_command into method for easier monkey-patching for debugging and testing reasons > module Watir > class Element > def click_no_wait > assert_enabled > highlight(:set) > element = "#{self.class}.new(#{@page_container.attach_command}, :unique_number, #{self.unique_number})" > @page_container.click_no_wait(element) > highlight(:clear) > end > end > module PageContainer > def click_no_wait(element) > ruby_code = "require 'rubygems';" << > "require 'watir/ie';" << > "#{element}.click!" > system(spawned_click_no_wait_command(ruby_code)) > end > def spawned_click_no_wait_command(command) > "start rubyw -e #{command.inspect}" > end > private :spawned_click_no_wait_command > end > end > Benchmark.bmbm do |x| > x.report("watir improved - ie") {times.times {b.button(:name => "btnG").click_no_wait}} > end > =begin > Rehearsal ------------------------------------------------------- > watir improved - ie 0.032000 0.047000 0.079000 ( 20.141152) > ---------------------------------------------- total: 0.079000sec > user system total real > watir improved - ie 0.047000 0.016000 0.063000 ( 18.931083) > =end > # * loading watir/core.rb to reduce loading of unneeded files/libraries > module Watir > class Element > def click_no_wait > assert_enabled > highlight(:set) > element = "#{self.class}.new(#{@page_container.attach_command}, :unique_number, #{self.unique_number})" > @page_container.click_no_wait(element) > highlight(:clear) > end > end > module PageContainer > def click_no_wait(element) > ruby_code = "require 'rubygems';" << > "require '#{File.expand_path(File.dirname(__FILE__))}/watir/core';" << > "#{element}.click!" > system(spawned_click_no_wait_command(ruby_code)) > end > def spawned_click_no_wait_command(command) > unless $DEBUG > "start rubyw -e #{command.inspect}" > else > puts "#click_no_wait command:" > command = "ruby -e #{command.inspect}" > puts command > command > end > end > private :spawned_click_no_wait_command > end > end > Benchmark.bmbm do |x| > x.report("watir improved - click_no_wait") {times.times {b.button(:name => "btnG").click_no_wait}} > end > =begin > Rehearsal ------------------------------------------------------------------ > watir improved - click_no_wait 0.062000 0.015000 0.077000 ( 9.729557) > --------------------------------------------------------- total: 0.077000sec > user system total real > watir improved - click_no_wait 0.015000 0.047000 0.062000 ( 9.308532) > =end > b.close > {noformat} > *watir/core.rb:* > {noformat} > require 'watir/win32ole' > require 'logger' > require 'watir/exceptions' > require 'watir/matches' > require 'watir/core_ext' > require 'watir/logger' > require 'watir/container' > require 'watir/locator' > require 'watir/page-container' > require 'watir/ie-class' > require 'watir/element' > require 'watir/element_collections' > require 'watir/form' > require 'watir/non_control_elements' > require 'watir/input_elements' > require 'watir/table' > require 'watir/image' > require 'watir/link' > require 'watir/html_element' > require 'watir/waiter' > require 'watir/module' > {noformat} > As it's possible to see from the results then i got click_no_wait to perform faster about 2-3 times (of course this depends on the PC and so on, but these are the results from my machine, which is a quite average laptop)! > Results: > 1) removed all this unnecessary and funny-looking code which also had slight of a "criminal overengineering" smell on it (http://coderoom.wordpress.com/2010/06/23/criminal-overengineering/) > 2) it is now easy to debug #click_no_wait problems: > {noformat} > $DEBUG = true > element.click_no_wait > {noformat} > 3) requiring rubygems always, just in case, in the spawned process > 4) click_no_wait performs 2-3x faster! It might be possible to improve the performance even more by doing some larger changes with the require statements in watir/core.rb - unfortunately it is not possible anymore to make changes in smaller steps > 5) all click_no_wait invocations in unit tests use now development libraries > Fixes are in branch click_no_wait_patch: > http://github.com/jarmo/watir/tree/click_no_wait_patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Tue Oct 19 21:48:20 2010 From: watirjira at gmail.com (Bret Pettichord (JIRA)) Date: Tue, 19 Oct 2010 20:48:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Reopened: (WTR-320) click_no_wait does not work on ruby186-27_rc2 Message-ID: <24570754.153.1287539300090.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret Pettichord reopened WTR-320: --------------------------------- Reopening so we can mark what version the fix is in. > click_no_wait does not work on ruby186-27_rc2 > --------------------------------------------- > > Key: WTR-320 > URL: http://jira.openqa.org/browse/WTR-320 > Project: Watir > Issue Type: Bug > Components: Inputs > Affects Versions: 1.6.2 > Environment: Vista SP1 IE8, normal administrator account with default security settings (UAC enabled, IE protected mode enabled) > Reporter: Bill Agee > Priority: Major > Fix For: Next > > Attachments: patch.txt > > > Several people (including myself) have had problems using click_no_wait on Vista. > The symptom is that the element being clicked will flash yellow, but nothing happens beyond that. The click does not seem to be received. > A patch that solves this problem was posted to the watir dev list, by Derek Berner: > http://rubyforge.org/pipermail/wtr-development/2009-January/000400.html > Looks like the patch was for Windows Server 2008, but it worked for me on Vista SP1 with IE8. > But I tried the same patch on XP SP3, with IE8, and click_no_wait no longer worked. A little work may be required to make sure the patch works on both Vista SP1 and XP. Hopefully Server 2008 and Vista RTM will also both work if Vista SP1 has no problems. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Tue Oct 19 21:50:20 2010 From: watirjira at gmail.com (Bret Pettichord (JIRA)) Date: Tue, 19 Oct 2010 20:50:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Resolved: (WTR-320) click_no_wait does not work on ruby186-27_rc2 Message-ID: <33118815.160.1287539420631.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret Pettichord resolved WTR-320. --------------------------------- Resolution: Fixed I guess Next = 1.6.7 > click_no_wait does not work on ruby186-27_rc2 > --------------------------------------------- > > Key: WTR-320 > URL: http://jira.openqa.org/browse/WTR-320 > Project: Watir > Issue Type: Bug > Components: Inputs > Affects Versions: 1.6.2 > Environment: Vista SP1 IE8, normal administrator account with default security settings (UAC enabled, IE protected mode enabled) > Reporter: Bill Agee > Priority: Major > Fix For: Next - 1.6.7 > > Attachments: patch.txt > > > Several people (including myself) have had problems using click_no_wait on Vista. > The symptom is that the element being clicked will flash yellow, but nothing happens beyond that. The click does not seem to be received. > A patch that solves this problem was posted to the watir dev list, by Derek Berner: > http://rubyforge.org/pipermail/wtr-development/2009-January/000400.html > Looks like the patch was for Windows Server 2008, but it worked for me on Vista SP1 with IE8. > But I tried the same patch on XP SP3, with IE8, and click_no_wait no longer worked. A little work may be required to make sure the patch works on both Vista SP1 and XP. Hopefully Server 2008 and Vista RTM will also both work if Vista SP1 has no problems. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Tue Oct 19 22:01:20 2010 From: watirjira at gmail.com (Bret Pettichord (JIRA)) Date: Tue, 19 Oct 2010 21:01:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-235) Xpath.exist returns different results in Watir and Firewatir. Message-ID: <11763970.163.1287540080147.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret Pettichord updated WTR-235: -------------------------------- Affects Version/s: 1.6.5 Fix Version/s: (was: 1.6.0) Someday Component/s: (was: FireWatir) Xpath Support > Xpath.exist returns different results in Watir and Firewatir. > ------------------------------------------------------------- > > Key: WTR-235 > URL: http://jira.openqa.org/browse/WTR-235 > Project: Watir > Issue Type: Bug > Components: Xpath Support > Affects Versions: 1.6.5 > Environment: WinXP Prof SP2, Ruby 1.8, Watir 1.5.6 and Firewatir 1.2.0 > Reporter: Manish Harkut > Priority: Major > Fix For: Someday > > Attachments: test.html, xpath_bug.rb > > > iIndex = 1 > $ie.div(:xpath,'/html/body/div[18]/div[3]/div[2]/div[7]/div/div/div[' + iIndex.to_s + ']').exists? > The Watir and FireWatir returns different values for the above statement. > If FireWatir it retuen true which is right and test aare executed properly However in Watir even if when the objects exists it returns false and test fails. -- 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 Tue Oct 19 23:35:48 2010 From: charley.baker at gmail.com (Charley Baker) Date: Tue, 19 Oct 2010 21:35:48 -0600 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: This was part of what I did in Taza in creating hooks for (aribitrary procs, usually but not always, wait methods for elements) using a basic Page model. It's worked well for 10's of thousands of tests on Ajax heavy sites - Gap brands, Facebook, and others. If Taza doesn't work for you then you may be doing something wrong. :) There are multiple points at which we can decide to handle timeouts and element failures, whether Watir itself needs to deal with it or not is also another question. I'll pull consesus and we need to summarize what we want to do for the watir api. I'm not in favor of including this in the base api, and don't like any of the addon api methods. Sorry, I'm tired after a long weekend. :) Will spend some time on the webdriver api as well to match or argue. Charley Baker Lead Developer, Watir, http://watir.com On Tue, Oct 19, 2010 at 7:06 PM, Bret Pettichord wrote: > > > On Tue, Oct 19, 2010 at 3:03 PM, Jarmo wrote: >> >> Jari, Charley, Bret and anyone else, what are your thoughts on the >> subject (it would be better if you answered only if you've used Watir >> with AJAX/JavaScript heavy sites where is a need to use wait_until or >> something similar). > > I would like to see a proposal, first, for a new method that encapsulates > your entire proposal. I'm seeing lots of interesting ideas and interesting > objections and counter-proposals, so I'm still unclear if there is a crisp > idea in your mind of what you want to do. > > This actually sounds like a good use case for Google Wave; too bad it died. > > To me, the core scenario is > > ?? browser.element(:attribute, 'value').when_present.click (or set or > whatever). > > By making this a new method, it allows us to focus on exactly how we would > configure the when_present method (how long to wait, wait for visible? > exists? both, other methods, too?). Like i said i would like a clear > proposal on this. Because in itself this raises no issues of compatibility, > it will be easier to reach consensus on what this needs to be to be most > useful/understandable. > > To me you are struggling over the corner cases because you are jumping to > step 2, which would be for Watir to always make calls to when_present. And > do me there is a real question about whether you would always do this or > perhaps only for some/most methods. Also it raises the issue about whether > this level of "implicit" invokation would itself need to be configurable. > > The third step would be to talk about deprecation and forcing people to use > this new scheme. To me it is premature to discuss such matters. Typically it > takes us years after new methods are introduced before we can discuss > deprecation and even then there are often many people who stick to the old > ways. > > I also liked Jari's comments about how much of this might simply be avoided > with proper use of page objects. Personally I always use page objects, but I > don't think this technique is understood by the majority of the Watir > community. Maybe we just need some better writing, explanation in this area. > > Or maybe someone should create a page object class/library/gem that itself > includes the automatic waiting functionality that you are proposing. It > might make sense to bundle that with some of the new rspec matchers that > have been discussed here as well. > > Bret > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From watirjira at gmail.com Wed Oct 20 03:50:20 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 20 Oct 2010 02:50:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Reopened: (WTR-320) click_no_wait does not work on ruby186-27_rc2 Message-ID: <6636081.171.1287561020658.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarmo Pertman reopened WTR-320: ------------------------------- > click_no_wait does not work on ruby186-27_rc2 > --------------------------------------------- > > Key: WTR-320 > URL: http://jira.openqa.org/browse/WTR-320 > Project: Watir > Issue Type: Bug > Components: Inputs > Affects Versions: 1.6.2 > Environment: Vista SP1 IE8, normal administrator account with default security settings (UAC enabled, IE protected mode enabled) > Reporter: Bill Agee > Priority: Major > Fix For: Next - 1.6.7 > > Attachments: patch.txt > > > Several people (including myself) have had problems using click_no_wait on Vista. > The symptom is that the element being clicked will flash yellow, but nothing happens beyond that. The click does not seem to be received. > A patch that solves this problem was posted to the watir dev list, by Derek Berner: > http://rubyforge.org/pipermail/wtr-development/2009-January/000400.html > Looks like the patch was for Windows Server 2008, but it worked for me on Vista SP1 with IE8. > But I tried the same patch on XP SP3, with IE8, and click_no_wait no longer worked. A little work may be required to make sure the patch works on both Vista SP1 and XP. Hopefully Server 2008 and Vista RTM will also both work if Vista SP1 has no problems. -- 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 Oct 20 03:52:19 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 20 Oct 2010 02:52:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-320) click_no_wait does not work on ruby186-27_rc2 Message-ID: <5458062.178.1287561139982.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarmo Pertman closed WTR-320. ----------------------------- Resolution: Fixed Fix Version/s: (was: Next - 1.6.7) 1.6.6 I noticed that it's marked as fixed in 1.6.7, but this is actually fixed in 1.6.6 already. In 1.6.6 exists a different problem with click_no_wait with frames only. > click_no_wait does not work on ruby186-27_rc2 > --------------------------------------------- > > Key: WTR-320 > URL: http://jira.openqa.org/browse/WTR-320 > Project: Watir > Issue Type: Bug > Components: Inputs > Affects Versions: 1.6.2 > Environment: Vista SP1 IE8, normal administrator account with default security settings (UAC enabled, IE protected mode enabled) > Reporter: Bill Agee > Priority: Major > Fix For: 1.6.6 > > Attachments: patch.txt > > > Several people (including myself) have had problems using click_no_wait on Vista. > The symptom is that the element being clicked will flash yellow, but nothing happens beyond that. The click does not seem to be received. > A patch that solves this problem was posted to the watir dev list, by Derek Berner: > http://rubyforge.org/pipermail/wtr-development/2009-January/000400.html > Looks like the patch was for Windows Server 2008, but it worked for me on Vista SP1 with IE8. > But I tried the same patch on XP SP3, with IE8, and click_no_wait no longer worked. A little work may be required to make sure the patch works on both Vista SP1 and XP. Hopefully Server 2008 and Vista RTM will also both work if Vista SP1 has no problems. -- 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 Wed Oct 20 05:22:23 2010 From: jarmo.p at gmail.com (Jarmo) Date: Wed, 20 Oct 2010 12:22:23 +0300 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: On Wed, Oct 20, 2010 at 12:38 AM, Jari Bakken wrote: > Actually both watir-webdriver and celerity keeps the lazy locate semantics but > will cache the result of #locate. So the lookup only happens once, not > every time #assert_exists is called. so you can't do anything like this? my_div = div(:id => "something") my_div.text.should == "something" my_div.click my_div.text.should == "something else" this of course depends what exactly is cached... if #text was cached then it might not work... of course i don't know the internals of watir-webdriver so much... if the #text is cached then that caching is bad. Caching is quite often overused anyway causing more problems than actually helping. At least i know many projects where problems have "been solved" by caching without inspecting why something is so slow in the first place. For me it is rather hiding the real problems behind the cache to not deal with them :P > If the element never appears, then yes WebDriver will raise an > exception. In watir(-webdriver), Element#exists? never raises any > exceptions of course. Why is this not what you want? I don't think > it's unreasonable to provide configurable implicit waits and let > people use wait_until (or element.wait_while_present) when they want > to make sure elements disappear. Yes, my bad. Exceptions are not thrown at Watir's level, but will be thrown at RSpec level: element.should exist # it doesn't yet due to some ajax So i have to do: wait_until {element.exists?} > Page objects would make the above much neater, since you can hide all > the waiting logic in the pages/components where they are required. Yes, you can, but you're still being forced to use those wait invocations and put them somewhere manually, thus still having the same problem in my mind. You're just hiding the problem at some other level :P > >> And i would like to do these examples like this with RSpec: >> button.click >> # some javascript work >> div.should exist >> >> button.click >> # some javascript work >> div.should be_visible >> > > This is hiding too much for my taste - it's much better to be explicit > about how/what to wait for when interacting with *the browser tool*. > If this makes your tests look ugly, then it's time to add another > abstraction - page objects - not try to make the browser tool guess > what you're really after. But think about manual testing. No manual tester marks test as failing because button appeared after 1 second due to some ajax request because he/she waits it to appear. He/she doesn't even pay any extra attention to it or think about "okay, i'm now waiting for the button to appear". It is just a logical way to do. If the button doesn't appear in a reasonable time then the test will be marked as a failed. But when doing that thing automatically we have to write explicitly "don't fail the test just yet, but try to be logical and wait for the button to appear, please". Idea behind this would make tests more natural by hiding these implicit waits away from the user level. What's the real reason why you're against it? Currently you want more to write because? You don't want to write types (even can't) of variables in Ruby, but you'll have to do it in any statically written language. That doesn't bother me in Ruby, does it bother you? If it doesn't then why does it bother if the waiting is done somewhere in lower level? > > I liked Ethan's idea of creating an RSpec matcher, i.e.: > > ?div.should eventually_exist > ?div.should eventually_be_visible > > The implementation should be super simple (and a collection of such > matchers could be provided in a separate gem). Yep, but the not_exists?, not_visible? solution is also super simple and you won't have to do it for every framework in use. Why not create those methods into Watir itself then? Are we really afraid of adding 2 methods into API? > or using the existing wait stuff > > ?div.when_present.text.should == "expected text" this doesn't work if the text itself is changed by JavaScript... > In general, I dislike waiting for things to go away - it very often > leads to hard-to-debug race conditions. Better to wait for the stuff > you want to interact with to be present. It's not always possible, but > should be much rarer than the opposite case. Yes, agreed that the opposite case happens much rarer, but still happens. >> With RSpec you'd have to use a slightly different syntax than usually: >> div.should not_exist # (normally you'd use div.should_not exist) >> > > Really? I agree with Ethan. This is just way too confusing - without > adding very much value over what we have. Again, the value would be not to have to use wait_until everywhere. >> Then it could be possible to set that timeout to let's say 2 seconds >> and you could use "div.should exist" which would wait maximum of 2 >> seconds before failing if the div doesn't exist. If div exists then it >> will take as much time as it is taking now. >> > > This is exactly what WebDriver does. Yup, but WebDriver doesn't work correctly if i'm waiting the opposite case - !exists? - or does it? > >> In the future we could start displaying deprecation warnings if >> timeout stays at 0 - this means that users are not taking advantage of >> that automatic waiting feature and after few versions we could set >> that timeout to something else than 0 by default. > > Why would the default ever change from 0? I'm strongly against this - > the default should encourage explicit waiting IMO, which are *always* > more robust. Why is it more robust? As mentioned above it happens quite often where wait_until is forgotten because test is passing when created, but will start to fail later intermittently. > Be explicit about what you need from the browser. Use abstractions to > make your test code communicate. Again, i'm explicit - i want some element to exist and i don't care if it exists right away or will exist after 2 seconds because that's what i'd do with testing manually also. > Otherwise, I'm keen to keep the API as simple as possible, so if we > need to add something for this I would rather have: > > Element#appears? > Element#disappears? Maybe having completely different method names is a good idea indeed, but as mentioned below needs a custom RSpec matcher or element.should be_appear... hehe. Element#has_appeared? Element#has_disappeared? In RSpec: element.should have_appeared element.should have_disappeared Still not the best. Maybe there's some even better method name, which would work with RSpec out-of-the-box. > > and some (custom) RSpec matchers: > > element.should appear > element.should disappear > > Jari Jarmo From jarmo.p at gmail.com Wed Oct 20 05:27:39 2010 From: jarmo.p at gmail.com (Jarmo) Date: Wed, 20 Oct 2010 12:27:39 +0300 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: On Wed, Oct 20, 2010 at 4:06 AM, Bret Pettichord wrote: > I also liked Jari's comments about how much of this might simply be avoided > with proper use of page objects. Personally I always use page objects, but I > don't think this technique is understood by the majority of the Watir > community. Maybe we just need some better writing, explanation in this area. Again, how are Page objects solving the problem? You still have to put these wait_until's or when_present's everywhere. > > Or maybe someone should create a page object class/library/gem that itself > includes the automatic waiting functionality that you are proposing. It > might make sense to bundle that with some of the new rspec matchers that > have been discussed here as well. And why it's better than having that functionality in Watir itself? > > Bret Jarmo From jarmo.p at gmail.com Wed Oct 20 05:28:41 2010 From: jarmo.p at gmail.com (Jarmo) Date: Wed, 20 Oct 2010 12:28:41 +0300 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: On Wed, Oct 20, 2010 at 6:35 AM, Charley Baker wrote: > This was part of what I did in Taza in creating hooks for (aribitrary > procs, usually but not always, wait methods for elements) using a > basic Page model. It's worked well for 10's of thousands of tests on > Ajax heavy sites - Gap brands, Facebook, and others. If Taza doesn't > work for you then you may be doing something wrong. :) There are > multiple points at which we can decide to handle timeouts and element > failures, whether Watir itself needs to deal with it or not is also > another question. Can you show the places where the code for that functionality is written? > > Charley Baker > Lead Developer, Watir, http://watir.com Jarmo From zeljko.filipin at wa-research.ch Wed Oct 20 05:37:01 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 20 Oct 2010 11:37:01 +0200 Subject: [Wtr-development] AWTA workshop in Austin In-Reply-To: References: <-391526066479601542@unknownmsgid> Message-ID: On Wed, Oct 13, 2010 at 11:59 PM, Bret Pettichord wrote: > I've never been to Europe. Maybe I should plan a trip there next summer. If you come near Croatia, let me know. :) ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Wed Oct 20 09:55:35 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 20 Oct 2010 15:55:35 +0200 Subject: [Wtr-development] watir-framework and taza groups Message-ID: Hi, Can somebody promote me to moderator of watir-framework [1] and taza [2] groups so I can cleanup the spam? Thanks, ?eljko -- [1] http://tech.groups.yahoo.com/group/watir-framework/ [2] http://groups.google.com/group/taza -------------- next part -------------- An HTML attachment was scrubbed... URL: From charley.baker at gmail.com Wed Oct 20 11:09:31 2010 From: charley.baker at gmail.com (Charley Baker) Date: Wed, 20 Oct 2010 09:09:31 -0600 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: It basically breaks down into elements as they're defined taking a proc: http://github.com/scudco/taza/wiki/Elements -c On Wed, Oct 20, 2010 at 3:28 AM, Jarmo wrote: > On Wed, Oct 20, 2010 at 6:35 AM, Charley Baker wrote: >> This was part of what I did in Taza in creating hooks for (aribitrary >> procs, usually but not always, wait methods for elements) using a >> basic Page model. It's worked well for 10's of thousands of tests on >> Ajax heavy sites - Gap brands, Facebook, and others. If Taza doesn't >> work for you then you may be doing something wrong. :) There are >> multiple points at which we can decide to handle timeouts and element >> failures, whether Watir itself needs to deal with it or not is also >> another question. > > Can you show the places where the code for that functionality is written? > >> >> Charley Baker >> Lead Developer, Watir, http://watir.com > > Jarmo > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From jarmo.p at gmail.com Wed Oct 20 12:40:29 2010 From: jarmo.p at gmail.com (Jarmo) Date: Wed, 20 Oct 2010 19:40:29 +0300 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: Okay, so you'd just do that wait_until in these procs and it's not done anywhere automatically? Jarmo On Wed, Oct 20, 2010 at 6:09 PM, Charley Baker wrote: > It basically breaks down into elements as they're defined taking a > proc: http://github.com/scudco/taza/wiki/Elements > > -c From notethan at gmail.com Wed Oct 20 12:53:00 2010 From: notethan at gmail.com (Ethan) Date: Wed, 20 Oct 2010 12:53:00 -0400 Subject: [Wtr-development] Convio's version of Watir In-Reply-To: References: Message-ID: regarding functionality of converting a html table into an array of hashes - I have recently pushed this to Vapir: http://github.com/vapir/vapir/commit/c1f28e017a1b8a781ac09b14ec26bb90f73532bd I called it #to_hashes - I might have gone with #hashes if I'd remembered that jarib had called his that, although I do not know if the functionality ends up being the same. looking at the watirspec test of it, it looks like it should be the same. mine is rather more complex than jarib's because the apps I have had to test do some interesting things with colSpan that I have to account for, and have varying numbers of header and footer rows that need to be excluded from the data. so, while looking through that code, phrases such as "unreadable mess" might come to mind, that really is the simplest implementation I could manage that satisfies all the tables I have to deal with. -Ethan On Tue, Sep 21, 2010 at 17:19, Jari Bakken wrote: > On Tue, Sep 21, 2010 at 8:38 PM, Ethan wrote: > > http://github.com/bret/convio_watir_extensions/blob/master/lib/convio_watir_extensions/watir.rb#L110 > > This looks handy. I have code to map a table to an array of hashes keyed > > with column headers, which seems to be of similar intent. Not sure about > the > > API, #column is not a very informative name for the method. > > The watir2 branch of watirspec has Table#hashes for this, taking a cue > from Cucumber's Table object. > _______________________________________________ > 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 Wed Oct 20 13:14:29 2010 From: charley.baker at gmail.com (Charley Baker) Date: Wed, 20 Oct 2010 11:14:29 -0600 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: Exactly. I prefer having the test writer decide which DOM elements to wait on. I did play around with wrapped (monkey patched) elements with timed out waits for one of the apps I was testing due to network speed and app issues, but eventually decided on explicitly calling out or adding waits. Charley Baker Lead Developer, Watir, http://watir.com On Wed, Oct 20, 2010 at 10:40 AM, Jarmo wrote: > Okay, so you'd just do that wait_until in these procs and it's not > done anywhere automatically? > > Jarmo > > On Wed, Oct 20, 2010 at 6:09 PM, Charley Baker wrote: >> It basically breaks down into elements as they're defined taking a >> proc: http://github.com/scudco/taza/wiki/Elements >> >> -c > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From brettcsykes at gmail.com Wed Oct 20 14:50:48 2010 From: brettcsykes at gmail.com (brett sykes) Date: Wed, 20 Oct 2010 14:50:48 -0400 Subject: [Wtr-development] automatic waiting? In-Reply-To: References: Message-ID: What Charley is describing (wrapped elements with timed out waits ...) sounds basically like what I've currently built. But, I think after reading this thread, I'm going to remove that functionality and just go back to explicitly setting wait_until for DOM elements inside my page objects instead of having my code magically take care of it. I'm starting to think that it probably just reads better. More importantly, what I did want to say, is that as an end user of the WATIR API, I did find the suggestions for element#appears? / element#disappears? really interesting. On Wed, Oct 20, 2010 at 1:14 PM, Charley Baker wrote: > Exactly. I prefer having the test writer decide which DOM elements to > wait on. I did play around with wrapped (monkey patched) elements with > timed out waits for one of the apps I was testing due to network speed > and app issues, but eventually decided on explicitly calling out or > adding waits. > > > Charley Baker > Lead Developer, Watir, http://watir.com > > > > On Wed, Oct 20, 2010 at 10:40 AM, Jarmo wrote: > > Okay, so you'd just do that wait_until in these procs and it's not > > done anywhere automatically? > > > > Jarmo > > > > On Wed, Oct 20, 2010 at 6:09 PM, Charley Baker > wrote: > >> It basically breaks down into elements as they're defined taking a > >> proc: http://github.com/scudco/taza/wiki/Elements > >> > >> -c > > _______________________________________________ > > 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 Wed Oct 20 15:08:21 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 20 Oct 2010 14:08:21 -0500 (CDT) Subject: [Wtr-development] [JIRA] Resolved: (WTR-458) Watir version 1.6.6 doesn't show correct version number In-Reply-To: <20139552.12.1286901259841.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <863066.187.1287601701139.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarmo Pertman resolved WTR-458. ------------------------------- Resolution: Fixed Fix Version/s: Next - 1.6.7 http://github.com/bret/watir/commit/bb9e65d7c69db1ecbe0a0a0986b57ab2b1fd53a4 > Watir version 1.6.6 doesn't show correct version number > ------------------------------------------------------- > > Key: WTR-458 > URL: http://jira.openqa.org/browse/WTR-458 > Project: Watir > Issue Type: Bug > Components: Gem installer > Affects Versions: 1.6.6 > Environment: Windows XP, IE8 > Reporter: Ning Cao > Fix For: Next - 1.6.7 > > > I'm running Watir on Windows XP and just updated to version 1.6.6, after the installation I wanted to check the version by using > ruby -e 'require "watir"; puts Watir::IE::VERSION' > [expected]Should show version number 1.6.6 > [actual]The output was: > -e:1: warning: toplevel constant VERSION referenced by Watir::IE::VERSION > 1.8.6 -- 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 Wed Oct 20 16:16:05 2010 From: jarmo.p at gmail.com (Jarmo) Date: Wed, 20 Oct 2010 23:16:05 +0300 Subject: [Wtr-development] 1.6.7? Message-ID: Anyone against of making a new release right now? Check out the CHANGES at http://github.com/bret/watir/blob/master/CHANGES Jarmo From bret at pettichord.com Wed Oct 20 17:30:23 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 20 Oct 2010 16:30:23 -0500 Subject: [Wtr-development] 1.6.7? In-Reply-To: References: Message-ID: +1 on making a new release. On Wed, Oct 20, 2010 at 3:16 PM, Jarmo wrote: > Anyone against of making a new release right now? Check out the > CHANGES at http://github.com/bret/watir/blob/master/CHANGES > > Jarmo > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Wed Oct 20 17:38:19 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 20 Oct 2010 16:38:19 -0500 Subject: [Wtr-development] watir-framework and taza groups In-Reply-To: References: Message-ID: Zeljko, You are now the owner/moderator of the watir-framework group. Bret On Wed, Oct 20, 2010 at 8:55 AM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > Hi, > > Can somebody promote me to moderator of watir-framework [1] and taza [2] > groups so I can cleanup the spam? > > Thanks, > > ?eljko > -- > [1] http://tech.groups.yahoo.com/group/watir-framework/ > [2] http://groups.google.com/group/taza > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Wed Oct 20 18:17:38 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 21 Oct 2010 00:17:38 +0200 Subject: [Wtr-development] watir-framework and taza groups In-Reply-To: References: Message-ID: On Wed, Oct 20, 2010 at 11:38 PM, Bret Pettichord wrote: > You are now the owner/moderator of the watir-framework group. Thanks, I have already deleted the most recent spam, I will take a better look tomorrow. Charley has deleted Taza Google group today. We had a short chat and decided that Taza related questions could also be discussed here, so there is no point in having two groups. I am looking at Watir frameworks lately, I will probably have a few questions in the next few days and weeks. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Thu Oct 21 06:03:09 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 21 Oct 2010 12:03:09 +0200 Subject: [Wtr-development] 1.6.7? In-Reply-To: References: Message-ID: On Wed, Oct 20, 2010 at 10:16 PM, Jarmo wrote: > Anyone against of making a new release right now? +1 for 1.6.7 ?eljko -- watir.com - community manager watirpodcast.com - host testingpodcast.com - audio podcasts on software testing. all of them -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Thu Oct 21 06:10:49 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 21 Oct 2010 12:10:49 +0200 Subject: [Wtr-development] watir-framework and taza groups In-Reply-To: References: Message-ID: On Wed, Oct 20, 2010 at 11:38 PM, Bret Pettichord wrote: > You are now the owner/moderator of the watir-framework group. I have found just one more spam message and deleted it. If anybody notices spam somewhere in the group, please let me know so I could delete it. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Thu Oct 21 08:44:44 2010 From: jarmo.p at gmail.com (Jarmo) Date: Thu, 21 Oct 2010 15:44:44 +0300 Subject: [Wtr-development] 1.6.7? In-Reply-To: References: Message-ID: Added back require "watir/waiter" to allow easier upgrading/migrating to Watir::Wait http://github.com/bret/watir/commit/223e04865e610c59b4caec446988acc72372f94a Charley, releasing today? Jarmo On Thu, Oct 21, 2010 at 1:03 PM, ?eljko Filipin wrote: > On Wed, Oct 20, 2010 at 10:16 PM, Jarmo wrote: >> Anyone against of making a new release right now? > > +1 for 1.6.7 > > ?eljko > -- > watir.com - community manager > watirpodcast.com - host > testingpodcast.com - audio podcasts on software testing. all of them > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From charley.baker at gmail.com Thu Oct 21 10:09:19 2010 From: charley.baker at gmail.com (Charley Baker) Date: Thu, 21 Oct 2010 08:09:19 -0600 Subject: [Wtr-development] 1.6.7? In-Reply-To: References: Message-ID: Yep, I'll run tests, tag and release. Charley Baker Lead Developer, Watir, http://watir.com On Thu, Oct 21, 2010 at 6:44 AM, Jarmo wrote: > Added back require "watir/waiter" to allow easier upgrading/migrating > to Watir::Wait > > http://github.com/bret/watir/commit/223e04865e610c59b4caec446988acc72372f94a > > Charley, releasing today? > > Jarmo > > On Thu, Oct 21, 2010 at 1:03 PM, ?eljko Filipin > wrote: >> On Wed, Oct 20, 2010 at 10:16 PM, Jarmo wrote: >>> Anyone against of making a new release right now? >> >> +1 for 1.6.7 >> >> ?eljko >> -- >> watir.com - community manager >> watirpodcast.com - host >> testingpodcast.com - audio podcasts on software testing. all of them >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development From jarmo.p at gmail.com Thu Oct 21 13:49:51 2010 From: jarmo.p at gmail.com (Jarmo) Date: Thu, 21 Oct 2010 20:49:51 +0300 Subject: [Wtr-development] 1.6.7.rc1! Message-ID: Hello, everyone! Watir 1.6.7.rc1 got just released! === General improvements * added new waiting methods for Watir::Element: #when_present, #wait_until_present and #wait_while_present (Jari Bakken and Jarmo Pertman) * added new waiting methods for Watir::IE and Watir::Firefox: #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) * added method #present? for Watir::Element (Jari Bakken and Jarmo Pertman) * deprecated old waiting methods in Watir::Waiter which will be removed in some future version - use Watir::Wait instead (Jarmo Pertman) === IE improvements * removed Watir::Simple (?eljko Filipin) * #click_no_wait was not working with frame elements. Closes http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) === Firefox improvements * get_attribute_value now works with attributes named something like "foo-bar" (Alan Shields) === Cleanup & Maintenance * cleaned up repo at GitHub * merge licenses into one (?eljko Filipin) * Rakefile works now under non-Windows systems too (Alan Shields) * Removed datahandler.rb Install it with: gem install watir --pre And run your existing tests. If you're seeing any problems then don't forget to open a ticket at JIRA (http://jira.openqa.org/browse/WTR) or fork the project on GitHub (http://github.com/bret/watir) and send us a pull request with the fix! If you have any problems installing Watir, then read more detailed instructions at http://watir.com/installation/ Watir Development Team From bret at pettichord.com Sun Oct 24 16:00:05 2010 From: bret at pettichord.com (Bret Pettichord) Date: Sun, 24 Oct 2010 15:00:05 -0500 Subject: [Wtr-development] Version Naming Message-ID: I know there is a strong desire to make a release that drops support for several obsolete features. Makes sense, but if we do that we should call the release 1.7.0 rather than 1.6.x. It would also be great if the prior 1.6.x release included warnings for the deprecated features. Bret -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From charley.baker at gmail.com Sun Oct 24 17:39:33 2010 From: charley.baker at gmail.com (Charley Baker) Date: Sun, 24 Oct 2010 15:39:33 -0600 Subject: [Wtr-development] Version Naming In-Reply-To: References: Message-ID: Agreed. Some of the current deletions are a bit debatable, and the semantic versioning has gotten a bit lost. As a basic primer, I'd suggest we start following these rules: http://semver.org/ Charley Baker Lead Developer, Watir, http://watir.com On Sun, Oct 24, 2010 at 2:00 PM, Bret Pettichord wrote: > I know there is a strong desire to make a release that drops support for > several obsolete features. > > Makes sense, but if we do that we should call the release 1.7.0 rather than > 1.6.x. It would also be great if the prior 1.6.x release included warnings > for the deprecated features. > > Bret > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From charley.baker at gmail.com Tue Oct 26 15:37:19 2010 From: charley.baker at gmail.com (Charley Baker) Date: Tue, 26 Oct 2010 13:37:19 -0600 Subject: [Wtr-development] Watir 1.6.7 final released Message-ID: Hello, everyone! Watir 1.6.7 got just released! === General improvements * added new waiting methods for Watir::Element: #when_present, #wait_until_present and #wait_while_present (Jari Bakken and Jarmo Pertman) * added new waiting methods for Watir::IE and Watir::Firefox: #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) * added method #present? for Watir::Element (Jari Bakken and Jarmo Pertman) * deprecated old waiting methods in Watir::Waiter which will be removed in some future version - use Watir::Wait instead (Jarmo Pertman) === IE improvements * removed Watir::Simple (?eljko Filipin) * #click_no_wait was not working with frame elements. Closes http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) === Firefox improvements * get_attribute_value now works with attributes named something like "foo-bar" (Alan Shields) === Cleanup & Maintenance * cleaned up repo at GitHub * merge licenses into one (?eljko Filipin) * Rakefile works now under non-Windows systems too (Alan Shields) * Removed datahandler.rb (Charley Baker) Install it with: gem install watir And run your existing tests. If you're seeing any problems then don't forget to open a ticket at JIRA (http://jira.openqa.org/browse/WTR) or fork the project on GitHub (http://github.com/bret/watir) and send us a pull request with the fix! If you have any problems installing Watir, then read more detailed instructions at http://watir.com/installation/ Watir Development Team From jarmo.p at gmail.com Tue Oct 26 15:57:21 2010 From: jarmo.p at gmail.com (Jarmo) Date: Tue, 26 Oct 2010 22:57:21 +0300 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: It took 24 days to release new version. Woho! But i think that we could do it even better :) Agenda for the next version? Jarmo On Tue, Oct 26, 2010 at 10:37 PM, Charley Baker wrote: > Hello, everyone! > > Watir 1.6.7 got just released! > > > === General improvements > * added new waiting methods for Watir::Element: #when_present, > #wait_until_present and #wait_while_present (Jari Bakken and Jarmo > Pertman) > * added new waiting methods for Watir::IE and Watir::Firefox: > #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) > * added method #present? for Watir::Element (Jari Bakken and Jarmo > Pertman) > * deprecated old waiting methods in Watir::Waiter which will be > removed in some future version - use Watir::Wait instead (Jarmo > Pertman) > > === IE improvements > * removed Watir::Simple (?eljko Filipin) > * #click_no_wait was not working with frame elements. Closes > http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) > > === Firefox improvements > * get_attribute_value now works with attributes named something like > "foo-bar" (Alan Shields) > > === Cleanup & Maintenance > * cleaned up repo at GitHub > * merge licenses into one (?eljko Filipin) > * Rakefile works now under non-Windows systems too (Alan Shields) > * Removed datahandler.rb (Charley Baker) > > Install it with: > > gem install watir > > And run your existing tests. > > If you're seeing any problems then don't forget to open a ticket at > JIRA (http://jira.openqa.org/browse/WTR) or fork the project on GitHub > (http://github.com/bret/watir) and send us a pull request with the > fix! > If you have any problems installing Watir, then read more detailed > instructions at http://watir.com/installation/ > > Watir Development Team > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development From charley.baker at gmail.com Tue Oct 26 17:11:39 2010 From: charley.baker at gmail.com (Charley Baker) Date: Tue, 26 Oct 2010 15:11:39 -0600 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: Agreed, we can do it better, the rolling releases and getting those going has been a priority just to make sure we can step it up a bit. After so much inactivity, I feel comfortable with the overall workflow again. Let's prioritize JIRA issues and move them into this next release. If anyone would like to step up and help out, feel free to let me know. Obviously you're welcome to make pull requests, and edit JIRA at will. We should have a better idea of what's going in the next release in the next day or two. Cheers, Charley Baker Lead Developer, Watir, http://watir.com On Tue, Oct 26, 2010 at 1:57 PM, Jarmo wrote: > It took 24 days to release new version. Woho! > > But i think that we could do it even better :) > > Agenda for the next version? > > Jarmo > > On Tue, Oct 26, 2010 at 10:37 PM, Charley Baker wrote: >> Hello, everyone! >> >> Watir 1.6.7 got just released! >> >> >> === General improvements >> * added new waiting methods for Watir::Element: #when_present, >> #wait_until_present and #wait_while_present (Jari Bakken and Jarmo >> Pertman) >> * added new waiting methods for Watir::IE and Watir::Firefox: >> #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) >> * added method #present? for Watir::Element (Jari Bakken and Jarmo >> Pertman) >> * deprecated old waiting methods in Watir::Waiter which will be >> removed in some future version - use Watir::Wait instead (Jarmo >> Pertman) >> >> === IE improvements >> * removed Watir::Simple (?eljko Filipin) >> * #click_no_wait was not working with frame elements. Closes >> http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) >> >> === Firefox improvements >> * get_attribute_value now works with attributes named something like >> "foo-bar" (Alan Shields) >> >> === Cleanup & Maintenance >> * cleaned up repo at GitHub >> * merge licenses into one (?eljko Filipin) >> * Rakefile works now under non-Windows systems too (Alan Shields) >> * Removed datahandler.rb (Charley Baker) >> >> Install it with: >> >> gem install watir >> >> And run your existing tests. >> >> If you're seeing any problems then don't forget to open a ticket at >> JIRA (http://jira.openqa.org/browse/WTR) or fork the project on GitHub >> (http://github.com/bret/watir) and send us a pull request with the >> fix! >> If you have any problems installing Watir, then read more detailed >> instructions at http://watir.com/installation/ >> >> Watir Development Team >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development From bret at pettichord.com Tue Oct 26 22:53:45 2010 From: bret at pettichord.com (Bret Pettichord) Date: Tue, 26 Oct 2010 21:53:45 -0500 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: This weekend I started updating Watir so that it could be configured to use either a one or zero-based index. You turn on zero-indexing using this command: Watir.origin = 0 I am doing this work right now on a topic branch (I didn't want to interfere with the 1.6.7 release) and with your consent will merge it into master when it is complete. I have a number of tests working with the origin so far, but there are lots of hidden places where this has an effect (iterators, tables). I expect this will be done in a week or two or so. Appreciate your comments on this. Work in progress is here: http://github.com/bret/watir/commits/zero-index It seems like there is a pending interest in making a release that removes support for some deprecated features. That would need to be a 1.7.0 release -- to hold to the semantic naming, as I would like. I would like like to release the configurable-index-origin feature in a release that does not change the default. However, in a later release, I think we will want to change Watir to use a zero-based origin. Today, at the office, we were also looking at using Watir with a newer version of Ruby. We are using Ruby 1.8.6 p287 (IIRC). Not sure entirely what is holding us from using the latest version of 1.8.6 or 1.8.7. Are we still running into problems with the Win32 gems? Is anyone using Watir's showModalDialog support with a newer version of Ruby? Any way, I'd like to see if I can get this sorted out. Bret On Tue, Oct 26, 2010 at 4:11 PM, Charley Baker wrote: > Agreed, we can do it better, the rolling releases and getting those > going has been a priority just to make sure we can step it up a bit. > After so much inactivity, I feel comfortable with the overall workflow > again. > > Let's prioritize JIRA issues and move them into this next release. > If anyone would like to step up and help out, feel free to let me > know. Obviously you're welcome to make pull requests, and edit JIRA at > will. We should have a better idea of what's going in the next release > in the next day or two. > > Cheers, > > Charley Baker > Lead Developer, Watir, http://watir.com > > > > On Tue, Oct 26, 2010 at 1:57 PM, Jarmo wrote: > > It took 24 days to release new version. Woho! > > > > But i think that we could do it even better :) > > > > Agenda for the next version? > > > > Jarmo > > > > On Tue, Oct 26, 2010 at 10:37 PM, Charley Baker > wrote: > >> Hello, everyone! > >> > >> Watir 1.6.7 got just released! > >> > >> > >> === General improvements > >> * added new waiting methods for Watir::Element: #when_present, > >> #wait_until_present and #wait_while_present (Jari Bakken and Jarmo > >> Pertman) > >> * added new waiting methods for Watir::IE and Watir::Firefox: > >> #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) > >> * added method #present? for Watir::Element (Jari Bakken and Jarmo > >> Pertman) > >> * deprecated old waiting methods in Watir::Waiter which will be > >> removed in some future version - use Watir::Wait instead (Jarmo > >> Pertman) > >> > >> === IE improvements > >> * removed Watir::Simple (?eljko Filipin) > >> * #click_no_wait was not working with frame elements. Closes > >> http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) > >> > >> === Firefox improvements > >> * get_attribute_value now works with attributes named something like > >> "foo-bar" (Alan Shields) > >> > >> === Cleanup & Maintenance > >> * cleaned up repo at GitHub > >> * merge licenses into one (?eljko Filipin) > >> * Rakefile works now under non-Windows systems too (Alan Shields) > >> * Removed datahandler.rb (Charley Baker) > >> > >> Install it with: > >> > >> gem install watir > >> > >> And run your existing tests. > >> > >> If you're seeing any problems then don't forget to open a ticket at > >> JIRA (http://jira.openqa.org/browse/WTR) or fork the project on GitHub > >> (http://github.com/bret/watir) and send us a pull request with the > >> fix! > >> If you have any problems installing Watir, then read more detailed > >> instructions at http://watir.com/installation/ > >> > >> Watir Development Team > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Wed Oct 27 00:37:29 2010 From: alister.scott at gmail.com (Alister Scott) Date: Wed, 27 Oct 2010 14:37:29 +1000 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: <-8538714755930776086@unknownmsgid> Great news and great work Bret. The zero based index will be excellent as it will enable full compatibility with watir-webdriver. Cheers, Alister. On 27/10/2010, at 2:32 PM, Bret Pettichord wrote: This weekend I started updating Watir so that it could be configured to use either a one or zero-based index. You turn on zero-indexing using this command: Watir.origin = 0 I am doing this work right now on a topic branch (I didn't want to interfere with the 1.6.7 release) and with your consent will merge it into master when it is complete. I have a number of tests working with the origin so far, but there are lots of hidden places where this has an effect (iterators, tables). I expect this will be done in a week or two or so. Appreciate your comments on this. Work in progress is here: http://github.com/bret/watir/commits/zero-index It seems like there is a pending interest in making a release that removes support for some deprecated features. That would need to be a 1.7.0 release -- to hold to the semantic naming, as I would like. I would like like to release the configurable-index-origin feature in a release that does not change the default. However, in a later release, I think we will want to change Watir to use a zero-based origin. Today, at the office, we were also looking at using Watir with a newer version of Ruby. We are using Ruby 1.8.6 p287 (IIRC). Not sure entirely what is holding us from using the latest version of 1.8.6 or 1.8.7. Are we still running into problems with the Win32 gems? Is anyone using Watir's showModalDialog support with a newer version of Ruby? Any way, I'd like to see if I can get this sorted out. Bret On Tue, Oct 26, 2010 at 4:11 PM, Charley Baker wrote: > Agreed, we can do it better, the rolling releases and getting those > going has been a priority just to make sure we can step it up a bit. > After so much inactivity, I feel comfortable with the overall workflow > again. > > Let's prioritize JIRA issues and move them into this next release. > If anyone would like to step up and help out, feel free to let me > know. Obviously you're welcome to make pull requests, and edit JIRA at > will. We should have a better idea of what's going in the next release > in the next day or two. > > Cheers, > > Charley Baker > Lead Developer, Watir, http://watir.com > > > > On Tue, Oct 26, 2010 at 1:57 PM, Jarmo wrote: > > It took 24 days to release new version. Woho! > > > > But i think that we could do it even better :) > > > > Agenda for the next version? > > > > Jarmo > > > > On Tue, Oct 26, 2010 at 10:37 PM, Charley Baker > wrote: > >> Hello, everyone! > >> > >> Watir 1.6.7 got just released! > >> > >> > >> === General improvements > >> * added new waiting methods for Watir::Element: #when_present, > >> #wait_until_present and #wait_while_present (Jari Bakken and Jarmo > >> Pertman) > >> * added new waiting methods for Watir::IE and Watir::Firefox: > >> #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) > >> * added method #present? for Watir::Element (Jari Bakken and Jarmo > >> Pertman) > >> * deprecated old waiting methods in Watir::Waiter which will be > >> removed in some future version - use Watir::Wait instead (Jarmo > >> Pertman) > >> > >> === IE improvements > >> * removed Watir::Simple (?eljko Filipin) > >> * #click_no_wait was not working with frame elements. Closes > >> http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) > >> > >> === Firefox improvements > >> * get_attribute_value now works with attributes named something like > >> "foo-bar" (Alan Shields) > >> > >> === Cleanup & Maintenance > >> * cleaned up repo at GitHub > >> * merge licenses into one (?eljko Filipin) > >> * Rakefile works now under non-Windows systems too (Alan Shields) > >> * Removed datahandler.rb (Charley Baker) > >> > >> Install it with: > >> > >> gem install watir > >> > >> And run your existing tests. > >> > >> If you're seeing any problems then don't forget to open a ticket at > >> JIRA (http://jira.openqa.org/browse/WTR) or fork the project on GitHub > >> (http://github.com/bret/watir) and send us a pull request with the > >> fix! > >> If you have any problems installing Watir, then read more detailed > >> instructions at http://watir.com/installation/ > >> > >> Watir Development Team > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord _______________________________________________ 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 Wed Oct 27 03:50:32 2010 From: jarmo.p at gmail.com (Jarmo) Date: Wed, 27 Oct 2010 10:50:32 +0300 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: I'd change #origin to something more explanatory... Since it will be more or less a temporary option since there is plan to make 0 to default in the future then we could have some better explanatory name. Also, why not just make it a boolean? I don't think that someone likes to set it to something else than 0 or 1... so I'd suggest something in the lines of: Watir.use_zero_based_indexing = true Jarmo 2010/10/27 Bret Pettichord : > This weekend I started updating Watir so that it could be configured to use > either a one or zero-based index. You turn on zero-indexing using this > command: > > ?? Watir.origin = 0 > > I am doing this work right now on a topic branch (I didn't want to interfere > with the 1.6.7 release) and with your consent will merge it into master when > it is complete. > > I have a number of tests working with the origin so far, but there are lots > of hidden places where this has an effect (iterators, tables). I expect this > will be done in a week or two or so. > > Appreciate your comments on this. Work in progress is here: > > http://github.com/bret/watir/commits/zero-index > > > It seems like there is a pending interest in making a release that removes > support for some deprecated features. That would need to be a 1.7.0 release > -- to hold to the semantic naming, as I would like. > > I would like like to release the configurable-index-origin feature in a > release that does not change the default. However, in a later release, I > think we will want to change Watir to use a zero-based origin. > > > Today, at the office, we were also looking at using Watir with a newer > version of Ruby. We are using Ruby 1.8.6 p287 (IIRC). Not sure entirely what > is holding us from using the latest version of 1.8.6 or 1.8.7. Are we still > running into problems with the Win32 gems? Is anyone using Watir's > showModalDialog support with a newer version of Ruby? Any way, I'd like to > see if I can get this sorted out. > > > Bret > > > On Tue, Oct 26, 2010 at 4:11 PM, Charley Baker > wrote: >> >> Agreed, we can do it better, the rolling releases and getting those >> going has been a priority just to make sure we can step it up a bit. >> After so much inactivity, I feel comfortable with the overall workflow >> again. >> >> ?Let's prioritize JIRA issues and move them into this next release. >> If anyone would like to step up and help out, feel free to let me >> know. Obviously you're welcome to make pull requests, and edit JIRA at >> will. We should have a better idea of what's going in the next release >> in the next day or two. >> >> Cheers, >> >> Charley Baker >> Lead Developer, Watir, http://watir.com >> >> >> >> On Tue, Oct 26, 2010 at 1:57 PM, Jarmo wrote: >> > It took 24 days to release new version. Woho! >> > >> > But i think that we could do it even better :) >> > >> > Agenda for the next version? >> > >> > Jarmo >> > >> > On Tue, Oct 26, 2010 at 10:37 PM, Charley Baker >> > wrote: >> >> Hello, everyone! >> >> >> >> Watir 1.6.7 got just released! >> >> >> >> >> >> === General improvements >> >> * added new waiting methods for Watir::Element: #when_present, >> >> #wait_until_present and #wait_while_present (Jari Bakken and Jarmo >> >> Pertman) >> >> * added new waiting methods for Watir::IE and Watir::Firefox: >> >> #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) >> >> * added method #present? for Watir::Element (Jari Bakken and Jarmo >> >> Pertman) >> >> * deprecated old waiting methods in Watir::Waiter which will be >> >> removed in some future version - use Watir::Wait instead (Jarmo >> >> Pertman) >> >> >> >> === IE improvements >> >> * removed Watir::Simple (?eljko Filipin) >> >> * #click_no_wait was not working with frame elements. Closes >> >> http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) >> >> >> >> === Firefox improvements >> >> * get_attribute_value now works with attributes named something like >> >> "foo-bar" (Alan Shields) >> >> >> >> === Cleanup & Maintenance >> >> * cleaned up repo at GitHub >> >> * merge licenses into one (?eljko Filipin) >> >> * Rakefile works now under non-Windows systems too (Alan Shields) >> >> * Removed datahandler.rb (Charley Baker) >> >> >> >> Install it with: >> >> >> >> gem install watir >> >> >> >> And run your existing tests. >> >> >> >> If you're seeing any problems then don't forget to open a ticket at >> >> JIRA (http://jira.openqa.org/browse/WTR) or fork the project on GitHub >> >> (http://github.com/bret/watir) and send us a pull request with the >> >> fix! >> >> If you have any problems installing Watir, then read more detailed >> >> instructions at http://watir.com/installation/ >> >> >> >> Watir Development Team >> >> _______________________________________________ >> >> Wtr-development mailing list >> >> Wtr-development at rubyforge.org >> >> http://rubyforge.org/mailman/listinfo/wtr-development >> > _______________________________________________ >> > Wtr-development mailing list >> > Wtr-development at rubyforge.org >> > http://rubyforge.org/mailman/listinfo/wtr-development >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From jarmo.p at gmail.com Wed Oct 27 05:17:03 2010 From: jarmo.p at gmail.com (Jarmo) Date: Wed, 27 Oct 2010 12:17:03 +0300 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: One of the goals for next version could be the removal of activesupport dependency. Charley, you started with it, can you finish that task? Currently, when people want to use ActiveRecord 3.x with Watir tests then they can't (http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/77180dd0f5c58906?hl=en) Jarmo On Wed, Oct 27, 2010 at 12:11 AM, Charley Baker wrote: > Agreed, we can do it better, the rolling releases and getting those > going has been a priority just to make sure we can step it up a bit. > After so much inactivity, I feel comfortable with the overall workflow > again. > > ?Let's prioritize JIRA issues and move them into this next release. > If anyone would like to step up and help out, feel free to let me > know. Obviously you're welcome to make pull requests, and edit JIRA at > will. We should have a better idea of what's going in the next release > in the next day or two. > > Cheers, > > Charley Baker > Lead Developer, Watir, http://watir.com > > > > On Tue, Oct 26, 2010 at 1:57 PM, Jarmo wrote: >> It took 24 days to release new version. Woho! >> >> But i think that we could do it even better :) >> >> Agenda for the next version? >> >> Jarmo >> >> On Tue, Oct 26, 2010 at 10:37 PM, Charley Baker wrote: >>> Hello, everyone! >>> >>> Watir 1.6.7 got just released! >>> >>> >>> === General improvements >>> * added new waiting methods for Watir::Element: #when_present, >>> #wait_until_present and #wait_while_present (Jari Bakken and Jarmo >>> Pertman) >>> * added new waiting methods for Watir::IE and Watir::Firefox: >>> #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) >>> * added method #present? for Watir::Element (Jari Bakken and Jarmo >>> Pertman) >>> * deprecated old waiting methods in Watir::Waiter which will be >>> removed in some future version - use Watir::Wait instead (Jarmo >>> Pertman) >>> >>> === IE improvements >>> * removed Watir::Simple (?eljko Filipin) >>> * #click_no_wait was not working with frame elements. Closes >>> http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) >>> >>> === Firefox improvements >>> * get_attribute_value now works with attributes named something like >>> "foo-bar" (Alan Shields) >>> >>> === Cleanup & Maintenance >>> * cleaned up repo at GitHub >>> * merge licenses into one (?eljko Filipin) >>> * Rakefile works now under non-Windows systems too (Alan Shields) >>> * Removed datahandler.rb (Charley Baker) >>> >>> Install it with: >>> >>> gem install watir >>> >>> And run your existing tests. >>> >>> If you're seeing any problems then don't forget to open a ticket at >>> JIRA (http://jira.openqa.org/browse/WTR) or fork the project on GitHub >>> (http://github.com/bret/watir) and send us a pull request with the >>> fix! >>> If you have any problems installing Watir, then read more detailed >>> instructions at http://watir.com/installation/ >>> >>> Watir Development Team >>> _______________________________________________ >>> 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 From watirjira at gmail.com Wed Oct 27 07:44:19 2010 From: watirjira at gmail.com (=?UTF-8?Q?Stephan_K=C3=A4mper_=28JIRA=29?=) Date: Wed, 27 Oct 2010 06:44:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Created: (WTR-461) Typo in README.rdoc, mismatch with example code Message-ID: <22972864.242.1288179859977.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Typo in README.rdoc, mismatch with example code ------------------------------------------------ Key: WTR-461 URL: http://jira.openqa.org/browse/WTR-461 Project: Watir Issue Type: Bug Components: Documentation Affects Versions: 1.6.6 Environment: Any Reporter: Stephan K?mper The README.rdoc (http://github.com/bret/watir/blob/master/README.rdoc) says: Actual text: > Setting and clearing a radio button > > browser.radio(:value => "watir").set > browser.radio(:value => "watir".clear Closing parenthesis is missing, should be > browser.radio(:value => "watir").clear Additionally the example page (http://bit.ly/watir-example) as given in the code/README actually is: ...
  • ... This uses 'Watir' while the example code is 'watir' which in turn raises an exception: > ... > Watir::Exception::UnknownObjectException: Unable to locate element, using {:value=>"watir"} -- 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 Oct 27 10:03:08 2010 From: notethan at gmail.com (Ethan) Date: Wed, 27 Oct 2010 10:03:08 -0400 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: I agree that 'origin' is not an informative name, and could mean any multitude of things. I'd go with base_index; jarib uses index_offset in celerity. On Wed, Oct 27, 2010 at 03:50, Jarmo wrote: > I'd change #origin to something more explanatory... Since it will be > more or less a temporary option since there is plan to make 0 to > default in the future then we could have some better explanatory name. > Also, why not just make it a boolean? I don't think that someone likes > to set it to something else than 0 or 1... so I'd suggest something in > the lines of: > Watir.use_zero_based_indexing = true > > Jarmo > > 2010/10/27 Bret Pettichord : > > This weekend I started updating Watir so that it could be configured to > use > > either a one or zero-based index. You turn on zero-indexing using this > > command: > > > > Watir.origin = 0 > > > > I am doing this work right now on a topic branch (I didn't want to > interfere > > with the 1.6.7 release) and with your consent will merge it into master > when > > it is complete. > > > > I have a number of tests working with the origin so far, but there are > lots > > of hidden places where this has an effect (iterators, tables). I expect > this > > will be done in a week or two or so. > > > > Appreciate your comments on this. Work in progress is here: > > > > http://github.com/bret/watir/commits/zero-index > > > > > > It seems like there is a pending interest in making a release that > removes > > support for some deprecated features. That would need to be a 1.7.0 > release > > -- to hold to the semantic naming, as I would like. > > > > I would like like to release the configurable-index-origin feature in a > > release that does not change the default. However, in a later release, I > > think we will want to change Watir to use a zero-based origin. > > > > > > Today, at the office, we were also looking at using Watir with a newer > > version of Ruby. We are using Ruby 1.8.6 p287 (IIRC). Not sure entirely > what > > is holding us from using the latest version of 1.8.6 or 1.8.7. Are we > still > > running into problems with the Win32 gems? Is anyone using Watir's > > showModalDialog support with a newer version of Ruby? Any way, I'd like > to > > see if I can get this sorted out. > > > > > > Bret > > > > > > On Tue, Oct 26, 2010 at 4:11 PM, Charley Baker > > wrote: > >> > >> Agreed, we can do it better, the rolling releases and getting those > >> going has been a priority just to make sure we can step it up a bit. > >> After so much inactivity, I feel comfortable with the overall workflow > >> again. > >> > >> Let's prioritize JIRA issues and move them into this next release. > >> If anyone would like to step up and help out, feel free to let me > >> know. Obviously you're welcome to make pull requests, and edit JIRA at > >> will. We should have a better idea of what's going in the next release > >> in the next day or two. > >> > >> Cheers, > >> > >> Charley Baker > >> Lead Developer, Watir, http://watir.com > >> > >> > >> > >> On Tue, Oct 26, 2010 at 1:57 PM, Jarmo wrote: > >> > It took 24 days to release new version. Woho! > >> > > >> > But i think that we could do it even better :) > >> > > >> > Agenda for the next version? > >> > > >> > Jarmo > >> > > >> > On Tue, Oct 26, 2010 at 10:37 PM, Charley Baker > >> > wrote: > >> >> Hello, everyone! > >> >> > >> >> Watir 1.6.7 got just released! > >> >> > >> >> > >> >> === General improvements > >> >> * added new waiting methods for Watir::Element: #when_present, > >> >> #wait_until_present and #wait_while_present (Jari Bakken and Jarmo > >> >> Pertman) > >> >> * added new waiting methods for Watir::IE and Watir::Firefox: > >> >> #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) > >> >> * added method #present? for Watir::Element (Jari Bakken and Jarmo > >> >> Pertman) > >> >> * deprecated old waiting methods in Watir::Waiter which will be > >> >> removed in some future version - use Watir::Wait instead (Jarmo > >> >> Pertman) > >> >> > >> >> === IE improvements > >> >> * removed Watir::Simple (?eljko Filipin) > >> >> * #click_no_wait was not working with frame elements. Closes > >> >> http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) > >> >> > >> >> === Firefox improvements > >> >> * get_attribute_value now works with attributes named something like > >> >> "foo-bar" (Alan Shields) > >> >> > >> >> === Cleanup & Maintenance > >> >> * cleaned up repo at GitHub > >> >> * merge licenses into one (?eljko Filipin) > >> >> * Rakefile works now under non-Windows systems too (Alan Shields) > >> >> * Removed datahandler.rb (Charley Baker) > >> >> > >> >> Install it with: > >> >> > >> >> gem install watir > >> >> > >> >> And run your existing tests. > >> >> > >> >> If you're seeing any problems then don't forget to open a ticket at > >> >> JIRA (http://jira.openqa.org/browse/WTR) or fork the project on > GitHub > >> >> (http://github.com/bret/watir) and send us a pull request with the > >> >> fix! > >> >> If you have any problems installing Watir, then read more detailed > >> >> instructions at http://watir.com/installation/ > >> >> > >> >> Watir Development Team > >> >> _______________________________________________ > >> >> Wtr-development mailing list > >> >> Wtr-development at rubyforge.org > >> >> http://rubyforge.org/mailman/listinfo/wtr-development > >> > _______________________________________________ > >> > Wtr-development mailing list > >> > Wtr-development at rubyforge.org > >> > http://rubyforge.org/mailman/listinfo/wtr-development > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > > > -- > > Bret Pettichord > > Lead Developer, Watir, www.watir.com > > > > Blog, www.io.com/~wazmo/blog > > Twitter, www.twitter.com/bpettichord > > > > > > _______________________________________________ > > 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 charley.baker at gmail.com Wed Oct 27 10:16:53 2010 From: charley.baker at gmail.com (Charley Baker) Date: Wed, 27 Oct 2010 08:16:53 -0600 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: Bret, That's excellent, as Alister mentioned, that's a great transition point to watir-webdriver. I've been using the latest 1.8.6.p111, p287 and the latest along with the latest version of 1.8.7 all managed by pik. [1] I think the only thing holding back from fully recommending the latest of these is showModalDialog, otherwise everything else appears to work fine. There are at least two things I want to take a look at for the next release - removing the ActiveSupport dependency and seeing if there is a different way of getting the IE showModalDialogs without having to use our custom version of win32ole.so. Also there are a lot of open issues, which we need to go through. Volunteers are welcome. :) [1]: http://github.com/vertiginous/pik Charley Baker Lead Developer, Watir, http://watir.com On Wed, Oct 27, 2010 at 3:17 AM, Jarmo wrote: > One of the goals for next version could be the removal of > activesupport dependency. Charley, you started with it, can you finish > that task? > > Currently, when people want to use ActiveRecord 3.x with Watir tests > then they can't > (http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/77180dd0f5c58906?hl=en) > > Jarmo > > On Wed, Oct 27, 2010 at 12:11 AM, Charley Baker wrote: >> Agreed, we can do it better, the rolling releases and getting those >> going has been a priority just to make sure we can step it up a bit. >> After so much inactivity, I feel comfortable with the overall workflow >> again. >> >> ?Let's prioritize JIRA issues and move them into this next release. >> If anyone would like to step up and help out, feel free to let me >> know. Obviously you're welcome to make pull requests, and edit JIRA at >> will. We should have a better idea of what's going in the next release >> in the next day or two. >> >> Cheers, >> >> Charley Baker >> Lead Developer, Watir, http://watir.com >> >> >> >> On Tue, Oct 26, 2010 at 1:57 PM, Jarmo wrote: >>> It took 24 days to release new version. Woho! >>> >>> But i think that we could do it even better :) >>> >>> Agenda for the next version? >>> >>> Jarmo >>> >>> On Tue, Oct 26, 2010 at 10:37 PM, Charley Baker wrote: >>>> Hello, everyone! >>>> >>>> Watir 1.6.7 got just released! >>>> >>>> >>>> === General improvements >>>> * added new waiting methods for Watir::Element: #when_present, >>>> #wait_until_present and #wait_while_present (Jari Bakken and Jarmo >>>> Pertman) >>>> * added new waiting methods for Watir::IE and Watir::Firefox: >>>> #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) >>>> * added method #present? for Watir::Element (Jari Bakken and Jarmo >>>> Pertman) >>>> * deprecated old waiting methods in Watir::Waiter which will be >>>> removed in some future version - use Watir::Wait instead (Jarmo >>>> Pertman) >>>> >>>> === IE improvements >>>> * removed Watir::Simple (?eljko Filipin) >>>> * #click_no_wait was not working with frame elements. Closes >>>> http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) >>>> >>>> === Firefox improvements >>>> * get_attribute_value now works with attributes named something like >>>> "foo-bar" (Alan Shields) >>>> >>>> === Cleanup & Maintenance >>>> * cleaned up repo at GitHub >>>> * merge licenses into one (?eljko Filipin) >>>> * Rakefile works now under non-Windows systems too (Alan Shields) >>>> * Removed datahandler.rb (Charley Baker) >>>> >>>> Install it with: >>>> >>>> gem install watir >>>> >>>> And run your existing tests. >>>> >>>> If you're seeing any problems then don't forget to open a ticket at >>>> JIRA (http://jira.openqa.org/browse/WTR) or fork the project on GitHub >>>> (http://github.com/bret/watir) and send us a pull request with the >>>> fix! >>>> If you have any problems installing Watir, then read more detailed >>>> instructions at http://watir.com/installation/ >>>> >>>> Watir Development Team >>>> _______________________________________________ >>>> Wtr-development mailing list >>>> Wtr-development at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/wtr-development >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development From bret at pettichord.com Wed Oct 27 10:53:29 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 27 Oct 2010 09:53:29 -0500 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: I think that it is easier to understand if the values are 0 and 1, than true and false. I'm happy to put a guard on it to prevent it from being set to other values. Is this easier to understand? Watir.indexing_origin = 0 I'm also finding the ability to use Watir.origin in the tests to be quite handy and suspect that I'll use the same technique in our test suite as we prepare to convert, which will not be trivial. This really begs to be noun. And Watir.index_base seems to me to be even more obscure. But maybe that's just me? Bret On Wed, Oct 27, 2010 at 2:50 AM, Jarmo wrote: > I'd change #origin to something more explanatory... Since it will be > more or less a temporary option since there is plan to make 0 to > default in the future then we could have some better explanatory name. > Also, why not just make it a boolean? I don't think that someone likes > to set it to something else than 0 or 1... so I'd suggest something in > the lines of: > Watir.use_zero_based_indexing = true > > Jarmo > > 2010/10/27 Bret Pettichord : > > This weekend I started updating Watir so that it could be configured to > use > > either a one or zero-based index. You turn on zero-indexing using this > > command: > > > > Watir.origin = 0 > > > > I am doing this work right now on a topic branch (I didn't want to > interfere > > with the 1.6.7 release) and with your consent will merge it into master > when > > it is complete. > > > > I have a number of tests working with the origin so far, but there are > lots > > of hidden places where this has an effect (iterators, tables). I expect > this > > will be done in a week or two or so. > > > > Appreciate your comments on this. Work in progress is here: > > > > http://github.com/bret/watir/commits/zero-index > > > > > > It seems like there is a pending interest in making a release that > removes > > support for some deprecated features. That would need to be a 1.7.0 > release > > -- to hold to the semantic naming, as I would like. > > > > I would like like to release the configurable-index-origin feature in a > > release that does not change the default. However, in a later release, I > > think we will want to change Watir to use a zero-based origin. > > > > > > Today, at the office, we were also looking at using Watir with a newer > > version of Ruby. We are using Ruby 1.8.6 p287 (IIRC). Not sure entirely > what > > is holding us from using the latest version of 1.8.6 or 1.8.7. Are we > still > > running into problems with the Win32 gems? Is anyone using Watir's > > showModalDialog support with a newer version of Ruby? Any way, I'd like > to > > see if I can get this sorted out. > > > > > > Bret > > > > > > On Tue, Oct 26, 2010 at 4:11 PM, Charley Baker > > wrote: > >> > >> Agreed, we can do it better, the rolling releases and getting those > >> going has been a priority just to make sure we can step it up a bit. > >> After so much inactivity, I feel comfortable with the overall workflow > >> again. > >> > >> Let's prioritize JIRA issues and move them into this next release. > >> If anyone would like to step up and help out, feel free to let me > >> know. Obviously you're welcome to make pull requests, and edit JIRA at > >> will. We should have a better idea of what's going in the next release > >> in the next day or two. > >> > >> Cheers, > >> > >> Charley Baker > >> Lead Developer, Watir, http://watir.com > >> > >> > >> > >> On Tue, Oct 26, 2010 at 1:57 PM, Jarmo wrote: > >> > It took 24 days to release new version. Woho! > >> > > >> > But i think that we could do it even better :) > >> > > >> > Agenda for the next version? > >> > > >> > Jarmo > >> > > >> > On Tue, Oct 26, 2010 at 10:37 PM, Charley Baker > >> > wrote: > >> >> Hello, everyone! > >> >> > >> >> Watir 1.6.7 got just released! > >> >> > >> >> > >> >> === General improvements > >> >> * added new waiting methods for Watir::Element: #when_present, > >> >> #wait_until_present and #wait_while_present (Jari Bakken and Jarmo > >> >> Pertman) > >> >> * added new waiting methods for Watir::IE and Watir::Firefox: > >> >> #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) > >> >> * added method #present? for Watir::Element (Jari Bakken and Jarmo > >> >> Pertman) > >> >> * deprecated old waiting methods in Watir::Waiter which will be > >> >> removed in some future version - use Watir::Wait instead (Jarmo > >> >> Pertman) > >> >> > >> >> === IE improvements > >> >> * removed Watir::Simple (?eljko Filipin) > >> >> * #click_no_wait was not working with frame elements. Closes > >> >> http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) > >> >> > >> >> === Firefox improvements > >> >> * get_attribute_value now works with attributes named something like > >> >> "foo-bar" (Alan Shields) > >> >> > >> >> === Cleanup & Maintenance > >> >> * cleaned up repo at GitHub > >> >> * merge licenses into one (?eljko Filipin) > >> >> * Rakefile works now under non-Windows systems too (Alan Shields) > >> >> * Removed datahandler.rb (Charley Baker) > >> >> > >> >> Install it with: > >> >> > >> >> gem install watir > >> >> > >> >> And run your existing tests. > >> >> > >> >> If you're seeing any problems then don't forget to open a ticket at > >> >> JIRA (http://jira.openqa.org/browse/WTR) or fork the project on > GitHub > >> >> (http://github.com/bret/watir) and send us a pull request with the > >> >> fix! > >> >> If you have any problems installing Watir, then read more detailed > >> >> instructions at http://watir.com/installation/ > >> >> > >> >> Watir Development Team > >> >> _______________________________________________ > >> >> Wtr-development mailing list > >> >> Wtr-development at rubyforge.org > >> >> http://rubyforge.org/mailman/listinfo/wtr-development > >> > _______________________________________________ > >> > Wtr-development mailing list > >> > Wtr-development at rubyforge.org > >> > http://rubyforge.org/mailman/listinfo/wtr-development > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > > > -- > > Bret Pettichord > > Lead Developer, Watir, www.watir.com > > > > Blog, www.io.com/~wazmo/blog > > Twitter, www.twitter.com/bpettichord > > > > > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Wed Oct 27 10:54:21 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 27 Oct 2010 09:54:21 -0500 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: Yes it would be great to finish this work. A couple of years ago I was adding active support dependencies to all my projects. Now I'm pulling them all out. Bret On Wed, Oct 27, 2010 at 4:17 AM, Jarmo wrote: > One of the goals for next version could be the removal of > activesupport dependency. Charley, you started with it, can you finish > that task? > > Currently, when people want to use ActiveRecord 3.x with Watir tests > then they can't > ( > http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/77180dd0f5c58906?hl=en > ) > > Jarmo > > On Wed, Oct 27, 2010 at 12:11 AM, Charley Baker > wrote: > > Agreed, we can do it better, the rolling releases and getting those > > going has been a priority just to make sure we can step it up a bit. > > After so much inactivity, I feel comfortable with the overall workflow > > again. > > > > Let's prioritize JIRA issues and move them into this next release. > > If anyone would like to step up and help out, feel free to let me > > know. Obviously you're welcome to make pull requests, and edit JIRA at > > will. We should have a better idea of what's going in the next release > > in the next day or two. > > > > Cheers, > > > > Charley Baker > > Lead Developer, Watir, http://watir.com > > > > > > > > On Tue, Oct 26, 2010 at 1:57 PM, Jarmo wrote: > >> It took 24 days to release new version. Woho! > >> > >> But i think that we could do it even better :) > >> > >> Agenda for the next version? > >> > >> Jarmo > >> > >> On Tue, Oct 26, 2010 at 10:37 PM, Charley Baker < > charley.baker at gmail.com> wrote: > >>> Hello, everyone! > >>> > >>> Watir 1.6.7 got just released! > >>> > >>> > >>> === General improvements > >>> * added new waiting methods for Watir::Element: #when_present, > >>> #wait_until_present and #wait_while_present (Jari Bakken and Jarmo > >>> Pertman) > >>> * added new waiting methods for Watir::IE and Watir::Firefox: > >>> #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) > >>> * added method #present? for Watir::Element (Jari Bakken and Jarmo > >>> Pertman) > >>> * deprecated old waiting methods in Watir::Waiter which will be > >>> removed in some future version - use Watir::Wait instead (Jarmo > >>> Pertman) > >>> > >>> === IE improvements > >>> * removed Watir::Simple (?eljko Filipin) > >>> * #click_no_wait was not working with frame elements. Closes > >>> http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) > >>> > >>> === Firefox improvements > >>> * get_attribute_value now works with attributes named something like > >>> "foo-bar" (Alan Shields) > >>> > >>> === Cleanup & Maintenance > >>> * cleaned up repo at GitHub > >>> * merge licenses into one (?eljko Filipin) > >>> * Rakefile works now under non-Windows systems too (Alan Shields) > >>> * Removed datahandler.rb (Charley Baker) > >>> > >>> Install it with: > >>> > >>> gem install watir > >>> > >>> And run your existing tests. > >>> > >>> If you're seeing any problems then don't forget to open a ticket at > >>> JIRA (http://jira.openqa.org/browse/WTR) or fork the project on GitHub > >>> (http://github.com/bret/watir) and send us a pull request with the > >>> fix! > >>> If you have any problems installing Watir, then read more detailed > >>> instructions at http://watir.com/installation/ > >>> > >>> Watir Development Team > >>> _______________________________________________ > >>> Wtr-development mailing list > >>> Wtr-development at rubyforge.org > >>> http://rubyforge.org/mailman/listinfo/wtr-development > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Wed Oct 27 10:55:19 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 27 Oct 2010 09:55:19 -0500 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: <-8538714755930776086@unknownmsgid> References: <-8538714755930776086@unknownmsgid> Message-ID: Yes that is my main motivation. What else do we need to do to achieve compatability with webdriver? Bret On Tue, Oct 26, 2010 at 11:37 PM, Alister Scott wrote: > Great news and great work Bret. > The zero based index will be excellent as it will enable full compatibility > with watir-webdriver. > > Cheers, Alister. > > > On 27/10/2010, at 2:32 PM, Bret Pettichord wrote: > > This weekend I started updating Watir so that it could be configured to use > either a one or zero-based index. You turn on zero-indexing using this > command: > > Watir.origin = 0 > > I am doing this work right now on a topic branch (I didn't want to > interfere with the 1.6.7 release) and with your consent will merge it into > master when it is complete. > > I have a number of tests working with the origin so far, but there are lots > of hidden places where this has an effect (iterators, tables). I expect this > will be done in a week or two or so. > > Appreciate your comments on this. Work in progress is here: > > > http://github.com/bret/watir/commits/zero-index > > > It seems like there is a pending interest in making a release that removes > support for some deprecated features. That would need to be a 1.7.0 release > -- to hold to the semantic naming, as I would like. > > I would like like to release the configurable-index-origin feature in a > release that does not change the default. However, in a later release, I > think we will want to change Watir to use a zero-based origin. > > > Today, at the office, we were also looking at using Watir with a newer > version of Ruby. We are using Ruby 1.8.6 p287 (IIRC). Not sure entirely what > is holding us from using the latest version of 1.8.6 or 1.8.7. Are we still > running into problems with the Win32 gems? Is anyone using Watir's > showModalDialog support with a newer version of Ruby? Any way, I'd like to > see if I can get this sorted out. > > > Bret > > > On Tue, Oct 26, 2010 at 4:11 PM, Charley Baker < > charley.baker at gmail.com> wrote: > >> Agreed, we can do it better, the rolling releases and getting those >> going has been a priority just to make sure we can step it up a bit. >> After so much inactivity, I feel comfortable with the overall workflow >> again. >> >> Let's prioritize JIRA issues and move them into this next release. >> If anyone would like to step up and help out, feel free to let me >> know. Obviously you're welcome to make pull requests, and edit JIRA at >> will. We should have a better idea of what's going in the next release >> in the next day or two. >> >> Cheers, >> >> Charley Baker >> Lead Developer, Watir, http://watir.com >> >> >> >> On Tue, Oct 26, 2010 at 1:57 PM, Jarmo < >> jarmo.p at gmail.com> wrote: >> > It took 24 days to release new version. Woho! >> > >> > But i think that we could do it even better :) >> > >> > Agenda for the next version? >> > >> > Jarmo >> > >> > On Tue, Oct 26, 2010 at 10:37 PM, Charley Baker < >> charley.baker at gmail.com> wrote: >> >> Hello, everyone! >> >> >> >> Watir 1.6.7 got just released! >> >> >> >> >> >> === General improvements >> >> * added new waiting methods for Watir::Element: #when_present, >> >> #wait_until_present and #wait_while_present (Jari Bakken and Jarmo >> >> Pertman) >> >> * added new waiting methods for Watir::IE and Watir::Firefox: >> >> #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) >> >> * added method #present? for Watir::Element (Jari Bakken and Jarmo >> >> Pertman) >> >> * deprecated old waiting methods in Watir::Waiter which will be >> >> removed in some future version - use Watir::Wait instead (Jarmo >> >> Pertman) >> >> >> >> === IE improvements >> >> * removed Watir::Simple (?eljko Filipin) >> >> * #click_no_wait was not working with frame elements. Closes >> >> >> http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) >> >> >> >> === Firefox improvements >> >> * get_attribute_value now works with attributes named something like >> >> "foo-bar" (Alan Shields) >> >> >> >> === Cleanup & Maintenance >> >> * cleaned up repo at GitHub >> >> * merge licenses into one (?eljko Filipin) >> >> * Rakefile works now under non-Windows systems too (Alan Shields) >> >> * Removed datahandler.rb (Charley Baker) >> >> >> >> Install it with: >> >> >> >> gem install watir >> >> >> >> And run your existing tests. >> >> >> >> If you're seeing any problems then don't forget to open a ticket at >> >> JIRA ( >> http://jira.openqa.org/browse/WTR) or fork the project on GitHub >> >> ( http://github.com/bret/watir) and send >> us a pull request with the >> >> fix! >> >> If you have any problems installing Watir, then read more detailed >> >> instructions at >> http://watir.com/installation/ >> >> >> >> Watir Development Team >> >> _______________________________________________ >> >> Wtr-development mailing list >> >> Wtr-development at rubyforge.org >> >> >> http://rubyforge.org/mailman/listinfo/wtr-development >> > _______________________________________________ >> > Wtr-development mailing list >> > Wtr-development at rubyforge.org >> > >> http://rubyforge.org/mailman/listinfo/wtr-development >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From notethan at gmail.com Wed Oct 27 11:50:01 2010 From: notethan at gmail.com (Ethan) Date: Wed, 27 Oct 2010 11:50:01 -0400 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: base_index, index_offset, indexing_origin - whatever. I think this is one of those cases where any of them is perfectly fine, but consistency among things implementing the watir API is most valuable. since jarib went with index_offset in one place already, that seems like as good a choice as any of the others to me, and gets my vote. On Wed, Oct 27, 2010 at 10:53, Bret Pettichord wrote: > I think that it is easier to understand if the values are 0 and 1, than > true and false. I'm happy to put a guard on it to prevent it from being set > to other values. > > Is this easier to understand? > > Watir.indexing_origin = 0 > > I'm also finding the ability to use Watir.origin in the tests to be quite > handy and suspect that I'll use the same technique in our test suite as we > prepare to convert, which will not be trivial. This really begs to be noun. > And Watir.index_base seems to me to be even more obscure. But maybe that's > just me? > > Bret > > > > On Wed, Oct 27, 2010 at 2:50 AM, Jarmo wrote: > >> I'd change #origin to something more explanatory... Since it will be >> more or less a temporary option since there is plan to make 0 to >> default in the future then we could have some better explanatory name. >> Also, why not just make it a boolean? I don't think that someone likes >> to set it to something else than 0 or 1... so I'd suggest something in >> the lines of: >> Watir.use_zero_based_indexing = true >> >> Jarmo >> >> 2010/10/27 Bret Pettichord : >> > This weekend I started updating Watir so that it could be configured to >> use >> > either a one or zero-based index. You turn on zero-indexing using this >> > command: >> > >> > Watir.origin = 0 >> > >> > I am doing this work right now on a topic branch (I didn't want to >> interfere >> > with the 1.6.7 release) and with your consent will merge it into master >> when >> > it is complete. >> > >> > I have a number of tests working with the origin so far, but there are >> lots >> > of hidden places where this has an effect (iterators, tables). I expect >> this >> > will be done in a week or two or so. >> > >> > Appreciate your comments on this. Work in progress is here: >> > >> > http://github.com/bret/watir/commits/zero-index >> > >> > >> > It seems like there is a pending interest in making a release that >> removes >> > support for some deprecated features. That would need to be a 1.7.0 >> release >> > -- to hold to the semantic naming, as I would like. >> > >> > I would like like to release the configurable-index-origin feature in a >> > release that does not change the default. However, in a later release, I >> > think we will want to change Watir to use a zero-based origin. >> > >> > >> > Today, at the office, we were also looking at using Watir with a newer >> > version of Ruby. We are using Ruby 1.8.6 p287 (IIRC). Not sure entirely >> what >> > is holding us from using the latest version of 1.8.6 or 1.8.7. Are we >> still >> > running into problems with the Win32 gems? Is anyone using Watir's >> > showModalDialog support with a newer version of Ruby? Any way, I'd like >> to >> > see if I can get this sorted out. >> > >> > >> > Bret >> > >> > >> > On Tue, Oct 26, 2010 at 4:11 PM, Charley Baker > > >> > wrote: >> >> >> >> Agreed, we can do it better, the rolling releases and getting those >> >> going has been a priority just to make sure we can step it up a bit. >> >> After so much inactivity, I feel comfortable with the overall workflow >> >> again. >> >> >> >> Let's prioritize JIRA issues and move them into this next release. >> >> If anyone would like to step up and help out, feel free to let me >> >> know. Obviously you're welcome to make pull requests, and edit JIRA at >> >> will. We should have a better idea of what's going in the next release >> >> in the next day or two. >> >> >> >> Cheers, >> >> >> >> Charley Baker >> >> Lead Developer, Watir, http://watir.com >> >> >> >> >> >> >> >> On Tue, Oct 26, 2010 at 1:57 PM, Jarmo wrote: >> >> > It took 24 days to release new version. Woho! >> >> > >> >> > But i think that we could do it even better :) >> >> > >> >> > Agenda for the next version? >> >> > >> >> > Jarmo >> >> > >> >> > On Tue, Oct 26, 2010 at 10:37 PM, Charley Baker >> >> > wrote: >> >> >> Hello, everyone! >> >> >> >> >> >> Watir 1.6.7 got just released! >> >> >> >> >> >> >> >> >> === General improvements >> >> >> * added new waiting methods for Watir::Element: #when_present, >> >> >> #wait_until_present and #wait_while_present (Jari Bakken and Jarmo >> >> >> Pertman) >> >> >> * added new waiting methods for Watir::IE and Watir::Firefox: >> >> >> #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) >> >> >> * added method #present? for Watir::Element (Jari Bakken and Jarmo >> >> >> Pertman) >> >> >> * deprecated old waiting methods in Watir::Waiter which will be >> >> >> removed in some future version - use Watir::Wait instead (Jarmo >> >> >> Pertman) >> >> >> >> >> >> === IE improvements >> >> >> * removed Watir::Simple (?eljko Filipin) >> >> >> * #click_no_wait was not working with frame elements. Closes >> >> >> http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) >> >> >> >> >> >> === Firefox improvements >> >> >> * get_attribute_value now works with attributes named something like >> >> >> "foo-bar" (Alan Shields) >> >> >> >> >> >> === Cleanup & Maintenance >> >> >> * cleaned up repo at GitHub >> >> >> * merge licenses into one (?eljko Filipin) >> >> >> * Rakefile works now under non-Windows systems too (Alan Shields) >> >> >> * Removed datahandler.rb (Charley Baker) >> >> >> >> >> >> Install it with: >> >> >> >> >> >> gem install watir >> >> >> >> >> >> And run your existing tests. >> >> >> >> >> >> If you're seeing any problems then don't forget to open a ticket at >> >> >> JIRA (http://jira.openqa.org/browse/WTR) or fork the project on >> GitHub >> >> >> (http://github.com/bret/watir) and send us a pull request with the >> >> >> fix! >> >> >> If you have any problems installing Watir, then read more detailed >> >> >> instructions at http://watir.com/installation/ >> >> >> >> >> >> Watir Development Team >> >> >> _______________________________________________ >> >> >> Wtr-development mailing list >> >> >> Wtr-development at rubyforge.org >> >> >> http://rubyforge.org/mailman/listinfo/wtr-development >> >> > _______________________________________________ >> >> > Wtr-development mailing list >> >> > Wtr-development at rubyforge.org >> >> > http://rubyforge.org/mailman/listinfo/wtr-development >> >> _______________________________________________ >> >> Wtr-development mailing list >> >> Wtr-development at rubyforge.org >> >> http://rubyforge.org/mailman/listinfo/wtr-development >> > >> > >> > -- >> > Bret Pettichord >> > Lead Developer, Watir, www.watir.com >> > >> > Blog, www.io.com/~wazmo/blog >> > Twitter, www.twitter.com/bpettichord >> > >> > >> > _______________________________________________ >> > Wtr-development mailing list >> > Wtr-development at rubyforge.org >> > http://rubyforge.org/mailman/listinfo/wtr-development >> > >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > 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 Wed Oct 27 12:00:49 2010 From: jarmo.p at gmail.com (Jarmo) Date: Wed, 27 Oct 2010 19:00:49 +0300 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: What's wrong with the very non-obscure boolean as i suggested before? If i'd be a newcomer and come to Watir then all those "indexing_origin", "origin", "base_index" wouldn't make sense to me. Jari's "index_offset" would be least obscure if i'd stumble it in the code. I'd remove the "use" from my recommendation and put it like Watir.zero_based_indexing = true I don't personally think that using "0" and "1" makes more sense, especially for the people who don't know the problem of 1-based indexing itself. Why not make the name and usage of the method self-explanatory? Jarmo On Wed, Oct 27, 2010 at 5:53 PM, Bret Pettichord wrote: > I think that it is easier to understand if the values are 0 and 1, than true > and false. I'm happy to put a guard on it to prevent it from being set to > other values. > > Is this easier to understand? > > ? Watir.indexing_origin = 0 > > I'm also finding the ability to use Watir.origin in the tests to be quite > handy and suspect that I'll use the same technique in our test suite as we > prepare to convert, which will not be trivial. This really begs to be noun. > And Watir.index_base seems to me to be even more obscure. But maybe that's > just me? > > Bret > > > On Wed, Oct 27, 2010 at 2:50 AM, Jarmo wrote: >> >> I'd change #origin to something more explanatory... Since it will be >> more or less a temporary option since there is plan to make 0 to >> default in the future then we could have some better explanatory name. >> Also, why not just make it a boolean? I don't think that someone likes >> to set it to something else than 0 or 1... so I'd suggest something in >> the lines of: >> Watir.use_zero_based_indexing = true >> >> Jarmo >> >> 2010/10/27 Bret Pettichord : >> > This weekend I started updating Watir so that it could be configured to >> > use >> > either a one or zero-based index. You turn on zero-indexing using this >> > command: >> > >> > ?? Watir.origin = 0 >> > >> > I am doing this work right now on a topic branch (I didn't want to >> > interfere >> > with the 1.6.7 release) and with your consent will merge it into master >> > when >> > it is complete. >> > >> > I have a number of tests working with the origin so far, but there are >> > lots >> > of hidden places where this has an effect (iterators, tables). I expect >> > this >> > will be done in a week or two or so. >> > >> > Appreciate your comments on this. Work in progress is here: >> > >> > http://github.com/bret/watir/commits/zero-index >> > >> > >> > It seems like there is a pending interest in making a release that >> > removes >> > support for some deprecated features. That would need to be a 1.7.0 >> > release >> > -- to hold to the semantic naming, as I would like. >> > >> > I would like like to release the configurable-index-origin feature in a >> > release that does not change the default. However, in a later release, I >> > think we will want to change Watir to use a zero-based origin. >> > >> > >> > Today, at the office, we were also looking at using Watir with a newer >> > version of Ruby. We are using Ruby 1.8.6 p287 (IIRC). Not sure entirely >> > what >> > is holding us from using the latest version of 1.8.6 or 1.8.7. Are we >> > still >> > running into problems with the Win32 gems? Is anyone using Watir's >> > showModalDialog support with a newer version of Ruby? Any way, I'd like >> > to >> > see if I can get this sorted out. >> > >> > >> > Bret >> > >> > >> > On Tue, Oct 26, 2010 at 4:11 PM, Charley Baker >> > wrote: >> >> >> >> Agreed, we can do it better, the rolling releases and getting those >> >> going has been a priority just to make sure we can step it up a bit. >> >> After so much inactivity, I feel comfortable with the overall workflow >> >> again. >> >> >> >> ?Let's prioritize JIRA issues and move them into this next release. >> >> If anyone would like to step up and help out, feel free to let me >> >> know. Obviously you're welcome to make pull requests, and edit JIRA at >> >> will. We should have a better idea of what's going in the next release >> >> in the next day or two. >> >> >> >> Cheers, >> >> >> >> Charley Baker >> >> Lead Developer, Watir, http://watir.com >> >> >> >> >> >> >> >> On Tue, Oct 26, 2010 at 1:57 PM, Jarmo wrote: >> >> > It took 24 days to release new version. Woho! >> >> > >> >> > But i think that we could do it even better :) >> >> > >> >> > Agenda for the next version? >> >> > >> >> > Jarmo >> >> > >> >> > On Tue, Oct 26, 2010 at 10:37 PM, Charley Baker >> >> > wrote: >> >> >> Hello, everyone! >> >> >> >> >> >> Watir 1.6.7 got just released! >> >> >> >> >> >> >> >> >> === General improvements >> >> >> * added new waiting methods for Watir::Element: #when_present, >> >> >> #wait_until_present and #wait_while_present (Jari Bakken and Jarmo >> >> >> Pertman) >> >> >> * added new waiting methods for Watir::IE and Watir::Firefox: >> >> >> #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) >> >> >> * added method #present? for Watir::Element (Jari Bakken and Jarmo >> >> >> Pertman) >> >> >> * deprecated old waiting methods in Watir::Waiter which will be >> >> >> removed in some future version - use Watir::Wait instead (Jarmo >> >> >> Pertman) >> >> >> >> >> >> === IE improvements >> >> >> * removed Watir::Simple (?eljko Filipin) >> >> >> * #click_no_wait was not working with frame elements. Closes >> >> >> http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) >> >> >> >> >> >> === Firefox improvements >> >> >> * get_attribute_value now works with attributes named something like >> >> >> "foo-bar" (Alan Shields) >> >> >> >> >> >> === Cleanup & Maintenance >> >> >> * cleaned up repo at GitHub >> >> >> * merge licenses into one (?eljko Filipin) >> >> >> * Rakefile works now under non-Windows systems too (Alan Shields) >> >> >> * Removed datahandler.rb (Charley Baker) >> >> >> >> >> >> Install it with: >> >> >> >> >> >> gem install watir >> >> >> >> >> >> And run your existing tests. >> >> >> >> >> >> If you're seeing any problems then don't forget to open a ticket at >> >> >> JIRA (http://jira.openqa.org/browse/WTR) or fork the project on >> >> >> GitHub >> >> >> (http://github.com/bret/watir) and send us a pull request with the >> >> >> fix! >> >> >> If you have any problems installing Watir, then read more detailed >> >> >> instructions at http://watir.com/installation/ >> >> >> >> >> >> Watir Development Team >> >> >> _______________________________________________ >> >> >> Wtr-development mailing list >> >> >> Wtr-development at rubyforge.org >> >> >> http://rubyforge.org/mailman/listinfo/wtr-development >> >> > _______________________________________________ >> >> > Wtr-development mailing list >> >> > Wtr-development at rubyforge.org >> >> > http://rubyforge.org/mailman/listinfo/wtr-development >> >> _______________________________________________ >> >> Wtr-development mailing list >> >> Wtr-development at rubyforge.org >> >> http://rubyforge.org/mailman/listinfo/wtr-development >> > >> > >> > -- >> > Bret Pettichord >> > Lead Developer, Watir, www.watir.com >> > >> > Blog, www.io.com/~wazmo/blog >> > Twitter, www.twitter.com/bpettichord >> > >> > >> > _______________________________________________ >> > Wtr-development mailing list >> > Wtr-development at rubyforge.org >> > http://rubyforge.org/mailman/listinfo/wtr-development >> > >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From notethan at gmail.com Wed Oct 27 14:12:19 2010 From: notethan at gmail.com (Ethan) Date: Wed, 27 Oct 2010 14:12:19 -0400 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: I think it makes more sense for a user to specify 0 or 1 as the index they want to start at. It also makes the code simpler to deal with (on the watir side - not on the user's side) - adding or subtracting index_offset rather than adding or subtracting (zero_based_indexing ? 0 : 1). On Wed, Oct 27, 2010 at 12:00, Jarmo wrote: > What's wrong with the very non-obscure boolean as i suggested before? > > If i'd be a newcomer and come to Watir then all those > "indexing_origin", "origin", "base_index" wouldn't make sense to me. > Jari's "index_offset" would be least obscure if i'd stumble it in the > code. > > I'd remove the "use" from my recommendation and put it like > Watir.zero_based_indexing = true > > I don't personally think that using "0" and "1" makes more sense, > especially for the people who don't know the problem of 1-based > indexing itself. Why not make the name and usage of the method > self-explanatory? > > Jarmo > > On Wed, Oct 27, 2010 at 5:53 PM, Bret Pettichord > wrote: > > I think that it is easier to understand if the values are 0 and 1, than > true > > and false. I'm happy to put a guard on it to prevent it from being set to > > other values. > > > > Is this easier to understand? > > > > Watir.indexing_origin = 0 > > > > I'm also finding the ability to use Watir.origin in the tests to be quite > > handy and suspect that I'll use the same technique in our test suite as > we > > prepare to convert, which will not be trivial. This really begs to be > noun. > > And Watir.index_base seems to me to be even more obscure. But maybe > that's > > just me? > > > > Bret > > > > > > On Wed, Oct 27, 2010 at 2:50 AM, Jarmo wrote: > >> > >> I'd change #origin to something more explanatory... Since it will be > >> more or less a temporary option since there is plan to make 0 to > >> default in the future then we could have some better explanatory name. > >> Also, why not just make it a boolean? I don't think that someone likes > >> to set it to something else than 0 or 1... so I'd suggest something in > >> the lines of: > >> Watir.use_zero_based_indexing = true > >> > >> Jarmo > >> > >> 2010/10/27 Bret Pettichord : > >> > This weekend I started updating Watir so that it could be configured > to > >> > use > >> > either a one or zero-based index. You turn on zero-indexing using this > >> > command: > >> > > >> > Watir.origin = 0 > >> > > >> > I am doing this work right now on a topic branch (I didn't want to > >> > interfere > >> > with the 1.6.7 release) and with your consent will merge it into > master > >> > when > >> > it is complete. > >> > > >> > I have a number of tests working with the origin so far, but there are > >> > lots > >> > of hidden places where this has an effect (iterators, tables). I > expect > >> > this > >> > will be done in a week or two or so. > >> > > >> > Appreciate your comments on this. Work in progress is here: > >> > > >> > http://github.com/bret/watir/commits/zero-index > >> > > >> > > >> > It seems like there is a pending interest in making a release that > >> > removes > >> > support for some deprecated features. That would need to be a 1.7.0 > >> > release > >> > -- to hold to the semantic naming, as I would like. > >> > > >> > I would like like to release the configurable-index-origin feature in > a > >> > release that does not change the default. However, in a later release, > I > >> > think we will want to change Watir to use a zero-based origin. > >> > > >> > > >> > Today, at the office, we were also looking at using Watir with a newer > >> > version of Ruby. We are using Ruby 1.8.6 p287 (IIRC). Not sure > entirely > >> > what > >> > is holding us from using the latest version of 1.8.6 or 1.8.7. Are we > >> > still > >> > running into problems with the Win32 gems? Is anyone using Watir's > >> > showModalDialog support with a newer version of Ruby? Any way, I'd > like > >> > to > >> > see if I can get this sorted out. > >> > > >> > > >> > Bret > >> > > >> > > >> > On Tue, Oct 26, 2010 at 4:11 PM, Charley Baker < > charley.baker at gmail.com> > >> > wrote: > >> >> > >> >> Agreed, we can do it better, the rolling releases and getting those > >> >> going has been a priority just to make sure we can step it up a bit. > >> >> After so much inactivity, I feel comfortable with the overall > workflow > >> >> again. > >> >> > >> >> Let's prioritize JIRA issues and move them into this next release. > >> >> If anyone would like to step up and help out, feel free to let me > >> >> know. Obviously you're welcome to make pull requests, and edit JIRA > at > >> >> will. We should have a better idea of what's going in the next > release > >> >> in the next day or two. > >> >> > >> >> Cheers, > >> >> > >> >> Charley Baker > >> >> Lead Developer, Watir, http://watir.com > >> >> > >> >> > >> >> > >> >> On Tue, Oct 26, 2010 at 1:57 PM, Jarmo wrote: > >> >> > It took 24 days to release new version. Woho! > >> >> > > >> >> > But i think that we could do it even better :) > >> >> > > >> >> > Agenda for the next version? > >> >> > > >> >> > Jarmo > >> >> > > >> >> > On Tue, Oct 26, 2010 at 10:37 PM, Charley Baker > >> >> > wrote: > >> >> >> Hello, everyone! > >> >> >> > >> >> >> Watir 1.6.7 got just released! > >> >> >> > >> >> >> > >> >> >> === General improvements > >> >> >> * added new waiting methods for Watir::Element: #when_present, > >> >> >> #wait_until_present and #wait_while_present (Jari Bakken and Jarmo > >> >> >> Pertman) > >> >> >> * added new waiting methods for Watir::IE and Watir::Firefox: > >> >> >> #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) > >> >> >> * added method #present? for Watir::Element (Jari Bakken and Jarmo > >> >> >> Pertman) > >> >> >> * deprecated old waiting methods in Watir::Waiter which will be > >> >> >> removed in some future version - use Watir::Wait instead (Jarmo > >> >> >> Pertman) > >> >> >> > >> >> >> === IE improvements > >> >> >> * removed Watir::Simple (?eljko Filipin) > >> >> >> * #click_no_wait was not working with frame elements. Closes > >> >> >> http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) > >> >> >> > >> >> >> === Firefox improvements > >> >> >> * get_attribute_value now works with attributes named something > like > >> >> >> "foo-bar" (Alan Shields) > >> >> >> > >> >> >> === Cleanup & Maintenance > >> >> >> * cleaned up repo at GitHub > >> >> >> * merge licenses into one (?eljko Filipin) > >> >> >> * Rakefile works now under non-Windows systems too (Alan Shields) > >> >> >> * Removed datahandler.rb (Charley Baker) > >> >> >> > >> >> >> Install it with: > >> >> >> > >> >> >> gem install watir > >> >> >> > >> >> >> And run your existing tests. > >> >> >> > >> >> >> If you're seeing any problems then don't forget to open a ticket > at > >> >> >> JIRA (http://jira.openqa.org/browse/WTR) or fork the project on > >> >> >> GitHub > >> >> >> (http://github.com/bret/watir) and send us a pull request with > the > >> >> >> fix! > >> >> >> If you have any problems installing Watir, then read more detailed > >> >> >> instructions at http://watir.com/installation/ > >> >> >> > >> >> >> Watir Development Team > >> >> >> _______________________________________________ > >> >> >> Wtr-development mailing list > >> >> >> Wtr-development at rubyforge.org > >> >> >> http://rubyforge.org/mailman/listinfo/wtr-development > >> >> > _______________________________________________ > >> >> > Wtr-development mailing list > >> >> > Wtr-development at rubyforge.org > >> >> > http://rubyforge.org/mailman/listinfo/wtr-development > >> >> _______________________________________________ > >> >> Wtr-development mailing list > >> >> Wtr-development at rubyforge.org > >> >> http://rubyforge.org/mailman/listinfo/wtr-development > >> > > >> > > >> > -- > >> > Bret Pettichord > >> > Lead Developer, Watir, www.watir.com > >> > > >> > Blog, www.io.com/~wazmo/blog > >> > Twitter, www.twitter.com/bpettichord > >> > > >> > > >> > _______________________________________________ > >> > Wtr-development mailing list > >> > Wtr-development at rubyforge.org > >> > http://rubyforge.org/mailman/listinfo/wtr-development > >> > > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > > > -- > > Bret Pettichord > > Lead Developer, Watir, www.watir.com > > > > Blog, www.io.com/~wazmo/blog > > Twitter, www.twitter.com/bpettichord > > > > > > _______________________________________________ > > 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 jarmo.p at gmail.com Wed Oct 27 14:16:40 2010 From: jarmo.p at gmail.com (Jarmo) Date: Wed, 27 Oct 2010 21:16:40 +0300 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: Makes sense, although watir-webdriver is with version 0.1.1 which means that it's API could change :) Jarmo On Wed, Oct 27, 2010 at 6:50 PM, Ethan wrote: > base_index, index_offset, indexing_origin - whatever. I think this is one of > those cases where any of them is perfectly fine, but consistency among > things implementing the watir API is most valuable. since jarib went with > index_offset in one place already, that seems like as good a choice as any > of the others to me, and gets my vote. > > On Wed, Oct 27, 2010 at 10:53, Bret Pettichord wrote: >> >> I think that it is easier to understand if the values are 0 and 1, than >> true and false. I'm happy to put a guard on it to prevent it from being set >> to other values. >> >> Is this easier to understand? >> >> ? Watir.indexing_origin = 0 >> >> I'm also finding the ability to use Watir.origin in the tests to be quite >> handy and suspect that I'll use the same technique in our test suite as we >> prepare to convert, which will not be trivial. This really begs to be noun. >> And Watir.index_base seems to me to be even more obscure. But maybe that's >> just me? >> >> Bret >> >> >> On Wed, Oct 27, 2010 at 2:50 AM, Jarmo wrote: >>> >>> I'd change #origin to something more explanatory... Since it will be >>> more or less a temporary option since there is plan to make 0 to >>> default in the future then we could have some better explanatory name. >>> Also, why not just make it a boolean? I don't think that someone likes >>> to set it to something else than 0 or 1... so I'd suggest something in >>> the lines of: >>> Watir.use_zero_based_indexing = true >>> >>> Jarmo >>> >>> 2010/10/27 Bret Pettichord : >>> > This weekend I started updating Watir so that it could be configured to >>> > use >>> > either a one or zero-based index. You turn on zero-indexing using this >>> > command: >>> > >>> > ?? Watir.origin = 0 >>> > >>> > I am doing this work right now on a topic branch (I didn't want to >>> > interfere >>> > with the 1.6.7 release) and with your consent will merge it into master >>> > when >>> > it is complete. >>> > >>> > I have a number of tests working with the origin so far, but there are >>> > lots >>> > of hidden places where this has an effect (iterators, tables). I expect >>> > this >>> > will be done in a week or two or so. >>> > >>> > Appreciate your comments on this. Work in progress is here: >>> > >>> > http://github.com/bret/watir/commits/zero-index >>> > >>> > >>> > It seems like there is a pending interest in making a release that >>> > removes >>> > support for some deprecated features. That would need to be a 1.7.0 >>> > release >>> > -- to hold to the semantic naming, as I would like. >>> > >>> > I would like like to release the configurable-index-origin feature in a >>> > release that does not change the default. However, in a later release, >>> > I >>> > think we will want to change Watir to use a zero-based origin. >>> > >>> > >>> > Today, at the office, we were also looking at using Watir with a newer >>> > version of Ruby. We are using Ruby 1.8.6 p287 (IIRC). Not sure entirely >>> > what >>> > is holding us from using the latest version of 1.8.6 or 1.8.7. Are we >>> > still >>> > running into problems with the Win32 gems? Is anyone using Watir's >>> > showModalDialog support with a newer version of Ruby? Any way, I'd like >>> > to >>> > see if I can get this sorted out. >>> > >>> > >>> > Bret >>> > >>> > >>> > On Tue, Oct 26, 2010 at 4:11 PM, Charley Baker >>> > >>> > wrote: >>> >> >>> >> Agreed, we can do it better, the rolling releases and getting those >>> >> going has been a priority just to make sure we can step it up a bit. >>> >> After so much inactivity, I feel comfortable with the overall workflow >>> >> again. >>> >> >>> >> ?Let's prioritize JIRA issues and move them into this next release. >>> >> If anyone would like to step up and help out, feel free to let me >>> >> know. Obviously you're welcome to make pull requests, and edit JIRA at >>> >> will. We should have a better idea of what's going in the next release >>> >> in the next day or two. >>> >> >>> >> Cheers, >>> >> >>> >> Charley Baker >>> >> Lead Developer, Watir, http://watir.com >>> >> >>> >> >>> >> >>> >> On Tue, Oct 26, 2010 at 1:57 PM, Jarmo wrote: >>> >> > It took 24 days to release new version. Woho! >>> >> > >>> >> > But i think that we could do it even better :) >>> >> > >>> >> > Agenda for the next version? >>> >> > >>> >> > Jarmo >>> >> > >>> >> > On Tue, Oct 26, 2010 at 10:37 PM, Charley Baker >>> >> > wrote: >>> >> >> Hello, everyone! >>> >> >> >>> >> >> Watir 1.6.7 got just released! >>> >> >> >>> >> >> >>> >> >> === General improvements >>> >> >> * added new waiting methods for Watir::Element: #when_present, >>> >> >> #wait_until_present and #wait_while_present (Jari Bakken and Jarmo >>> >> >> Pertman) >>> >> >> * added new waiting methods for Watir::IE and Watir::Firefox: >>> >> >> #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) >>> >> >> * added method #present? for Watir::Element (Jari Bakken and Jarmo >>> >> >> Pertman) >>> >> >> * deprecated old waiting methods in Watir::Waiter which will be >>> >> >> removed in some future version - use Watir::Wait instead (Jarmo >>> >> >> Pertman) >>> >> >> >>> >> >> === IE improvements >>> >> >> * removed Watir::Simple (?eljko Filipin) >>> >> >> * #click_no_wait was not working with frame elements. Closes >>> >> >> http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) >>> >> >> >>> >> >> === Firefox improvements >>> >> >> * get_attribute_value now works with attributes named something >>> >> >> like >>> >> >> "foo-bar" (Alan Shields) >>> >> >> >>> >> >> === Cleanup & Maintenance >>> >> >> * cleaned up repo at GitHub >>> >> >> * merge licenses into one (?eljko Filipin) >>> >> >> * Rakefile works now under non-Windows systems too (Alan Shields) >>> >> >> * Removed datahandler.rb (Charley Baker) >>> >> >> >>> >> >> Install it with: >>> >> >> >>> >> >> gem install watir >>> >> >> >>> >> >> And run your existing tests. >>> >> >> >>> >> >> If you're seeing any problems then don't forget to open a ticket at >>> >> >> JIRA (http://jira.openqa.org/browse/WTR) or fork the project on >>> >> >> GitHub >>> >> >> (http://github.com/bret/watir) and send us a pull request with the >>> >> >> fix! >>> >> >> If you have any problems installing Watir, then read more detailed >>> >> >> instructions at http://watir.com/installation/ >>> >> >> >>> >> >> Watir Development Team >>> >> >> _______________________________________________ >>> >> >> Wtr-development mailing list >>> >> >> Wtr-development at rubyforge.org >>> >> >> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> > _______________________________________________ >>> >> > Wtr-development mailing list >>> >> > Wtr-development at rubyforge.org >>> >> > http://rubyforge.org/mailman/listinfo/wtr-development >>> >> _______________________________________________ >>> >> Wtr-development mailing list >>> >> Wtr-development at rubyforge.org >>> >> http://rubyforge.org/mailman/listinfo/wtr-development >>> > >>> > >>> > -- >>> > Bret Pettichord >>> > Lead Developer, Watir, www.watir.com >>> > >>> > Blog, www.io.com/~wazmo/blog >>> > Twitter, www.twitter.com/bpettichord >>> > >>> > >>> > _______________________________________________ >>> > Wtr-development mailing list >>> > Wtr-development at rubyforge.org >>> > http://rubyforge.org/mailman/listinfo/wtr-development >>> > >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >> >> >> -- >> Bret Pettichord >> Lead Developer, Watir, www.watir.com >> >> Blog, www.io.com/~wazmo/blog >> Twitter, www.twitter.com/bpettichord >> >> >> _______________________________________________ >> 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 jarmo.p at gmail.com Wed Oct 27 15:08:49 2010 From: jarmo.p at gmail.com (Jarmo) Date: Wed, 27 Oct 2010 22:08:49 +0300 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: Well, you're gonna extract that logic into method anyway hopefully so i don't see any problems. Bret, i just reviewed your code and noticed 3 things in addition to the method name itself: 1) why did you create separate file called origin.rb for that? couldn't you use options.rb in similar way as it's used for :speed now? 2) usage of global variable $ORIGIN... i'd not recommend using global variables at all, there's too many in tests already... could use Watir.orgin instead 3) let's not change tests at all, but just create some new test for specifically testing that Watir.origin (or whatever it's called) works as expected. All other index-based tests could stay as they are and work with default indexing (so, 1 for now). I don't see much of a point in modifying all tests to subtract or add 1. What do you think? Jarmo On Wed, Oct 27, 2010 at 9:12 PM, Ethan wrote: > I think it makes more sense for a user to specify 0 or 1 as the index they > want to start at. It also makes the code simpler to deal with (on the watir > side - not on the user's side) - adding or subtracting index_offset rather > than adding or subtracting (zero_based_indexing ? 0 : 1). > > On Wed, Oct 27, 2010 at 12:00, Jarmo wrote: >> >> What's wrong with the very non-obscure boolean as i suggested before? >> >> If i'd be a newcomer and come to Watir then all those >> "indexing_origin", "origin", "base_index" wouldn't make sense to me. >> Jari's "index_offset" would be least obscure if i'd stumble it in the >> code. >> >> I'd remove the "use" from my recommendation and put it like >> Watir.zero_based_indexing = true >> >> I don't personally think that using "0" and "1" makes more sense, >> especially for the people who don't know the problem of 1-based >> indexing itself. Why not make the name and usage of the method >> self-explanatory? >> >> Jarmo >> >> On Wed, Oct 27, 2010 at 5:53 PM, Bret Pettichord >> wrote: >> > I think that it is easier to understand if the values are 0 and 1, than >> > true >> > and false. I'm happy to put a guard on it to prevent it from being set >> > to >> > other values. >> > >> > Is this easier to understand? >> > >> > ? Watir.indexing_origin = 0 >> > >> > I'm also finding the ability to use Watir.origin in the tests to be >> > quite >> > handy and suspect that I'll use the same technique in our test suite as >> > we >> > prepare to convert, which will not be trivial. This really begs to be >> > noun. >> > And Watir.index_base seems to me to be even more obscure. But maybe >> > that's >> > just me? >> > >> > Bret >> > >> > >> > On Wed, Oct 27, 2010 at 2:50 AM, Jarmo wrote: >> >> >> >> I'd change #origin to something more explanatory... Since it will be >> >> more or less a temporary option since there is plan to make 0 to >> >> default in the future then we could have some better explanatory name. >> >> Also, why not just make it a boolean? I don't think that someone likes >> >> to set it to something else than 0 or 1... so I'd suggest something in >> >> the lines of: >> >> Watir.use_zero_based_indexing = true >> >> >> >> Jarmo >> >> >> >> 2010/10/27 Bret Pettichord : >> >> > This weekend I started updating Watir so that it could be configured >> >> > to >> >> > use >> >> > either a one or zero-based index. You turn on zero-indexing using >> >> > this >> >> > command: >> >> > >> >> > ?? Watir.origin = 0 >> >> > >> >> > I am doing this work right now on a topic branch (I didn't want to >> >> > interfere >> >> > with the 1.6.7 release) and with your consent will merge it into >> >> > master >> >> > when >> >> > it is complete. >> >> > >> >> > I have a number of tests working with the origin so far, but there >> >> > are >> >> > lots >> >> > of hidden places where this has an effect (iterators, tables). I >> >> > expect >> >> > this >> >> > will be done in a week or two or so. >> >> > >> >> > Appreciate your comments on this. Work in progress is here: >> >> > >> >> > http://github.com/bret/watir/commits/zero-index >> >> > >> >> > >> >> > It seems like there is a pending interest in making a release that >> >> > removes >> >> > support for some deprecated features. That would need to be a 1.7.0 >> >> > release >> >> > -- to hold to the semantic naming, as I would like. >> >> > >> >> > I would like like to release the configurable-index-origin feature in >> >> > a >> >> > release that does not change the default. However, in a later >> >> > release, I >> >> > think we will want to change Watir to use a zero-based origin. >> >> > >> >> > >> >> > Today, at the office, we were also looking at using Watir with a >> >> > newer >> >> > version of Ruby. We are using Ruby 1.8.6 p287 (IIRC). Not sure >> >> > entirely >> >> > what >> >> > is holding us from using the latest version of 1.8.6 or 1.8.7. Are we >> >> > still >> >> > running into problems with the Win32 gems? Is anyone using Watir's >> >> > showModalDialog support with a newer version of Ruby? Any way, I'd >> >> > like >> >> > to >> >> > see if I can get this sorted out. >> >> > >> >> > >> >> > Bret >> >> > >> >> > >> >> > On Tue, Oct 26, 2010 at 4:11 PM, Charley Baker >> >> > >> >> > wrote: >> >> >> >> >> >> Agreed, we can do it better, the rolling releases and getting those >> >> >> going has been a priority just to make sure we can step it up a bit. >> >> >> After so much inactivity, I feel comfortable with the overall >> >> >> workflow >> >> >> again. >> >> >> >> >> >> ?Let's prioritize JIRA issues and move them into this next release. >> >> >> If anyone would like to step up and help out, feel free to let me >> >> >> know. Obviously you're welcome to make pull requests, and edit JIRA >> >> >> at >> >> >> will. We should have a better idea of what's going in the next >> >> >> release >> >> >> in the next day or two. >> >> >> >> >> >> Cheers, >> >> >> >> >> >> Charley Baker >> >> >> Lead Developer, Watir, http://watir.com >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Oct 26, 2010 at 1:57 PM, Jarmo wrote: >> >> >> > It took 24 days to release new version. Woho! >> >> >> > >> >> >> > But i think that we could do it even better :) >> >> >> > >> >> >> > Agenda for the next version? >> >> >> > >> >> >> > Jarmo >> >> >> > >> >> >> > On Tue, Oct 26, 2010 at 10:37 PM, Charley Baker >> >> >> > wrote: >> >> >> >> Hello, everyone! >> >> >> >> >> >> >> >> Watir 1.6.7 got just released! >> >> >> >> >> >> >> >> >> >> >> >> === General improvements >> >> >> >> * added new waiting methods for Watir::Element: #when_present, >> >> >> >> #wait_until_present and #wait_while_present (Jari Bakken and >> >> >> >> Jarmo >> >> >> >> Pertman) >> >> >> >> * added new waiting methods for Watir::IE and Watir::Firefox: >> >> >> >> #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) >> >> >> >> * added method #present? for Watir::Element (Jari Bakken and >> >> >> >> Jarmo >> >> >> >> Pertman) >> >> >> >> * deprecated old waiting methods in Watir::Waiter which will be >> >> >> >> removed in some future version - use Watir::Wait instead (Jarmo >> >> >> >> Pertman) >> >> >> >> >> >> >> >> === IE improvements >> >> >> >> * removed Watir::Simple (?eljko Filipin) >> >> >> >> * #click_no_wait was not working with frame elements. Closes >> >> >> >> http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) >> >> >> >> >> >> >> >> === Firefox improvements >> >> >> >> * get_attribute_value now works with attributes named something >> >> >> >> like >> >> >> >> "foo-bar" (Alan Shields) >> >> >> >> >> >> >> >> === Cleanup & Maintenance >> >> >> >> * cleaned up repo at GitHub >> >> >> >> * merge licenses into one (?eljko Filipin) >> >> >> >> * Rakefile works now under non-Windows systems too (Alan Shields) >> >> >> >> * Removed datahandler.rb (Charley Baker) >> >> >> >> >> >> >> >> Install it with: >> >> >> >> >> >> >> >> gem install watir >> >> >> >> >> >> >> >> And run your existing tests. >> >> >> >> >> >> >> >> If you're seeing any problems then don't forget to open a ticket >> >> >> >> at >> >> >> >> JIRA (http://jira.openqa.org/browse/WTR) or fork the project on >> >> >> >> GitHub >> >> >> >> (http://github.com/bret/watir) and send us a pull request with >> >> >> >> the >> >> >> >> fix! >> >> >> >> If you have any problems installing Watir, then read more >> >> >> >> detailed >> >> >> >> instructions at http://watir.com/installation/ >> >> >> >> >> >> >> >> Watir Development Team >> >> >> >> _______________________________________________ >> >> >> >> Wtr-development mailing list >> >> >> >> Wtr-development at rubyforge.org >> >> >> >> http://rubyforge.org/mailman/listinfo/wtr-development >> >> >> > _______________________________________________ >> >> >> > Wtr-development mailing list >> >> >> > Wtr-development at rubyforge.org >> >> >> > http://rubyforge.org/mailman/listinfo/wtr-development >> >> >> _______________________________________________ >> >> >> Wtr-development mailing list >> >> >> Wtr-development at rubyforge.org >> >> >> http://rubyforge.org/mailman/listinfo/wtr-development >> >> > >> >> > >> >> > -- >> >> > Bret Pettichord >> >> > Lead Developer, Watir, www.watir.com >> >> > >> >> > Blog, www.io.com/~wazmo/blog >> >> > Twitter, www.twitter.com/bpettichord >> >> > >> >> > >> >> > _______________________________________________ >> >> > Wtr-development mailing list >> >> > Wtr-development at rubyforge.org >> >> > http://rubyforge.org/mailman/listinfo/wtr-development >> >> > >> >> _______________________________________________ >> >> Wtr-development mailing list >> >> Wtr-development at rubyforge.org >> >> http://rubyforge.org/mailman/listinfo/wtr-development >> > >> > >> > -- >> > Bret Pettichord >> > Lead Developer, Watir, www.watir.com >> > >> > Blog, www.io.com/~wazmo/blog >> > Twitter, www.twitter.com/bpettichord >> > >> > >> > _______________________________________________ >> > 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 > From jari.bakken at gmail.com Wed Oct 27 15:15:30 2010 From: jari.bakken at gmail.com (Jari Bakken) Date: Thu, 28 Oct 2010 00:45:30 +0530 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: On Wed, Oct 27, 2010 at 11:46 PM, Jarmo wrote: > Makes sense, although watir-webdriver is with version 0.1.1 which > means that it's API could change :) > I'm not really following semantic versioning at the moment, so don't read too much into it. I like the concept, it's just requires a bit more discipline. :) The WHATWG HTML spec which I've used to generate much of the code is unversioned though, which we'll have to take into account if we want to keep in close sync with the spec (which is tempting since it's so easy in watir-webdriver's case). It might just mean we'll bump major versions more frequently than most projects. Also, the YARD documentation tool has an excellent feature that lets you diff the APIs of two gems - grab the latest YARD gem and try `yard help diff`. Very nifty. From watirjira at gmail.com Wed Oct 27 15:38:20 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 27 Oct 2010 14:38:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-461) Typo in README.rdoc, mismatch with example code In-Reply-To: <22972864.242.1288179859977.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <11345837.245.1288208300521.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19961#action_19961 ] Jarmo Pertman commented on WTR-461: ----------------------------------- Thank you for these observations! Fixed http://github.com/bret/watir/commit/110abca79293d9da90a939fc3b0e17421dd3bcf1 And closed. > Typo in README.rdoc, mismatch with example code > ------------------------------------------------ > > Key: WTR-461 > URL: http://jira.openqa.org/browse/WTR-461 > Project: Watir > Issue Type: Bug > Components: Documentation > Affects Versions: 1.6.6 > Environment: Any > Reporter: Stephan K?mper > > The README.rdoc (http://github.com/bret/watir/blob/master/README.rdoc) says: > Actual text: > > Setting and clearing a radio button > > > > browser.radio(:value => "watir").set > > browser.radio(:value => "watir".clear > Closing parenthesis is missing, should be > > browser.radio(:value => "watir").clear > Additionally the example page (http://bit.ly/watir-example) as given in the code/README actually is: > ... > >
    • > ... > This uses 'Watir' while the example code is 'watir' which in turn raises an exception: > > ... > > Watir::Exception::UnknownObjectException: Unable to locate element, using {:value=>"watir"} -- 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 Oct 27 15:38:20 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 27 Oct 2010 14:38:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Resolved: (WTR-461) Typo in README.rdoc, mismatch with example code In-Reply-To: <22972864.242.1288179859977.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <4738444.247.1288208300631.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarmo Pertman resolved WTR-461. ------------------------------- Resolution: Fixed > Typo in README.rdoc, mismatch with example code > ------------------------------------------------ > > Key: WTR-461 > URL: http://jira.openqa.org/browse/WTR-461 > Project: Watir > Issue Type: Bug > Components: Documentation > Affects Versions: 1.6.6 > Environment: Any > Reporter: Stephan K?mper > > The README.rdoc (http://github.com/bret/watir/blob/master/README.rdoc) says: > Actual text: > > Setting and clearing a radio button > > > > browser.radio(:value => "watir").set > > browser.radio(:value => "watir".clear > Closing parenthesis is missing, should be > > browser.radio(:value => "watir").clear > Additionally the example page (http://bit.ly/watir-example) as given in the code/README actually is: > ... > >
      • > ... > This uses 'Watir' while the example code is 'watir' which in turn raises an exception: > > ... > > Watir::Exception::UnknownObjectException: Unable to locate element, using {:value=>"watir"} -- 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 Oct 27 15:42:23 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:23 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-439) error using attach method with => syntax In-Reply-To: <2798750.201.1273578510734.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <11258305.251.1288208543032.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-439: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > error using attach method with => syntax > ---------------------------------------- > > Key: WTR-439 > URL: http://jira.openqa.org/browse/WTR-439 > Project: Watir > Issue Type: Bug > Components: Window Attachment > Affects Versions: 1.6.5 > Environment: Windows XP, IE8 > Reporter: Marc Betts > Priority: Major > Fix For: Soon > > > browser.attach(:title=>"title") returns the following error: > ArgumentError: wrong number of arguments (1 for 2) > This works fine using browser.attach(:title, "title") -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Wed Oct 27 15:42:23 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:23 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-417) If the html contains a BR tag, watir splits it with a new line and fire watir doesn't give a new line Message-ID: <4164282.253.1288208543090.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-417: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > If the html contains a BR tag, watir splits it with a new line and fire watir doesn't give a new line > ----------------------------------------------------------------------------------------------------- > > Key: WTR-417 > URL: http://jira.openqa.org/browse/WTR-417 > Project: Watir > Issue Type: Bug > Components: FireWatir > Affects Versions: 1.6.2 > Environment: Windows XP > Reporter: Pallavi > Priority: Major > Fix For: Soon > > > code looks like this: > Say the input is: >

        hello
        bye

        > Now if you do from watir saying > puts ie.text > it will print > hello > bye > so text is seperated by new line > but with firewatir > ff.text > output is: > hello bye > separated by space. or at times no space also. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Wed Oct 27 15:42:23 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:23 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-367) watirspec-pending: add Container#option Message-ID: <6239624.260.1288208543387.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-367: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec-pending: add Container#option > --------------------------------------- > > Key: WTR-367 > URL: http://jira.openqa.org/browse/WTR-367 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 12) > NoMethodError in 'Link#url returns the href attribute' > undefined method `url' for # > ./spec/watirspec/link_spec.rb:96: -- 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 Oct 27 15:38:20 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 27 Oct 2010 14:38:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-461) Typo in README.rdoc, mismatch with example code In-Reply-To: <22972864.242.1288179859977.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <24149012.249.1288208300685.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarmo Pertman closed WTR-461. ----------------------------- > Typo in README.rdoc, mismatch with example code > ------------------------------------------------ > > Key: WTR-461 > URL: http://jira.openqa.org/browse/WTR-461 > Project: Watir > Issue Type: Bug > Components: Documentation > Affects Versions: 1.6.6 > Environment: Any > Reporter: Stephan K?mper > > The README.rdoc (http://github.com/bret/watir/blob/master/README.rdoc) says: > Actual text: > > Setting and clearing a radio button > > > > browser.radio(:value => "watir").set > > browser.radio(:value => "watir".clear > Closing parenthesis is missing, should be > > browser.radio(:value => "watir").clear > Additionally the example page (http://bit.ly/watir-example) as given in the code/README actually is: > ... > >
        • > ... > This uses 'Watir' while the example code is 'watir' which in turn raises an exception: > > ... > > Watir::Exception::UnknownObjectException: Unable to locate element, using {:value=>"watir"} -- 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 Oct 27 15:42:23 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:23 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-357) watirspec-pending: `Browser#{body, bodies}` not implemented Message-ID: <14256184.280.1288208543968.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-357: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec-pending: `Browser#{body,bodies}` not implemented > ---------------------------------------------------------- > > Key: WTR-357 > URL: http://jira.openqa.org/browse/WTR-357 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Fix For: Soon > > > 76) > NoMethodError in 'TableBody#exists returns true if the table body exists (page context)' > undefined method `body' for # > ./spec/watirspec/table_body_spec.rb:12: > 78) > NoMethodError in 'TableBody#exists returns true if the element exists (default how = :id)' > undefined method `body' for # > ./spec/watirspec/table_body_spec.rb:30: > 79) > NoMethodError in 'TableBody#exists returns false if the table body exists (page context)' > undefined method `body' for # > ./spec/watirspec/table_body_spec.rb:35: > 80) > 'TableBody#exists raises TypeError when 'what' argument is invalid' FAILED > expected TypeError, got #> > ./spec/watirspec/table_body_spec.rb:53: > 81) > 'TableBody#exists raises MissingWayOfFindingObjectException when 'how' argument is invalid' FAILED > expected Watir::Exception::MissingWayOfFindingObjectException, got #> > ./spec/watirspec/table_body_spec.rb:58: > 82) > NoMethodError in 'TableBody#length returns the correct number of table bodies (page context)' > undefined method `body' for # > ./spec/watirspec/table_body_spec.rb:65: > 83) > NoMethodError in 'TableBody#length returns the correct number of table bodies (table context)' > undefined method `length' for nil:NilClass > Z:/git/watir/watir/lib/watir/table.rb:256:in `length' > ./spec/watirspec/table_body_spec.rb:70: > 84) > NoMethodError in 'TableBody#[] returns the row at the given index (page context)' > undefined method `body' for # > ./spec/watirspec/table_body_spec.rb:77: > 72) > NoMethodError in 'TableBodies#length returns the correct number of table bodies (page context)' > undefined method `bodies' for # > ./spec/watirspec/table_bodies_spec.rb:12: > 73) > NoMethodError in 'TableBodies#[] returns the row at the given index (page context)' > undefined method `bodies' for # > ./spec/watirspec/table_bodies_spec.rb:22: > 74) > NoMethodError in 'TableBodies#each iterates through table bodies correctly (table context)' > undefined method `bodies' for # > ./spec/watirspec/table_bodies_spec.rb:34: -- 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 Oct 27 15:42:23 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:23 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-363) watirspec: SelectList#select return value Message-ID: <33488419.268.1288208543713.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-363: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: SelectList#select return value > ----------------------------------------- > > Key: WTR-363 > URL: http://jira.openqa.org/browse/WTR-363 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 66) > 'SelectList#select returns the value selected' FAILED > expected: "Danish", > got: nil (using ==) > ./spec/watirspec/select_list_spec.rb:268: > 67) > 'SelectList#select returns the first matching value if there are multiple matches' FAILED > expected: "Danish", > got: nil (using ==) > ./spec/watirspec/select_list_spec.rb:272: > 68) -- 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 Oct 27 15:42:23 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:23 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-358) watirspec: tfoot, tfoots, thead, theads not implemented Message-ID: <24657509.278.1288208543925.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-358: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: tfoot, tfoots, thead, theads not implemented > ------------------------------------------------------- > > Key: WTR-358 > URL: http://jira.openqa.org/browse/WTR-358 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 88) > NoMethodError in 'TableFooter#exists returns true if the table tfoot exists (page context)' > undefined method `tfoot' for # > ./spec/watirspec/table_footer_spec.rb:12: > 89) > NoMethodError in 'TableFooter#exists returns true if the table tfoot exists (table context)' > undefined method `tfoot' for # > ./spec/watirspec/table_footer_spec.rb:19: > 90) > NoMethodError in 'TableFooter#exists returns true if the element exists (default how = :id)' > undefined method `tfoot' for # > ./spec/watirspec/table_footer_spec.rb:26: > 91) > NoMethodError in 'TableFooter#exists returns false if the table tfoot exists (page context)' > undefined method `tfoot' for # > ./spec/watirspec/table_footer_spec.rb:31: > 92) > NoMethodError in 'TableFooter#exists returns false if the table tfoot exists (table context)' > undefined method `tfoot' for # > ./spec/watirspec/table_footer_spec.rb:38: > 93) > 'TableFooter#exists raises TypeError when 'what' argument is invalid' FAILED > expected TypeError, got #> > ./spec/watirspec/table_footer_spec.rb:45: > 94) > 'TableFooter#exists raises MissingWayOfFindingObjectException when 'how' argument is invalid' FAILED > expected Watir::Exception::MissingWayOfFindingObjectException, got #> > ./spec/watirspec/table_footer_spec.rb:50: > 95) > NoMethodError in 'TableFooter#length returns the correct number of table bodies (page context)' > undefined method `tfoot' for # > ./spec/watirspec/table_footer_spec.rb:57: > 96) > NoMethodError in 'TableFooter#length returns the correct number of table bodies (table context)' > undefined method `tfoot' for # > ./spec/watirspec/table_footer_spec.rb:61: > 97) > NoMethodError in 'TableFooter#[] returns the row at the given index (page context)' > undefined method `tfoot' for # > ./spec/watirspec/table_footer_spec.rb:67: > 98) > NoMethodError in 'TableFooter#[] returns the row at the given index (table context)' > undefined method `tfoot' for # > ./spec/watirspec/table_footer_spec.rb:73: > 99) > NoMethodError in 'TableFooter#each iterates through rows correctly' > undefined method `tfoot' for # > ./spec/watirspec/table_footer_spec.rb:81: > 100) > NoMethodError in 'TableFooters#length returns the correct number of table tfoots (page context)' > undefined method `tfoots' for # > ./spec/watirspec/table_footers_spec.rb:12: > 101) > NoMethodError in 'TableFooters#length returns the correct number of table tfoots (table context)' > undefined method `tfoots' for # > ./spec/watirspec/table_footers_spec.rb:16: > 102) > NoMethodError in 'TableFooters#[] returns the row at the given index (page context)' > undefined method `tfoots' for # > ./spec/watirspec/table_footers_spec.rb:22: > 103) > NoMethodError in 'TableFooters#[] returns the row at the given index (table context)' > undefined method `tfoots' for # > ./spec/watirspec/table_footers_spec.rb:26: > 104) > NoMethodError in 'TableFooters#each iterates through table tfoots correctly (page context)' > undefined method `tfoots' for # > ./spec/watirspec/table_footers_spec.rb:32: > 105) > NoMethodError in 'TableFooters#each iterates through table tfoots correctly (table context)' > undefined method `tfoots' for # > ./spec/watirspec/table_footers_spec.rb:40: > 106) > NoMethodError in 'TableHeader#exists returns true if the table theader exists (page context)' > undefined method `thead' for # > ./spec/watirspec/table_header_spec.rb:12: > 107) > NoMethodError in 'TableHeader#exists returns true if the table theader exists (table context)' > undefined method `thead' for # > ./spec/watirspec/table_header_spec.rb:19: > 108) > NoMethodError in 'TableHeader#exists returns true if the element exists (default how = :id)' > undefined method `thead' for # > ./spec/watirspec/table_header_spec.rb:26: > 109) > NoMethodError in 'TableHeader#exists returns false if the table theader exists (page context)' > undefined method `thead' for # > ./spec/watirspec/table_header_spec.rb:31: > 110) > NoMethodError in 'TableHeader#exists returns false if the table theader exists (table context)' > undefined method `thead' for # > ./spec/watirspec/table_header_spec.rb:38: > 111) > 'TableHeader#exists raises TypeError when 'what' argument is invalid' FAILED > expected TypeError, got #> > ./spec/watirspec/table_header_spec.rb:45: > 112) > 'TableHeader#exists raises MissingWayOfFindingObjectException when 'how' argument is invalid' FAILED > expected Watir::Exception::MissingWayOfFindingObjectException, got #> > ./spec/watirspec/table_header_spec.rb:50: > 113) > NoMethodError in 'TableHeader#length returns the correct number of table bodies (page context)' > undefined method `thead' for # > ./spec/watirspec/table_header_spec.rb:57: > 114) > NoMethodError in 'TableHeader#length returns the correct number of table bodies (table context)' > undefined method `thead' for # > ./spec/watirspec/table_header_spec.rb:61: > 115) > NoMethodError in 'TableHeader#[] returns the row at the given index (page context)' > undefined method `thead' for # > ./spec/watirspec/table_header_spec.rb:67: > 116) > NoMethodError in 'TableHeader#[] returns the row at the given index (table context)' > undefined method `thead' for # > ./spec/watirspec/table_header_spec.rb:73: > 117) > NoMethodError in 'TableHeader#each iterates through rows correctly' > undefined method `thead' for # > ./spec/watirspec/table_header_spec.rb:81: > 118) > NoMethodError in 'TableHeaders#length returns the correct number of table theads (page context)' > undefined method `theads' for # > ./spec/watirspec/table_headers_spec.rb:12: > 119) > NoMethodError in 'TableHeaders#length returns the correct number of table theads (table context)' > undefined method `theads' for # > ./spec/watirspec/table_headers_spec.rb:16: > 120) > NoMethodError in 'TableHeaders#[] returns the row at the given index (page context)' > undefined method `theads' for # > ./spec/watirspec/table_headers_spec.rb:22: > 121) > NoMethodError in 'TableHeaders#[] returns the row at the given index (table context)' > undefined method `theads' for # > ./spec/watirspec/table_headers_spec.rb:26: > 122) > NoMethodError in 'TableHeaders#each iterates through table theads correctly (page context)' > undefined method `theads' for # > ./spec/watirspec/table_headers_spec.rb:32: > 123) > NoMethodError in 'TableHeaders#each iterates through table theads correctly (table context)' > undefined method `theads' for # > ./spec/watirspec/table_headers_spec.rb:40: -- 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 Oct 27 15:42:23 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:23 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-394) Basic Authenticaiton Message-ID: <11346119.258.1288208543258.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-394: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > Basic Authenticaiton > -------------------- > > Key: WTR-394 > URL: http://jira.openqa.org/browse/WTR-394 > Project: Watir > Issue Type: Bug > Components: FireWatir > Affects Versions: Open QA Migration > Environment: any > Reporter: Zeljko > Assignee: Angrez > Fix For: Soon > > > - moved from http://code.google.com/p/firewatir/issues/detail?id=73 > Issue 73: Basic Authenticaiton > 2 people starred this issue and may be notified of changes. > Status: New > Owner: ---- > Type-Defect > Priority-Medium > Reported by mfurrer, Jul 06, 2008 > Sorry, this is not a bug, rather a question / feature request. > I have a need to do basic authentication with firewatir, I cannot find > anywhere in the documentation or in Google a way of doing it. > So is there a solution ? > If not is there a workaround ? > Thanks for your help. > Marc. > --- > > Comment 1 by angrez, Jul 06, 2008 > Can you give some example of what you want Firewatir to do for you? > --- > > Comment 2 by lastobelus, Oct 05, 2009 > he means basic authentication: entering username & password for standard htttp basic auth. -- 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 Oct 27 15:42:24 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:24 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-346) watirspec-pending: Image#{width, height, file_size} should return Integer Message-ID: <9860683.302.1288208544861.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-346: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec-pending: Image#{width,height,file_size} should return Integer > ------------------------------------------------------------------------ > > Key: WTR-346 > URL: http://jira.openqa.org/browse/WTR-346 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 34) > 'Image#file_size returns the file size of the image if the image exists' FAILED > expected: 788, > got: "788" (using ==) > ./spec/watirspec/image_spec.rb:155: -- 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 Oct 27 15:42:24 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:24 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-348) watirspec: Browser#status does not return the value of window.status Message-ID: <19828908.298.1288208544743.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-348: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: Browser#status does not return the value of window.status > -------------------------------------------------------------------- > > Key: WTR-348 > URL: http://jira.openqa.org/browse/WTR-348 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 2) > 'Browser#status returns the current value of window.status' FAILED > expected: "All done!", > got: "Done" (using ==) > ./spec/watirspec/browser_spec.rb:40: -- 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 Oct 27 15:42:23 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:23 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-360) watirspec: TableBodies#each_with_index not implemented (not Enumerable?) Message-ID: <21412832.274.1288208543841.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-360: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: TableBodies#each_with_index not implemented (not Enumerable?) > ------------------------------------------------------------------------ > > Key: WTR-360 > URL: http://jira.openqa.org/browse/WTR-360 > Project: Watir > Issue Type: Sub-task > Components: Gem installer > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 75) > NoMethodError in 'TableBodies#each iterates through table bodies correctly (table context)' > undefined method `each_with_index' for # > ./spec/watirspec/table_bodies_spec.rb:42: -- 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 Oct 27 15:42:23 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:23 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-365) watirspec: no default how for Link Message-ID: <30493593.264.1288208543570.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-365: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: no default how for Link > ---------------------------------- > > Key: WTR-365 > URL: http://jira.openqa.org/browse/WTR-365 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 10) > TypeError in 'Link#exist? returns true if the element exists (default how = :href)' > expected [String, Regexp, Fixnum, Watir::Element], got nil:NilClass > Z:/git/watir/watir/lib/watir/locator.rb:21:in `normalize_specifiers!' > Z:/git/watir/watir/lib/watir/locator.rb:7:in `each' > Z:/git/watir/watir/lib/watir/locator.rb:7:in `normalize_specifiers!' > Z:/git/watir/watir/lib/watir/locator.rb:45:in `set_specifier' > Z:/git/watir/watir/lib/watir/container.rb:823:in `locate_tagged_element' > Z:/git/watir/watir/lib/watir/link.rb:24:in `locate' > Z:/git/watir/watir/lib/watir/element.rb:279:in `exist?' > ./spec/watirspec/link_spec.rb:28: -- 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 Oct 27 15:42:24 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:24 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-344) watirspec: elements_by_xpath should support wildcard xpaths Message-ID: <8970497.306.1288208544980.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-344: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: elements_by_xpath should support wildcard xpaths > ----------------------------------------------------------- > > Key: WTR-344 > URL: http://jira.openqa.org/browse/WTR-344 > Project: Watir > Issue Type: Sub-task > Components: Xpath Support > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 9) > 'Browser#elements_by_xpath returns an Array of matching elements' FAILED > expected nil to be a kind of Array > ./spec/watirspec/browser_spec.rb:232: -- 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 Oct 27 15:42:24 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:24 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-347) watirspec-pending: Can't locate image by :src when given the exact attribute string Message-ID: <31280257.300.1288208544780.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-347: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec-pending: Can't locate image by :src when given the exact attribute string > ----------------------------------------------------------------------------------- > > Key: WTR-347 > URL: http://jira.openqa.org/browse/WTR-347 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 31) > 'Image#exists? returns true when the image exists' FAILED > expected # to exist > ./spec/watirspec/image_spec.rb:17: > 32) > 'Image#exists? returns true if the element exists (default how = :src)' FAILED > expected # to exist > ./spec/watirspec/image_spec.rb:25: -- 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 Oct 27 15:42:27 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:27 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-166) Document how to use the add_checker method to add custom wait logic to Watir Message-ID: <8564067.381.1288208547895.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-166: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > Document how to use the add_checker method to add custom wait logic to Watir > ---------------------------------------------------------------------------- > > Key: WTR-166 > URL: http://jira.openqa.org/browse/WTR-166 > Project: Watir > Issue Type: New Feature > Components: Wait > Affects Versions: 1.5.0/1.5.1 > Environment: x > Reporter: Jeff Fry > Assignee: Bret Pettichord > Priority: Major > Fix For: Soon > > > Watir.wait() listens to whether IE thinks its done loading, and then checks to see that the main document and any sub documents/frames have finished loading. More and more, there are pages that on load also kick off various XHRs and timers. For me - and possibly for a growing number of folks, testing more AJAXy applications - it would be great to expand wait() to check if there are any XHRs or timers pending, in additional to the checks it currently makes. > Note, I don't know, but there may be applications where an XHR is intentionally left open at all times. If this happens I would guess that it's rare, but if we change the default behavior of watir.wait() to wait for pending XHRs and timers, we might want to give a config option that turns this off as well. -- 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 Oct 27 15:42:23 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:23 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-359) watirspec: TableRow#{child_cell, each_with_index} not implemented Message-ID: <27235683.276.1288208543883.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-359: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: TableRow#{child_cell,each_with_index} not implemented > ---------------------------------------------------------------- > > Key: WTR-359 > URL: http://jira.openqa.org/browse/WTR-359 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 126) > NoMethodError in 'TableRow#child_cell returns the nth cell of the parent row' > undefined method `child_cell' for # > ./spec/watirspec/table_row_spec.rb:77: > 127) > 'TableRow#child_cell raises UnknownCellException if the index is out of bounds' FAILED > expected Watir::Exception::UnknownCellException, got #> > ./spec/watirspec/table_row_spec.rb:83: > 128) > NoMethodError in 'TableRow#each iterates correctly through the cells of the row' > undefined method `each_with_index' for # > ./spec/watirspec/table_row_spec.rb:90: -- 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 Oct 27 15:42:23 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:23 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-414) Using modal_dialog by specifying title doesn't work in IE8 as modal dialog has changed to "Webpage Dialog" Message-ID: <13702649.255.1288208543124.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-414: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > Using modal_dialog by specifying title doesn't work in IE8 as modal dialog has changed to "Webpage Dialog" > ---------------------------------------------------------------------------------------------------------- > > Key: WTR-414 > URL: http://jira.openqa.org/browse/WTR-414 > Project: Watir > Issue Type: Bug > Components: Modal Windows Dialogs > Affects Versions: 1.6.5 > Environment: Windows Vista, IE8 > Reporter: Alister Scott > Fix For: Soon > > Attachments: modal IE8.jpg, modal_dialog.rb > > > When specifying the title of a modal_dialog, using IE 8, the suffix has changed from "Web Page Dialog" to "Webpage Dialog". > I updated line 46 of modal_dialog.rb to use this new description (see attached), but not sure how to add backwards compatibility. -- 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 Oct 27 15:42:24 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:24 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-345) watirspec: h1s..h6s collections not implemented Message-ID: <6312004.304.1288208544937.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-345: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: h1s..h6s collections not implemented > ----------------------------------------------- > > Key: WTR-345 > URL: http://jira.openqa.org/browse/WTR-345 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 28) > NoMethodError in 'H1s H2s H3s H4s H5s H6s#length returns the number of h1s' > undefined method `h2s' for # > ./spec/watirspec/hns_spec.rb:12: > 29) > NoMethodError in 'H1s H2s H3s H4s H5s H6s#[] returns the h1 at the given index' > undefined method `h1s' for # > ./spec/watirspec/hns_spec.rb:18: > 30) > NoMethodError in 'H1s H2s H3s H4s H5s H6s#each iterates through header collections correctly' > undefined method `h1s' for # > ./spec/watirspec/hns_spec.rb:25:in `send' > ./spec/watirspec/hns_spec.rb:25: > ./spec/watirspec/hns_spec.rb:18:in `collect' > ./spec/watirspec/hns_spec.rb:24:in `each' > ./spec/watirspec/hns_spec.rb:24:in `collect' > ./spec/watirspec/hns_spec.rb:24: -- 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 Oct 27 15:42:24 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:24 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-349) watirspec: Buttons#last and Buttons#length fails Message-ID: <16511649.296.1288208544706.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-349: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: Buttons#last and Buttons#length fails > ------------------------------------------------ > > Key: WTR-349 > URL: http://jira.openqa.org/browse/WTR-349 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 10) > 'Buttons#length returns the number of buttons' FAILED > expected: 8, > got: 6 (using ==) > ./spec/watirspec/buttons_spec.rb:12: > 11) > Watir::Exception::UnknownObjectException in 'Buttons#last returns the last element in the collection' > Unable to locate Button, using :index and 0 > Z:/git/watir/watir/lib/watir/element.rb:55:in `assert_exists' > (eval):2:in `value' > ./spec/watirspec/buttons_spec.rb:30: -- 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 Oct 27 15:42:28 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:28 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-66) IE#Frame.show_frames doesn't work Message-ID: <14661934.394.1288208548643.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-66: ----------------------------- Fix Version/s: (was: 1.6.7) Soon > IE#Frame.show_frames doesn't work > --------------------------------- > > Key: WTR-66 > URL: http://jira.openqa.org/browse/WTR-66 > Project: Watir > Issue Type: Bug > Components: Frame > Affects Versions: 1.5.0/1.5.1 > Environment: Watir 1.5.0.993 on Branch: modal_dialog > Reporter: David Schmidt > Fix For: Soon > > > Frame.show_frames no longer works. Since frames may contain sub-frames, the "show_frames" method (and probably other "show" methods) should be in module Container rather than class IE: > irb(main):101:0> ie.frame('Main').show_all_frames > NoMethodError: undefined method `show_all_frames' for # > from (irb):101 > from ?:0 > After moving show methods to module Container it works fine: > irb(main):004:0> ie.frame('Main').show_frames > there are 6 frames > frame index: 1 name: navigator > frame index: 2 name: cookies > frame index: 3 name: Header > frame index: 4 name: workarea > frame index: 5 name: IFSCommArea > frame index: 6 name: toolbar -- 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 Oct 27 15:42:28 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:28 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-28) show_all_objects only shows some objects -- it should be renamed Message-ID: <11963572.399.1288208548946.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-28: ----------------------------- Fix Version/s: (was: 1.6.7) Soon > show_all_objects only shows some objects -- it should be renamed > ---------------------------------------------------------------- > > Key: WTR-28 > URL: http://jira.openqa.org/browse/WTR-28 > Project: Watir > Issue Type: Bug > Reporter: Charley Baker > Fix For: Soon > > Attachments: WTR-28.zip > > > show_all_objects only shows some objects -- it should be renamed -- 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 Oct 27 15:42:23 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:23 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-364) watirspec: 'SelectList#select shouldn't fire onchange event when selecting an already selected item' Message-ID: <8466808.266.1288208543641.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-364: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: 'SelectList#select shouldn't fire onchange event when selecting an already selected item' > ---------------------------------------------------------------------------------------------------- > > Key: WTR-364 > URL: http://jira.openqa.org/browse/WTR-364 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Fix For: Soon > > > 'SelectList#select doesn't fire onchange event when selecting an already selected item' FAILED > expected: 3, > got: 1 (using ==) > ./spec/watirspec/select_list_spec.rb:283: -- 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 Oct 27 15:42:23 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:23 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-362) watirspec: `SelectList#{select, select_value}` should select multiple items when given (:name, /regexp/) Message-ID: <20118177.270.1288208543753.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-362: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: `SelectList#{select,select_value}` should select multiple items when given (:name, /regexp/) > ------------------------------------------------------------------------------------------------------- > > Key: WTR-362 > URL: http://jira.openqa.org/browse/WTR-362 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 64) > 'SelectList#select selects multiple items using :name and a Regexp' FAILED > expected: ["Danish", "English", "Swedish"], > got: ["Danish"] (using ==) > ./spec/watirspec/select_list_spec.rb:253: > 65) > 'SelectList#select selects multiple items using :xpath' FAILED > expected: ["Danish", "English", "Swedish"], > got: ["Danish"] (using ==) > ./spec/watirspec/select_list_spec.rb:259: > 69) > 'SelectList#select_value selects the items by value regexp' FAILED > expected: ["Danish", "Norwegian"], > got: ["Danish"] (using ==) > ./spec/watirspec/select_list_spec.rb:305: -- 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 Oct 27 15:42:28 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:28 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-43) Add new frames methods Message-ID: <19792593.397.1288208548814.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-43: ----------------------------- Fix Version/s: (was: 1.6.7) Soon > Add new frames methods > ---------------------- > > Key: WTR-43 > URL: http://jira.openqa.org/browse/WTR-43 > Project: Watir > Issue Type: Improvement > Components: Frame > Affects Versions: 1.5.4 > Reporter: Charley Baker > Fix For: Soon > > > Exists method should be useful > ie.frame(:name, 'foo').exists? > adding src as a way of finding frames should also be useful > ie.frame(:src, /foo/).exists? > Iterators for frames would make it more compatible with the rest of the api > ie.frames.each do |f| > Originally reported on Rubyforge: http://rubyforge.org/tracker/index.php?func=detail&aid=1860&group_id=104&atid=1999 -- 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 Oct 27 15:42:28 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:28 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-93) ie.divs.show not working Message-ID: <31100431.392.1288208548489.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-93: ----------------------------- Fix Version/s: (was: 1.6.7) Soon > ie.divs.show not working > ------------------------ > > Key: WTR-93 > URL: http://jira.openqa.org/browse/WTR-93 > Project: Watir > Issue Type: Bug > Components: HTML Controls > Affects Versions: 1.5.0/1.5.1 > Environment: Microsoft Windows XP Professional, Version: 5.1.2600, Service Pack: 2.0 > ruby 1.8.4 (2006-04-14) [i386-mswin32] > watir-1.5.1.1065 > Reporter: Zeljko > Priority: Major > Fix For: Soon > > > - go to irb > irb(main):001:0> require 'watir' > => true > irb(main):002:0> ie = Watir::IE.start("http://www.yahoo.com/") > => # [...] > > > irb(main):003:0> ie.divs.show > index id className > 1 > 2 > [...] > 74 > 75 > => nil > - only indexes are printed, all ids are empty > - this is snippet of html of that page (divs have ids) > [...] >
          >
          >
          >
          >
          > [...] -- 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 Oct 27 19:17:20 2010 From: watirjira at gmail.com (Bret Pettichord (JIRA)) Date: Wed, 27 Oct 2010 18:17:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-224) FireWatir support for Multiple Browsers [patch] Message-ID: <17653523.406.1288221440288.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19962#action_19962 ] Bret Pettichord commented on WTR-224: ------------------------------------- Alex, Can you comment on whether you (or any one else) is planning to complete this work? Bret > FireWatir support for Multiple Browsers [patch] > ----------------------------------------------- > > Key: WTR-224 > URL: http://jira.openqa.org/browse/WTR-224 > Project: Watir > Issue Type: New Feature > Components: FireWatir > Reporter: Bret Pettichord > Priority: Major > Fix For: Soon > > > patch for multiple browsers from http://pastie.caboo.se/111648 firewatir group post: http://groups.google.com/group/firewatir/browse_thread/thread/9111c7a10f119a13 > see also commit 134 to the firewatir/googlecode repository, where this was initially comitted (before being backed out). -- 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 Oct 27 15:42:24 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:24 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-355) watirspec: `Form` should accept 'class' as how argument Message-ID: <26047059.284.1288208544282.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-355: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: `Form` should accept 'class' as how argument > ------------------------------------------------------- > > Key: WTR-355 > URL: http://jira.openqa.org/browse/WTR-355 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 25) > Watir::Exception::MissingWayOfFindingObjectException in 'Form#exists? returns true if the form exists' > class is an unknown way of finding a form (user) > Z:/git/watir/watir/lib/watir/form.rb:62:in `initialize' > Z:/git/watir/watir/lib/watir/form.rb:51:in `each' > Z:/git/watir/watir/lib/watir/form.rb:51:in `initialize' > Z:/git/watir/watir/lib/watir/container.rb:116:in `new' > Z:/git/watir/watir/lib/watir/container.rb:116:in `form' > ./spec/watirspec/form_spec.rb:14: > 26) > Watir::Exception::MissingWayOfFindingObjectException in 'Form#exists? returns false if the form doesn't exist' > class is an unknown way of finding a form (no_such_class) > Z:/git/watir/watir/lib/watir/form.rb:62:in `initialize' > Z:/git/watir/watir/lib/watir/form.rb:51:in `each' > Z:/git/watir/watir/lib/watir/form.rb:51:in `initialize' > Z:/git/watir/watir/lib/watir/container.rb:116:in `new' > Z:/git/watir/watir/lib/watir/container.rb:116:in `form' > ./spec/watirspec/form_spec.rb:31: -- 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 Oct 27 15:42:23 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:23 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-361) watirspec: Label's default how should be :text Message-ID: <32474021.272.1288208543792.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-361: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: Label's default how should be :text > ---------------------------------------------- > > Key: WTR-361 > URL: http://jira.openqa.org/browse/WTR-361 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 35) > 'Label#exists? returns true if the element exists (default how = :text)' FAILED > expected # to exist > ./spec/watirspec/label_spec.rb:22: -- 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 Oct 27 15:42:28 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:28 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-23) show_tables needs a rescue Message-ID: <1369300.401.1288208548993.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-23: ----------------------------- Fix Version/s: (was: 1.6.7) Soon > show_tables needs a rescue > -------------------------- > > Key: WTR-23 > URL: http://jira.openqa.org/browse/WTR-23 > Project: Watir > Issue Type: Bug > Components: HTML Controls > Reporter: Charley Baker > Fix For: Soon > > > add a begin/rescue around the columns=#{d.rows["0"].cells.length > code > I guess sometimes row(0) doesnt work - maybe its a th > WIN32OLERuntimeError: Unknown property or method `0' > HRESULT error code:0x80020006 > Unknown name. > from c:/ruby/lib/ruby/site_ruby/1.8/watir.rb:1678:in `[]' > from c:/ruby/lib/ruby/site_ruby/1.8/watir.rb:1678:in > ignore the line numbers, they are from an old version -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Wed Oct 27 15:42:29 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:29 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-15) OnBlur event is not being fired when select from a selectBox control. Message-ID: <26114084.404.1288208549252.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-15: ----------------------------- Fix Version/s: (was: 1.6.7) Soon > OnBlur event is not being fired when select from a selectBox control. > --------------------------------------------------------------------- > > Key: WTR-15 > URL: http://jira.openqa.org/browse/WTR-15 > Project: Watir > Issue Type: Bug > Components: HTML Controls > Affects Versions: 1.4.1, 1.5.0/1.5.1 > Environment: Windows XP SP2 and IE 6 > Reporter: MarkC > Assignee: Bret Pettichord > Priority: Major > Fix For: Soon > > > > The developer put an 'OnBlur' event behind the selecting from the > > troublesome dropdown, which would populate a form variable with the value of > > the selection. That event was not happening in my script (not sure how > > Watir does it but you actually have to give the select list focus in order > > for the OnBlur event to fire, or call the event explicitly). When I added > > this line to my script >>$ie.selectBox( :name, > > "myProjectID2").fireEvent("OnBlur")<< then it set the > > variable and would not reset the value > The OnBlur event is not being fired after selecting a value from a selectBox. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From bret at pettichord.com Wed Oct 27 19:49:09 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 27 Oct 2010 18:49:09 -0500 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: On Wed, Oct 27, 2010 at 2:08 PM, Jarmo wrote: > Well, you're gonna extract that logic into method anyway hopefully so > i don't see any problems. > > Bret, i just reviewed your code and noticed 3 things in addition to > the method name itself: > 1) why did you create separate file called origin.rb for that? > couldn't you use options.rb in similar way as it's used for :speed > now? > I'm keeping it simple right now. If there is a general desire for more ways to set Watir.index_base (yes, i'll change the name), then we can always add it. My sense is that most of the interfaces supported by options.rb (env var, yaml file) are ignored right now anyway. Maybe no one knows about them? 2) usage of global variable $ORIGIN... i'd not recommend using global > variables at all, there's too many in tests already... could use > Watir.orgin instead > I agree. I'll fix this before merging. > 3) let's not change tests at all, but just create some new test for > specifically testing that Watir.origin (or whatever it's called) works > as expected. All other index-based tests could stay as they are and > work with default indexing (so, 1 for now). I don't see much of a > point in modifying all tests to subtract or add 1. What do you think? > Yeah, that's what we did with the firewatir unit tests and now we have two slightly different tests for everything. Quite a nightmare. Also, we will eventually need to convert all the tests to use the new base anyway if we are going to change the default, so this doesn't feel like extra work to me. Right now I'm still discovering all the places where I need to make changes. And I'm doing that by running the tests and then revising them. Maybe your point is that we also need a few tests to verify that the non-default setting works whenever we run the standard suite? That makes sense to me. Bret Jarmo > > On Wed, Oct 27, 2010 at 9:12 PM, Ethan wrote: > > I think it makes more sense for a user to specify 0 or 1 as the index > they > > want to start at. It also makes the code simpler to deal with (on the > watir > > side - not on the user's side) - adding or subtracting index_offset > rather > > than adding or subtracting (zero_based_indexing ? 0 : 1). > > > > On Wed, Oct 27, 2010 at 12:00, Jarmo wrote: > >> > >> What's wrong with the very non-obscure boolean as i suggested before? > >> > >> If i'd be a newcomer and come to Watir then all those > >> "indexing_origin", "origin", "base_index" wouldn't make sense to me. > >> Jari's "index_offset" would be least obscure if i'd stumble it in the > >> code. > >> > >> I'd remove the "use" from my recommendation and put it like > >> Watir.zero_based_indexing = true > >> > >> I don't personally think that using "0" and "1" makes more sense, > >> especially for the people who don't know the problem of 1-based > >> indexing itself. Why not make the name and usage of the method > >> self-explanatory? > >> > >> Jarmo > >> > >> On Wed, Oct 27, 2010 at 5:53 PM, Bret Pettichord > >> wrote: > >> > I think that it is easier to understand if the values are 0 and 1, > than > >> > true > >> > and false. I'm happy to put a guard on it to prevent it from being set > >> > to > >> > other values. > >> > > >> > Is this easier to understand? > >> > > >> > Watir.indexing_origin = 0 > >> > > >> > I'm also finding the ability to use Watir.origin in the tests to be > >> > quite > >> > handy and suspect that I'll use the same technique in our test suite > as > >> > we > >> > prepare to convert, which will not be trivial. This really begs to be > >> > noun. > >> > And Watir.index_base seems to me to be even more obscure. But maybe > >> > that's > >> > just me? > >> > > >> > Bret > >> > > >> > > >> > On Wed, Oct 27, 2010 at 2:50 AM, Jarmo wrote: > >> >> > >> >> I'd change #origin to something more explanatory... Since it will be > >> >> more or less a temporary option since there is plan to make 0 to > >> >> default in the future then we could have some better explanatory > name. > >> >> Also, why not just make it a boolean? I don't think that someone > likes > >> >> to set it to something else than 0 or 1... so I'd suggest something > in > >> >> the lines of: > >> >> Watir.use_zero_based_indexing = true > >> >> > >> >> Jarmo > >> >> > >> >> 2010/10/27 Bret Pettichord : > >> >> > This weekend I started updating Watir so that it could be > configured > >> >> > to > >> >> > use > >> >> > either a one or zero-based index. You turn on zero-indexing using > >> >> > this > >> >> > command: > >> >> > > >> >> > Watir.origin = 0 > >> >> > > >> >> > I am doing this work right now on a topic branch (I didn't want to > >> >> > interfere > >> >> > with the 1.6.7 release) and with your consent will merge it into > >> >> > master > >> >> > when > >> >> > it is complete. > >> >> > > >> >> > I have a number of tests working with the origin so far, but there > >> >> > are > >> >> > lots > >> >> > of hidden places where this has an effect (iterators, tables). I > >> >> > expect > >> >> > this > >> >> > will be done in a week or two or so. > >> >> > > >> >> > Appreciate your comments on this. Work in progress is here: > >> >> > > >> >> > http://github.com/bret/watir/commits/zero-index > >> >> > > >> >> > > >> >> > It seems like there is a pending interest in making a release that > >> >> > removes > >> >> > support for some deprecated features. That would need to be a 1.7.0 > >> >> > release > >> >> > -- to hold to the semantic naming, as I would like. > >> >> > > >> >> > I would like like to release the configurable-index-origin feature > in > >> >> > a > >> >> > release that does not change the default. However, in a later > >> >> > release, I > >> >> > think we will want to change Watir to use a zero-based origin. > >> >> > > >> >> > > >> >> > Today, at the office, we were also looking at using Watir with a > >> >> > newer > >> >> > version of Ruby. We are using Ruby 1.8.6 p287 (IIRC). Not sure > >> >> > entirely > >> >> > what > >> >> > is holding us from using the latest version of 1.8.6 or 1.8.7. Are > we > >> >> > still > >> >> > running into problems with the Win32 gems? Is anyone using Watir's > >> >> > showModalDialog support with a newer version of Ruby? Any way, I'd > >> >> > like > >> >> > to > >> >> > see if I can get this sorted out. > >> >> > > >> >> > > >> >> > Bret > >> >> > > >> >> > > >> >> > On Tue, Oct 26, 2010 at 4:11 PM, Charley Baker > >> >> > > >> >> > wrote: > >> >> >> > >> >> >> Agreed, we can do it better, the rolling releases and getting > those > >> >> >> going has been a priority just to make sure we can step it up a > bit. > >> >> >> After so much inactivity, I feel comfortable with the overall > >> >> >> workflow > >> >> >> again. > >> >> >> > >> >> >> Let's prioritize JIRA issues and move them into this next > release. > >> >> >> If anyone would like to step up and help out, feel free to let me > >> >> >> know. Obviously you're welcome to make pull requests, and edit > JIRA > >> >> >> at > >> >> >> will. We should have a better idea of what's going in the next > >> >> >> release > >> >> >> in the next day or two. > >> >> >> > >> >> >> Cheers, > >> >> >> > >> >> >> Charley Baker > >> >> >> Lead Developer, Watir, http://watir.com > >> >> >> > >> >> >> > >> >> >> > >> >> >> On Tue, Oct 26, 2010 at 1:57 PM, Jarmo wrote: > >> >> >> > It took 24 days to release new version. Woho! > >> >> >> > > >> >> >> > But i think that we could do it even better :) > >> >> >> > > >> >> >> > Agenda for the next version? > >> >> >> > > >> >> >> > Jarmo > >> >> >> > > >> >> >> > On Tue, Oct 26, 2010 at 10:37 PM, Charley Baker > >> >> >> > wrote: > >> >> >> >> Hello, everyone! > >> >> >> >> > >> >> >> >> Watir 1.6.7 got just released! > >> >> >> >> > >> >> >> >> > >> >> >> >> === General improvements > >> >> >> >> * added new waiting methods for Watir::Element: #when_present, > >> >> >> >> #wait_until_present and #wait_while_present (Jari Bakken and > >> >> >> >> Jarmo > >> >> >> >> Pertman) > >> >> >> >> * added new waiting methods for Watir::IE and Watir::Firefox: > >> >> >> >> #wait_until and #wait_while (Jari Bakken and Jarmo Pertman) > >> >> >> >> * added method #present? for Watir::Element (Jari Bakken and > >> >> >> >> Jarmo > >> >> >> >> Pertman) > >> >> >> >> * deprecated old waiting methods in Watir::Waiter which will be > >> >> >> >> removed in some future version - use Watir::Wait instead (Jarmo > >> >> >> >> Pertman) > >> >> >> >> > >> >> >> >> === IE improvements > >> >> >> >> * removed Watir::Simple (?eljko Filipin) > >> >> >> >> * #click_no_wait was not working with frame elements. Closes > >> >> >> >> http://jira.openqa.org/browse/WTR-459 (Jarmo Pertman) > >> >> >> >> > >> >> >> >> === Firefox improvements > >> >> >> >> * get_attribute_value now works with attributes named something > >> >> >> >> like > >> >> >> >> "foo-bar" (Alan Shields) > >> >> >> >> > >> >> >> >> === Cleanup & Maintenance > >> >> >> >> * cleaned up repo at GitHub > >> >> >> >> * merge licenses into one (?eljko Filipin) > >> >> >> >> * Rakefile works now under non-Windows systems too (Alan > Shields) > >> >> >> >> * Removed datahandler.rb (Charley Baker) > >> >> >> >> > >> >> >> >> Install it with: > >> >> >> >> > >> >> >> >> gem install watir > >> >> >> >> > >> >> >> >> And run your existing tests. > >> >> >> >> > >> >> >> >> If you're seeing any problems then don't forget to open a > ticket > >> >> >> >> at > >> >> >> >> JIRA (http://jira.openqa.org/browse/WTR) or fork the project > on > >> >> >> >> GitHub > >> >> >> >> (http://github.com/bret/watir) and send us a pull request with > >> >> >> >> the > >> >> >> >> fix! > >> >> >> >> If you have any problems installing Watir, then read more > >> >> >> >> detailed > >> >> >> >> instructions at http://watir.com/installation/ > >> >> >> >> > >> >> >> >> Watir Development Team > >> >> >> >> _______________________________________________ > >> >> >> >> Wtr-development mailing list > >> >> >> >> Wtr-development at rubyforge.org > >> >> >> >> http://rubyforge.org/mailman/listinfo/wtr-development > >> >> >> > _______________________________________________ > >> >> >> > Wtr-development mailing list > >> >> >> > Wtr-development at rubyforge.org > >> >> >> > http://rubyforge.org/mailman/listinfo/wtr-development > >> >> >> _______________________________________________ > >> >> >> Wtr-development mailing list > >> >> >> Wtr-development at rubyforge.org > >> >> >> http://rubyforge.org/mailman/listinfo/wtr-development > >> >> > > >> >> > > >> >> > -- > >> >> > Bret Pettichord > >> >> > Lead Developer, Watir, www.watir.com > >> >> > > >> >> > Blog, www.io.com/~wazmo/blog > >> >> > Twitter, www.twitter.com/bpettichord > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > Wtr-development mailing list > >> >> > Wtr-development at rubyforge.org > >> >> > http://rubyforge.org/mailman/listinfo/wtr-development > >> >> > > >> >> _______________________________________________ > >> >> Wtr-development mailing list > >> >> Wtr-development at rubyforge.org > >> >> http://rubyforge.org/mailman/listinfo/wtr-development > >> > > >> > > >> > -- > >> > Bret Pettichord > >> > Lead Developer, Watir, www.watir.com > >> > > >> > Blog, www.io.com/~wazmo/blog > >> > Twitter, www.twitter.com/bpettichord > >> > > >> > > >> > _______________________________________________ > >> > Wtr-development mailing list > >> > Wtr-development at rubyforge.org > >> > http://rubyforge.org/mailman/listinfo/wtr-development > >> > > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Wed Oct 27 15:42:23 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:23 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-366) watirspec: add Link#url as alias for Link#href Message-ID: <17957784.262.1288208543479.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-366: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: add Link#url as alias for Link#href > ---------------------------------------------- > > Key: WTR-366 > URL: http://jira.openqa.org/browse/WTR-366 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 12) > NoMethodError in 'Link#url returns the href attribute' > undefined method `url' for # > ./spec/watirspec/link_spec.rb:96: -- 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 Oct 27 15:42:24 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:24 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-353) watirspec: TextFields of type 'hidden' should not be visible Message-ID: <18032586.288.1288208544433.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-353: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: TextFields of type 'hidden' should not be visible > ------------------------------------------------------------ > > Key: WTR-353 > URL: http://jira.openqa.org/browse/WTR-353 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 23) > 'Element#visible? returns false if the element is input element where type == 'hidden'' FAILED > expected visible? to return false, got true > ./spec/watirspec/element_spec.rb:57: -- 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 Oct 27 15:42:24 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:24 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-352) watirspec: `Element#parent` should return the correct Watir object type if possible. Message-ID: <5201171.290.1288208544538.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-352: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: `Element#parent` should return the correct Watir object type if possible. > ------------------------------------------------------------------------------------ > > Key: WTR-352 > URL: http://jira.openqa.org/browse/WTR-352 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 22) > 'Element#parent gets the parent of this element' FAILED > expected # to be an instance of Watir::Form > ./spec/watirspec/element_spec.rb:47: -- 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 Oct 27 15:42:24 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:24 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-354) watirspec: `TableRow#length`, `Table#row_count`, `TableRows#length` should return the correct number of cells Message-ID: <11774401.286.1288208544366.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-354: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: `TableRow#length`,`Table#row_count`, `TableRows#length` should return the correct number of cells > ------------------------------------------------------------------------------------------------------------ > > Key: WTR-354 > URL: http://jira.openqa.org/browse/WTR-354 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 125) > 'TableRow#length returns the number of rows' FAILED > expected: 3, > got: 4 (using ==) > ./spec/watirspec/table_row_spec.rb:57: > 129) > 'TableRows#length returns the correct number of cells (table context)' FAILED > expected: 3, > got: 4 (using ==) > ./spec/watirspec/table_rows_spec.rb:13: > 131) > 'Table#row_count counts the number of rows correctly' FAILED > expected: 3, > got: 4 (using ==) > ./spec/watirspec/table_spec.rb:62: -- 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 Oct 27 15:42:24 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:24 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-356) watirspec: `Form#exists?` should raise TypeError on invalid 'what' argument. Message-ID: <4286135.282.1288208544019.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-356: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: `Form#exists?` should raise TypeError on invalid 'what' argument. > ---------------------------------------------------------------------------- > > Key: WTR-356 > URL: http://jira.openqa.org/browse/WTR-356 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Fix For: Soon > > > 27) > 'Form#exists? raises TypeError when 'what' argument is invalid' FAILED > expected TypeError, got # > ./spec/watirspec/form_spec.rb:42: -- 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 Oct 27 15:42:24 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:24 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-351) watirspec: Element.new raises ArgumentError with wrong message Message-ID: <27969065.292.1288208544593.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-351: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: Element.new raises ArgumentError with wrong message > -------------------------------------------------------------- > > Key: WTR-351 > URL: http://jira.openqa.org/browse/WTR-351 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 21) > 'Element.new raises ArgumentError if given the wrong number of arguments' FAILED > expected ArgumentError with "wrong number of arguments (4 for 2)", got # > ./spec/watirspec/element_spec.rb:23: -- 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 Oct 28 01:53:20 2010 From: watirjira at gmail.com (Alister Scott (JIRA)) Date: Thu, 28 Oct 2010 00:53:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-461) Typo in README.rdoc, mismatch with example code In-Reply-To: <22972864.242.1288179859977.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <24407407.409.1288245200884.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19963#action_19963 ] Alister Scott commented on WTR-461: ----------------------------------- Thanks. Updated the watir site also: http://watir.com/examples/ > Typo in README.rdoc, mismatch with example code > ------------------------------------------------ > > Key: WTR-461 > URL: http://jira.openqa.org/browse/WTR-461 > Project: Watir > Issue Type: Bug > Components: Documentation > Affects Versions: 1.6.6 > Environment: Any > Reporter: Stephan K?mper > > The README.rdoc (http://github.com/bret/watir/blob/master/README.rdoc) says: > Actual text: > > Setting and clearing a radio button > > > > browser.radio(:value => "watir").set > > browser.radio(:value => "watir".clear > Closing parenthesis is missing, should be > > browser.radio(:value => "watir").clear > Additionally the example page (http://bit.ly/watir-example) as given in the code/README actually is: > ... > >
          • > ... > This uses 'Watir' while the example code is 'watir' which in turn raises an exception: > > ... > > Watir::Exception::UnknownObjectException: Unable to locate element, using {:value=>"watir"} -- 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 Oct 27 15:42:24 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:24 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-350) watirspec-pending: Element#to_s does not include tag name Message-ID: <9665950.294.1288208544658.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-350: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec-pending: Element#to_s does not include tag name > --------------------------------------------------------- > > Key: WTR-350 > URL: http://jira.openqa.org/browse/WTR-350 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > Without the tag name, elements without attributes will return empty strings. > Perhaps we should decide on a new and better string representation of elements? > 12) > 'Dd#to_s returns a human readable representation of the element' FAILED > expected: "tag: dd\n id: someone\n class: name\n title: someone\n text: John Doe", > got: "type: \nid: someone\nname: \nvalue: \ndisabled: false\nclass: name\ntext: John Doe" (using ==) > ./spec/watirspec/dd_spec.rb:130: > 16) > 'Div#to_s returns a human readable representation of the element' FAILED > expected: "tag: div\n id: footer\n title: Closing remarks\n class: profile\n text: This is a footer.", > got: "type: \nid: footer\nname: \nvalue: \ndisabled: false\nclass: profile\ntext: This is a footer." (using ==) > ./spec/watirspec/div_spec.rb:226: > 18) > 'Dl#to_s returns a human readable representation of the element' FAILED > expected: "tag: dl\n id: experience-list\n class: list\n title: experience\n text: Experience 11 years Education Master Current industry Architecture Previous industry experience Architecture", > got: "type: \nid: experience-list\nname: \nvalue: \ndisabled: false\nclass: list\ntext: Experience \r\n11 years \r\nEducation \r\nMaster \r\nCurrent industry \r\nArchitecture \r\nPrevious industry experience \r\nArchitecture" (using ==) > ./spec/watirspec/dl_spec.rb:130: > 20) > 'Dt#to_s returns a human readable representation of the element' FAILED > expected: "tag: dt\n id: experience\n class: industry\n title: experience\n text: Experience", > got: "type: \nid: experience\nname: \nvalue: \ndisabled: false\nclass: industry\ntext: Experience" (using ==) > ./spec/watirspec/dt_spec.rb:130: > 24) > 'Em#to_s returns a human readable representation of the element' FAILED > expected: "tag: em\n class: important-class\n id: important-id\n title: ergo cogito\n text: ergo cogito", > got: "type: \nid: important-id\nname: \nvalue: \ndisabled: false\nclass: important-class\ntext: ergo cogito" (using ==) > ./spec/watirspec/em_spec.rb:104: > 42) > 'Map#to_s returns a human readable representation of the element' FAILED > expected: "tag: map\n id: triangle_map\n name: triangle_map", > got: "type: \nid: triangle_map\nname: triangle_map\nvalue: \ndisabled: false\nclass: \ntext: " (using ==) > ./spec/watirspec/map_spec.rb:86: > 60) > 'P#to_s returns a human readable representation of the element' FAILED > expected: "tag: p\n id: lead\n class: lead\n title: Lorem ipsum\n text: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Curabitur eu pede. Ut justo. Praesent feugiat, elit in feugiat iaculis, sem risus rutrum justo, eget fermentum dolor arcu non nunc.", > got: "type: \nid: lead\nname: \nvalue: \ndisabled: false\nclass: lead\ntext: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Curabitur eu pede. Ut justo. Praesent feugiat, elit in feugiat iaculis, sem risus rutrum justo, eget fermentum dolor arcu non nunc." (using ==) > ./spec/watirspec/p_spec.rb:155: > 61) > 'Pre#to_s returns a human readable representation of the element' FAILED > expected: "tag: pre", > got: "type: \nid: \nname: \nvalue: \ndisabled: false\nclass: \ntext: " (using ==) > ./spec/watirspec/pre_spec.rb:119: > 70) > 'Span#to_s returns a human readable representation of the element' FAILED > expected: "tag: span\n name: invalid_attribute\n value: invalid_attribute\n text: Sed pretium metus et quam. Nullam odio dolor, vestibulum non, tempor ut, vehicula sed, sapien. Vestibulum placerat ligula at quam. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.", > got: "type: \nid: \nname: invalid_attribute\nvalue: invalid_attribute\ndisabled: false\nclass: \ntext: Sed pretium metus et quam. Nullam odio dolor, vestibulum non, tempor ut, vehicula sed, sapien. Vestibulum placerat ligula at quam. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas." (using ==) > ./spec/watirspec/span_spec.rb:167: > 71) > 'Spans#to_s returns a human readable representation of the collection' FAILED > expected: "tag: span\n id: lead\n class: lead\n title: Lorem ipsum\n text: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Curabitur eu pede. Ut justo. Praesent feugiat, elit in feugiat iaculis, sem risus rutrum justo, eget fermentum dolor arcu non nunc.\ntag: span\n name: invalid_attribute\n value: invalid_attribute\n text: Sed pretium metus et quam. Nullam odio dolor, vestibulum non, tempor ut, vehicula sed, sapien. Vestibulum placerat ligula at quam. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.\ntag: span\n text: Suspendisse at ipsum a turpis viverra venenatis. Praesent ut nibh. Nullam eu odio. Donec tempor, elit ut lacinia porttitor, augue neque vehicula diam, in elementum ligula nisi a tellus. Aliquam vestibulum ultricies tortor.\ntag: span\n text: Dubito, ergo cogito, ergo sum.\ntag: span\ntag: span\n class: footer\n name: footer\n onclick: this.innerHTML = 'This is a footer with text set by Javascript.'\n text: This is a footer.", > got: "type: \nid: lead\nname: \nvalue: \ndisabled: false\nclass: lead\ntext: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Curabitur eu pede. Ut justo. Praesent feugiat, elit in feugiat iaculis, sem risus rutrum justo, eget fermentum dolor arcu non nunc.\ntype: \nid: \nname: invalid_attribute\nvalue: invalid_attribute\ndisabled: false\nclass: \ntext: Sed pretium metus et quam. Nullam odio dolor, vestibulum non, tempor ut, vehicula sed, sapien. Vestibulum placerat ligula at quam. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.\ntype: \nid: \nname: \nvalue: \ndisabled: false\nclass: \ntext: Suspendisse at ipsum a turpis viverra venenatis. Praesent ut nibh. Nullam eu odio. Donec tempor, elit ut lacinia porttitor, augue neque vehicula diam, in elementum ligula nisi a tellus. Aliquam vestibulum ultricies tortor.\ntype: \nid: \nname: \nvalue: \ndisabled: false\nclass: \ntext: Dubito, ergo cogito, ergo sum.\ntype: \nid: \nname: \nvalue: \ndisabled: false\nclass: \ntext: \ntype: \nid: \nname: footer\nvalue: \ndisabled: false\nclass: footer\ntext: This is a footer." (using ==) > ./spec/watirspec/spans_spec.rb:52: -- 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 Oct 27 15:42:25 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:25 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-333) watirspec: Ol or Ols not implemented Message-ID: <744115.320.1288208545464.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-333: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: Ol or Ols not implemented > ------------------------------------ > > Key: WTR-333 > URL: http://jira.openqa.org/browse/WTR-333 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 75) > NoMethodError in 'Ol#exist? returns true if the 'ol' exists' > undefined method `ol' for # > ./spec/watirspec/ol_spec.rb:13: > 76) > NoMethodError in 'Ol#exist? returns true if the element exists (default how = :id)' > undefined method `ol' for # > ./spec/watirspec/ol_spec.rb:20: > 77) > NoMethodError in 'Ol#exist? returns false if the 'ol' doesn't exist' > undefined method `ol' for # > ./spec/watirspec/ol_spec.rb:24: > 78) > 'Ol#exist? raises TypeError when 'what' argument is invalid' FAILED > expected TypeError, got #> > ./spec/watirspec/ol_spec.rb:35: > 79) > 'Ol#exist? raises MissingWayOfFindingObjectException when 'how' argument is invalid' FAILED > expected Watir::Exception::MissingWayOfFindingObjectException, got #> > ./spec/watirspec/ol_spec.rb:39: > 80) > NoMethodError in 'Ol#class_name returns the class attribute' > undefined method `ol' for # > ./spec/watirspec/ol_spec.rb:46: > 81) > NoMethodError in 'Ol#class_name returns an empty string if the element exists and the attribute doesn't' > undefined method `ol' for # > ./spec/watirspec/ol_spec.rb:50: > 82) > 'Ol#class_name raises UnknownObjectException if the ol doesn't exist' FAILED > expected Watir::Exception::UnknownObjectException, got #> > ./spec/watirspec/ol_spec.rb:54: > 83) > NoMethodError in 'Ol#id returns the id attribute' > undefined method `ol' for # > ./spec/watirspec/ol_spec.rb:60: > 84) > NoMethodError in 'Ol#id returns an empty string if the element exists and the attribute doesn't' > undefined method `ol' for # > ./spec/watirspec/ol_spec.rb:64: > 85) > 'Ol#id raises UnknownObjectException if the ol doesn't exist' FAILED > expected Watir::Exception::UnknownObjectException, got #> > ./spec/watirspec/ol_spec.rb:68: > 86) > NoMethodError in 'Ol#respond_to? returns true for all attribute methods' > undefined method `ol' for # > ./spec/watirspec/ol_spec.rb:75: > 87) > NoMethodError in 'Ols#length returns the number of ols' > undefined method `ols' for # > ./spec/watirspec/ols_spec.rb:12: > 88) > NoMethodError in 'Ols#[] returns the ol at the given index' > undefined method `ols' for # > ./spec/watirspec/ols_spec.rb:18: > 89) > NoMethodError in 'Ols#each iterates through ols correctly' > undefined method `ols' for # > ./spec/watirspec/ols_spec.rb:24: -- 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 Oct 28 03:52:03 2010 From: jarmo.p at gmail.com (Jarmo) Date: Thu, 28 Oct 2010 10:52:03 +0300 Subject: [Wtr-development] [JIRA] Commented: (WTR-461) Typo in README.rdoc, mismatch with example code In-Reply-To: <24407407.409.1288245200884.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> References: <22972864.242.1288179859977.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> <24407407.409.1288245200884.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: Documentation link at http://watir.com/documentation/ to rdoc.info should be also updated. Maybe have some
              there for different versions? Jarmo On Thu, Oct 28, 2010 at 8:53 AM, Alister Scott (JIRA) wrote: > > ? ?[ http://jira.openqa.org/browse/WTR-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19963#action_19963 ] > > Alister Scott commented on WTR-461: > ----------------------------------- > > Thanks. > Updated the watir site also: http://watir.com/examples/ > >> Typo in README.rdoc, mismatch with example code >> ------------------------------------------------ >> >> ? ? ? ? ? ? ? ? Key: WTR-461 >> ? ? ? ? ? ? ? ? URL: http://jira.openqa.org/browse/WTR-461 >> ? ? ? ? ? ? Project: Watir >> ? ? ? ? ?Issue Type: Bug >> ? ? ? ? ?Components: Documentation >> ? ?Affects Versions: 1.6.6 >> ? ? ? ? Environment: Any >> ? ? ? ? ? ?Reporter: Stephan K?mper >> >> The README.rdoc (http://github.com/bret/watir/blob/master/README.rdoc) says: >> Actual text: >> > Setting and clearing a radio button >> > >> > ?browser.radio(:value => "watir").set >> > ?browser.radio(:value => "watir".clear >> Closing parenthesis is missing, should be >> > browser.radio(:value => "watir").clear >> Additionally the example page (http://bit.ly/watir-example) as given in the code/README actually is: >> ... >> >>
              • >> ... >> This uses 'Watir' while the example code is 'watir' which in turn raises an exception: >> > ... >> > Watir::Exception::UnknownObjectException: Unable to locate element, using {:value=>"watir"} > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development From watirjira at gmail.com Thu Oct 28 04:20:20 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Thu, 28 Oct 2010 03:20:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-350) watirspec-pending: Element#to_s does not include tag name Message-ID: <18760798.411.1288254020754.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19964#action_19964 ] Zeljko commented on WTR-350: ---------------------------- I thought we agreed on wtr-development that we will override only inspect method, and remove Watir's to_s and show methods. > watirspec-pending: Element#to_s does not include tag name > --------------------------------------------------------- > > Key: WTR-350 > URL: http://jira.openqa.org/browse/WTR-350 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Priority: Major > Fix For: Soon > > > Without the tag name, elements without attributes will return empty strings. > Perhaps we should decide on a new and better string representation of elements? > 12) > 'Dd#to_s returns a human readable representation of the element' FAILED > expected: "tag: dd\n id: someone\n class: name\n title: someone\n text: John Doe", > got: "type: \nid: someone\nname: \nvalue: \ndisabled: false\nclass: name\ntext: John Doe" (using ==) > ./spec/watirspec/dd_spec.rb:130: > 16) > 'Div#to_s returns a human readable representation of the element' FAILED > expected: "tag: div\n id: footer\n title: Closing remarks\n class: profile\n text: This is a footer.", > got: "type: \nid: footer\nname: \nvalue: \ndisabled: false\nclass: profile\ntext: This is a footer." (using ==) > ./spec/watirspec/div_spec.rb:226: > 18) > 'Dl#to_s returns a human readable representation of the element' FAILED > expected: "tag: dl\n id: experience-list\n class: list\n title: experience\n text: Experience 11 years Education Master Current industry Architecture Previous industry experience Architecture", > got: "type: \nid: experience-list\nname: \nvalue: \ndisabled: false\nclass: list\ntext: Experience \r\n11 years \r\nEducation \r\nMaster \r\nCurrent industry \r\nArchitecture \r\nPrevious industry experience \r\nArchitecture" (using ==) > ./spec/watirspec/dl_spec.rb:130: > 20) > 'Dt#to_s returns a human readable representation of the element' FAILED > expected: "tag: dt\n id: experience\n class: industry\n title: experience\n text: Experience", > got: "type: \nid: experience\nname: \nvalue: \ndisabled: false\nclass: industry\ntext: Experience" (using ==) > ./spec/watirspec/dt_spec.rb:130: > 24) > 'Em#to_s returns a human readable representation of the element' FAILED > expected: "tag: em\n class: important-class\n id: important-id\n title: ergo cogito\n text: ergo cogito", > got: "type: \nid: important-id\nname: \nvalue: \ndisabled: false\nclass: important-class\ntext: ergo cogito" (using ==) > ./spec/watirspec/em_spec.rb:104: > 42) > 'Map#to_s returns a human readable representation of the element' FAILED > expected: "tag: map\n id: triangle_map\n name: triangle_map", > got: "type: \nid: triangle_map\nname: triangle_map\nvalue: \ndisabled: false\nclass: \ntext: " (using ==) > ./spec/watirspec/map_spec.rb:86: > 60) > 'P#to_s returns a human readable representation of the element' FAILED > expected: "tag: p\n id: lead\n class: lead\n title: Lorem ipsum\n text: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Curabitur eu pede. Ut justo. Praesent feugiat, elit in feugiat iaculis, sem risus rutrum justo, eget fermentum dolor arcu non nunc.", > got: "type: \nid: lead\nname: \nvalue: \ndisabled: false\nclass: lead\ntext: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Curabitur eu pede. Ut justo. Praesent feugiat, elit in feugiat iaculis, sem risus rutrum justo, eget fermentum dolor arcu non nunc." (using ==) > ./spec/watirspec/p_spec.rb:155: > 61) > 'Pre#to_s returns a human readable representation of the element' FAILED > expected: "tag: pre", > got: "type: \nid: \nname: \nvalue: \ndisabled: false\nclass: \ntext: " (using ==) > ./spec/watirspec/pre_spec.rb:119: > 70) > 'Span#to_s returns a human readable representation of the element' FAILED > expected: "tag: span\n name: invalid_attribute\n value: invalid_attribute\n text: Sed pretium metus et quam. Nullam odio dolor, vestibulum non, tempor ut, vehicula sed, sapien. Vestibulum placerat ligula at quam. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.", > got: "type: \nid: \nname: invalid_attribute\nvalue: invalid_attribute\ndisabled: false\nclass: \ntext: Sed pretium metus et quam. Nullam odio dolor, vestibulum non, tempor ut, vehicula sed, sapien. Vestibulum placerat ligula at quam. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas." (using ==) > ./spec/watirspec/span_spec.rb:167: > 71) > 'Spans#to_s returns a human readable representation of the collection' FAILED > expected: "tag: span\n id: lead\n class: lead\n title: Lorem ipsum\n text: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Curabitur eu pede. Ut justo. Praesent feugiat, elit in feugiat iaculis, sem risus rutrum justo, eget fermentum dolor arcu non nunc.\ntag: span\n name: invalid_attribute\n value: invalid_attribute\n text: Sed pretium metus et quam. Nullam odio dolor, vestibulum non, tempor ut, vehicula sed, sapien. Vestibulum placerat ligula at quam. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.\ntag: span\n text: Suspendisse at ipsum a turpis viverra venenatis. Praesent ut nibh. Nullam eu odio. Donec tempor, elit ut lacinia porttitor, augue neque vehicula diam, in elementum ligula nisi a tellus. Aliquam vestibulum ultricies tortor.\ntag: span\n text: Dubito, ergo cogito, ergo sum.\ntag: span\ntag: span\n class: footer\n name: footer\n onclick: this.innerHTML = 'This is a footer with text set by Javascript.'\n text: This is a footer.", > got: "type: \nid: lead\nname: \nvalue: \ndisabled: false\nclass: lead\ntext: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Curabitur eu pede. Ut justo. Praesent feugiat, elit in feugiat iaculis, sem risus rutrum justo, eget fermentum dolor arcu non nunc.\ntype: \nid: \nname: invalid_attribute\nvalue: invalid_attribute\ndisabled: false\nclass: \ntext: Sed pretium metus et quam. Nullam odio dolor, vestibulum non, tempor ut, vehicula sed, sapien. Vestibulum placerat ligula at quam. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.\ntype: \nid: \nname: \nvalue: \ndisabled: false\nclass: \ntext: Suspendisse at ipsum a turpis viverra venenatis. Praesent ut nibh. Nullam eu odio. Donec tempor, elit ut lacinia porttitor, augue neque vehicula diam, in elementum ligula nisi a tellus. Aliquam vestibulum ultricies tortor.\ntype: \nid: \nname: \nvalue: \ndisabled: false\nclass: \ntext: Dubito, ergo cogito, ergo sum.\ntype: \nid: \nname: \nvalue: \ndisabled: false\nclass: \ntext: \ntype: \nid: \nname: footer\nvalue: \ndisabled: false\nclass: footer\ntext: This is a footer." (using ==) > ./spec/watirspec/spans_spec.rb:52: -- 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 Oct 28 04:20:20 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Thu, 28 Oct 2010 03:20:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-23) show_tables needs a rescue Message-ID: <16269971.413.1288254020966.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19965#action_19965 ] Zeljko commented on WTR-23: --------------------------- I vote for completely removing all show* methods. > show_tables needs a rescue > -------------------------- > > Key: WTR-23 > URL: http://jira.openqa.org/browse/WTR-23 > Project: Watir > Issue Type: Bug > Components: HTML Controls > Reporter: Charley Baker > Fix For: Soon > > > add a begin/rescue around the columns=#{d.rows["0"].cells.length > code > I guess sometimes row(0) doesnt work - maybe its a th > WIN32OLERuntimeError: Unknown property or method `0' > HRESULT error code:0x80020006 > Unknown name. > from c:/ruby/lib/ruby/site_ruby/1.8/watir.rb:1678:in `[]' > from c:/ruby/lib/ruby/site_ruby/1.8/watir.rb:1678:in > ignore the line numbers, they are from an old version -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Thu Oct 28 04:28:20 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Thu, 28 Oct 2010 03:28:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-414) Using modal_dialog by specifying title doesn't work in IE8 as modal dialog has changed to "Webpage Dialog" Message-ID: <4114828.415.1288254500316.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19966#action_19966 ] Zeljko commented on WTR-414: ---------------------------- The more I think of it, the more I think it would be the best to completely remove popup support from Watir and provide separate gem for each platform. I do not think there is a single solution that works on all platforms Watir supports. Maybe we should use WinWindow (http://winwindow.vapir.org/) on Windows and create gems for other platforms. > Using modal_dialog by specifying title doesn't work in IE8 as modal dialog has changed to "Webpage Dialog" > ---------------------------------------------------------------------------------------------------------- > > Key: WTR-414 > URL: http://jira.openqa.org/browse/WTR-414 > Project: Watir > Issue Type: Bug > Components: Modal Windows Dialogs > Affects Versions: 1.6.5 > Environment: Windows Vista, IE8 > Reporter: Alister Scott > Fix For: Soon > > Attachments: modal IE8.jpg, modal_dialog.rb > > > When specifying the title of a modal_dialog, using IE 8, the suffix has changed from "Web Page Dialog" to "Webpage Dialog". > I updated line 46 of modal_dialog.rb to use this new description (see attached), but not sure how to add backwards compatibility. -- 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 Oct 28 04:28:20 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Thu, 28 Oct 2010 03:28:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-28) show_all_objects only shows some objects -- it should be renamed Message-ID: <19244717.417.1288254500898.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19967#action_19967 ] Zeljko commented on WTR-28: --------------------------- I vote for completely removing all show* methods. > show_all_objects only shows some objects -- it should be renamed > ---------------------------------------------------------------- > > Key: WTR-28 > URL: http://jira.openqa.org/browse/WTR-28 > Project: Watir > Issue Type: Bug > Reporter: Charley Baker > Fix For: Soon > > Attachments: WTR-28.zip > > > show_all_objects only shows some objects -- it should be renamed -- 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 Oct 28 04:33:20 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Thu, 28 Oct 2010 03:33:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-365) watirspec: no default how for Link Message-ID: <23821969.419.1288254800139.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19968#action_19968 ] Zeljko commented on WTR-365: ---------------------------- Does this ticket say that we want :href to be default how for links? I thought we agreed on wtr-development that we will remove default hows. > watirspec: no default how for Link > ---------------------------------- > > Key: WTR-365 > URL: http://jira.openqa.org/browse/WTR-365 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Priority: Major > Fix For: Soon > > > 10) > TypeError in 'Link#exist? returns true if the element exists (default how = :href)' > expected [String, Regexp, Fixnum, Watir::Element], got nil:NilClass > Z:/git/watir/watir/lib/watir/locator.rb:21:in `normalize_specifiers!' > Z:/git/watir/watir/lib/watir/locator.rb:7:in `each' > Z:/git/watir/watir/lib/watir/locator.rb:7:in `normalize_specifiers!' > Z:/git/watir/watir/lib/watir/locator.rb:45:in `set_specifier' > Z:/git/watir/watir/lib/watir/container.rb:823:in `locate_tagged_element' > Z:/git/watir/watir/lib/watir/link.rb:24:in `locate' > Z:/git/watir/watir/lib/watir/element.rb:279:in `exist?' > ./spec/watirspec/link_spec.rb:28: -- 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 Oct 28 04:35:20 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Thu, 28 Oct 2010 03:35:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-394) Basic Authenticaiton Message-ID: <30159293.422.1288254920675.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19969#action_19969 ] Zeljko commented on WTR-394: ---------------------------- I vote for removing popup support from Watir gem(s) and creating a separate gem for it. > Basic Authenticaiton > -------------------- > > Key: WTR-394 > URL: http://jira.openqa.org/browse/WTR-394 > Project: Watir > Issue Type: Bug > Components: FireWatir > Affects Versions: Open QA Migration > Environment: any > Reporter: Zeljko > Assignee: Angrez > Fix For: Soon > > > - moved from http://code.google.com/p/firewatir/issues/detail?id=73 > Issue 73: Basic Authenticaiton > 2 people starred this issue and may be notified of changes. > Status: New > Owner: ---- > Type-Defect > Priority-Medium > Reported by mfurrer, Jul 06, 2008 > Sorry, this is not a bug, rather a question / feature request. > I have a need to do basic authentication with firewatir, I cannot find > anywhere in the documentation or in Google a way of doing it. > So is there a solution ? > If not is there a workaround ? > Thanks for your help. > Marc. > --- > > Comment 1 by angrez, Jul 06, 2008 > Can you give some example of what you want Firewatir to do for you? > --- > > Comment 2 by lastobelus, Oct 05, 2009 > he means basic authentication: entering username & password for standard htttp basic auth. -- 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 Oct 28 04:37:20 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Thu, 28 Oct 2010 03:37:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-93) ie.divs.show not working Message-ID: <19896035.424.1288255040247.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19970#action_19970 ] Zeljko commented on WTR-93: --------------------------- I vote for completely removing all show methods. > ie.divs.show not working > ------------------------ > > Key: WTR-93 > URL: http://jira.openqa.org/browse/WTR-93 > Project: Watir > Issue Type: Bug > Components: HTML Controls > Affects Versions: 1.5.0/1.5.1 > Environment: Microsoft Windows XP Professional, Version: 5.1.2600, Service Pack: 2.0 > ruby 1.8.4 (2006-04-14) [i386-mswin32] > watir-1.5.1.1065 > Reporter: Zeljko > Priority: Major > Fix For: Soon > > > - go to irb > irb(main):001:0> require 'watir' > => true > irb(main):002:0> ie = Watir::IE.start("http://www.yahoo.com/") > => # [...] > > > irb(main):003:0> ie.divs.show > index id className > 1 > 2 > [...] > 74 > 75 > => nil > - only indexes are printed, all ids are empty > - this is snippet of html of that page (divs have ids) > [...] >
                >
                >
                >
                >
                > [...] -- 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 Oct 28 04:39:20 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Thu, 28 Oct 2010 03:39:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-66) IE#Frame.show_frames doesn't work Message-ID: <26598520.426.1288255160047.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19971#action_19971 ] Zeljko commented on WTR-66: --------------------------- I vote for removing all show* methods. > IE#Frame.show_frames doesn't work > --------------------------------- > > Key: WTR-66 > URL: http://jira.openqa.org/browse/WTR-66 > Project: Watir > Issue Type: Bug > Components: Frame > Affects Versions: 1.5.0/1.5.1 > Environment: Watir 1.5.0.993 on Branch: modal_dialog > Reporter: David Schmidt > Fix For: Soon > > > Frame.show_frames no longer works. Since frames may contain sub-frames, the "show_frames" method (and probably other "show" methods) should be in module Container rather than class IE: > irb(main):101:0> ie.frame('Main').show_all_frames > NoMethodError: undefined method `show_all_frames' for # > from (irb):101 > from ?:0 > After moving show methods to module Container it works fine: > irb(main):004:0> ie.frame('Main').show_frames > there are 6 frames > frame index: 1 name: navigator > frame index: 2 name: cookies > frame index: 3 name: Header > frame index: 4 name: workarea > frame index: 5 name: IFSCommArea > frame index: 6 name: toolbar -- 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 Oct 27 15:42:25 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:25 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-335) watirspec: Option#select should fire onclick event Message-ID: <8664089.316.1288208545368.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-335: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: Option#select should fire onclick event > -------------------------------------------------- > > Key: WTR-335 > URL: http://jira.openqa.org/browse/WTR-335 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 101) > 'Option#select fires onclick event (select_list context)' FAILED > expected: "Don't do it!", > got: "Default comment." (using ==) > ./spec/watirspec/option_spec.rb:107: -- 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 Oct 27 15:42:25 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:25 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-332) watirspec: Container#uls not implemented Message-ID: <5828609.322.1288208545502.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-332: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: Container#uls not implemented > ---------------------------------------- > > Key: WTR-332 > URL: http://jira.openqa.org/browse/WTR-332 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 194) > NoMethodError in 'Uls#length returns the number of uls' > undefined method `uls' for # > ./spec/watirspec/uls_spec.rb:12: > 195) > NoMethodError in 'Uls#[] returns the ul at the given index' > undefined method `uls' for # > ./spec/watirspec/uls_spec.rb:18: > 196) > NoMethodError in 'Uls#each iterates through uls correctly' > undefined method `uls' for # > ./spec/watirspec/uls_spec.rb:24: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From zeljko.filipin at wa-research.ch Thu Oct 28 06:10:30 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 28 Oct 2010 12:10:30 +0200 Subject: [Wtr-development] [JIRA] Commented: (WTR-461) Typo in README.rdoc, mismatch with example code In-Reply-To: References: <22972864.242.1288179859977.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> <24407407.409.1288245200884.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: On Thu, Oct 28, 2010 at 9:52 AM, Jarmo wrote: > Documentation link at http://watir.com/documentation/ to rdoc.info > should be also updated. I have changed the link to point to http://rdoc.info/gems/watir/ instead of http://rdoc.info/gems/watir/1.6.6 I have generated rdoc for watir 1.6.7 at rdoc.info, but I do not know why http://rdoc.info/gems/watir/ still points to 1.6.6. Maybe it needs some time. > Maybe have some
                  there for different > versions? I think we should link just to the most recent version. Jarmo, I see that you do not have account at watir.com. Would you like one, so you can edit the pages? You will have to provide your wordpress.comaccount name (send it off list if you prefer). ?eljko -- watir.com - community manager watirpodcast.com - host testingpodcast.com - audio podcasts on software testing. all of them -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Thu Oct 28 06:35:36 2010 From: jarmo.p at gmail.com (Jarmo) Date: Thu, 28 Oct 2010 13:35:36 +0300 Subject: [Wtr-development] [JIRA] Commented: (WTR-461) Typo in README.rdoc, mismatch with example code In-Reply-To: References: <22972864.242.1288179859977.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> <24407407.409.1288245200884.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: Add /frames to the url for better view at rdoc.org. I'm not sure i need that account and don't have any wordpress accounts either. I think i can manage. Jarmo On Thu, Oct 28, 2010 at 1:10 PM, ?eljko Filipin wrote: > On Thu, Oct 28, 2010 at 9:52 AM, Jarmo wrote: >> Documentation link at http://watir.com/documentation/ to rdoc.info >> should be also updated. > > I have changed the link to point to http://rdoc.info/gems/watir/ instead of > http://rdoc.info/gems/watir/1.6.6 > > I have generated rdoc for watir 1.6.7 at rdoc.info, but I do not know why > http://rdoc.info/gems/watir/ still points to 1.6.6. Maybe it needs some > time. > >> Maybe have some
                    there for different >> versions? > > I think we should link just to the most recent version. > > Jarmo, I see that you do not have account at watir.com. Would you like one, > so you can edit the pages? You will have to provide your wordpress.com > account name (send it off list if you prefer). > > ?eljko > -- > watir.com - community manager > watirpodcast.com - host > testingpodcast.com - audio podcasts on software testing. all of them > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From zeljko.filipin at wa-research.ch Thu Oct 28 07:31:25 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 28 Oct 2010 13:31:25 +0200 Subject: [Wtr-development] [JIRA] Commented: (WTR-461) Typo in README.rdoc, mismatch with example code In-Reply-To: References: <22972864.242.1288179859977.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> <24407407.409.1288245200884.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: On Thu, Oct 28, 2010 at 12:35 PM, Jarmo wrote: > Add /frames to the url for better view at rdoc.org. Done. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Wed Oct 27 15:42:25 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:25 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-327) watirspec: Browser#element_by_xpath should return a Watir::Element if there are no matching elements, not nil Message-ID: <19323176.332.1288208545786.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-327: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: Browser#element_by_xpath should return a Watir::Element if there are no matching elements, not nil > ------------------------------------------------------------------------------------------------------------- > > Key: WTR-327 > URL: http://jira.openqa.org/browse/WTR-327 > Project: Watir > Issue Type: Sub-task > Components: Xpath Support > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 9) > NoMethodError in 'Browser#element_by_xpath will not find elements that doesn't exist' > undefined method `exist?' for nil:NilClass > ./spec/watirspec/browser_spec.rb -- 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 Oct 27 15:42:25 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:25 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-342) watirspec: Should find Area elements by :url (href) attribute Message-ID: <20584447.310.1288208545184.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-342: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: Should find Area elements by :url (href) attribute > ------------------------------------------------------------- > > Key: WTR-342 > URL: http://jira.openqa.org/browse/WTR-342 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 1) > 'Area#exist? returns true if the area exists' FAILED > expected # to exist > ./spec/watirspec/area_spec.rb:19: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From zeljko.filipin at wa-research.ch Thu Oct 28 07:47:57 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 28 Oct 2010 13:47:57 +0200 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: On Wed, Oct 27, 2010 at 4:16 PM, Charley Baker wrote: > I think the only thing holding back from fully recommending > the latest of these is showModalDialog And if we removed popup support from Watir and created new gem? Watir-popups? That does not fix the problem, but it lets people that do not need popup support to use newer versions of Ruby. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Wed Oct 27 15:42:25 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:25 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-343) watirspec: element_by_xpath should return Watir::Element objects Message-ID: <23888780.308.1288208545026.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-343: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: element_by_xpath should return Watir::Element objects > ---------------------------------------------------------------- > > Key: WTR-343 > URL: http://jira.openqa.org/browse/WTR-343 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 5) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds submit buttons matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:201: > 6) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds reset buttons matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:205: > 7) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds image buttons matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:209: > 8) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds the element matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:213: -- 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 Oct 27 15:42:25 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:25 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-322) Open Firefox when using Ruby under Cygwin [patch] Message-ID: <21517618.334.1288208545849.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-322: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > Open Firefox when using Ruby under Cygwin [patch] > ------------------------------------------------- > > Key: WTR-322 > URL: http://jira.openqa.org/browse/WTR-322 > Project: Watir > Issue Type: Improvement > Components: FireWatir > Affects Versions: 1.6.2 > Environment: Cygwin under Windows > Reporter: Tobias Haagen Michaelsen > Fix For: Soon > > Attachments: firewatir_cygwin.patch > > > When running Ruby under Cygwin, the firewatir gem can not open the Firefox browser because the RUBY_PLATFORM is not matched. > Implementation: > Since Cygwin is an environment inside Windows, the code for resolving the path to the binaries is essentially the same, but the resulting path can not be "run" since Cygwin expects a unix-style path, so we need to use the cygstart app to call it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From bret at pettichord.com Thu Oct 28 11:44:07 2010 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 28 Oct 2010 10:44:07 -0500 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: That's a good idea. The hardest part will be finding a good name for the gem. Watir-popups is a horrible name for it. If you can get consensus around a good name for this gem, I will volunteer to extract the code to it. Bret On Thu, Oct 28, 2010 at 6:47 AM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Wed, Oct 27, 2010 at 4:16 PM, Charley Baker > wrote: > > I think the only thing holding back from fully recommending > > the latest of these is showModalDialog > > And if we removed popup support from Watir and created new gem? > Watir-popups? That does not fix the problem, but it lets people that do not > need popup support to use newer versions of Ruby. > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Thu Oct 28 12:14:20 2010 From: watirjira at gmail.com (Ethan (JIRA)) Date: Thu, 28 Oct 2010 11:14:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-343) watirspec: element_by_xpath should return Watir::Element objects Message-ID: <25265940.435.1288282460738.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19973#action_19973 ] Ethan commented on WTR-343: --------------------------- I don't think that element_by_xpath / elements_by_xpath should be documented as watir API - they should be internal methods only. The API that should be used is container.element(:xpath, "some xpath"). > watirspec: element_by_xpath should return Watir::Element objects > ---------------------------------------------------------------- > > Key: WTR-343 > URL: http://jira.openqa.org/browse/WTR-343 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Priority: Major > Fix For: Soon > > > 5) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds submit buttons matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:201: > 6) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds reset buttons matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:205: > 7) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds image buttons matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:209: > 8) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds the element matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:213: -- 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 Oct 28 12:16:19 2010 From: watirjira at gmail.com (Ethan (JIRA)) Date: Thu, 28 Oct 2010 11:16:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-23) show_tables needs a rescue Message-ID: <23215389.437.1288282579987.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19974#action_19974 ] Ethan commented on WTR-23: -------------------------- zeljko: seconded. > show_tables needs a rescue > -------------------------- > > Key: WTR-23 > URL: http://jira.openqa.org/browse/WTR-23 > Project: Watir > Issue Type: Bug > Components: HTML Controls > Reporter: Charley Baker > Fix For: Soon > > > add a begin/rescue around the columns=#{d.rows["0"].cells.length > code > I guess sometimes row(0) doesnt work - maybe its a th > WIN32OLERuntimeError: Unknown property or method `0' > HRESULT error code:0x80020006 > Unknown name. > from c:/ruby/lib/ruby/site_ruby/1.8/watir.rb:1678:in `[]' > from c:/ruby/lib/ruby/site_ruby/1.8/watir.rb:1678:in > ignore the line numbers, they are from an old version -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Wed Oct 27 15:42:25 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:25 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-334) watirspec: meta tag not implemented Message-ID: <20584784.318.1288208545417.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-334: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: meta tag not implemented > ----------------------------------- > > Key: WTR-334 > URL: http://jira.openqa.org/browse/WTR-334 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > NoMethodError in 'Meta#exist? returns true if the meta tag exists' > undefined method `meta' for # > ./spec/watirspec/meta_spec.rb:12: > 71) > NoMethodError in 'Meta content returns the content attribute of the tag' > undefined method `meta' for # > ./spec/watirspec/meta_spec.rb:18: > 72) > NoMethodError in 'Metas#length returns the number of meta elements' > undefined method `metas' for # > ./spec/watirspec/metas_spec.rb:12: > 73) > NoMethodError in 'Metas#[] returns the meta element at the given index' > undefined method `metas' for # > ./spec/watirspec/metas_spec.rb:18: > 74) > NoMethodError in 'Metas#each iterates through meta elements correctly' > undefined method `metas' for # > ./spec/watirspec/metas_spec.rb:24: -- 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 Oct 27 15:42:25 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:25 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-341) watirspec: TextField#set should fire events Message-ID: <19014691.312.1288208545220.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-341: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: TextField#set should fire events > ------------------------------------------- > > Key: WTR-341 > URL: http://jira.openqa.org/browse/WTR-341 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 151) > 'TextField#set fires events' FAILED > expected: "11", > got: "12" (using ==) > ./spec/watirspec/text_field_spec.rb:270: -- 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 Oct 28 14:46:19 2010 From: watirjira at gmail.com (Jari Bakken (JIRA)) Date: Thu, 28 Oct 2010 13:46:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-343) watirspec: element_by_xpath should return Watir::Element objects Message-ID: <31665506.439.1288291579975.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19975#action_19975 ] Jari Bakken commented on WTR-343: --------------------------------- +1 for deprecating this and adding Browser#element (or does that exist already?) and Element#to_subtype. > watirspec: element_by_xpath should return Watir::Element objects > ---------------------------------------------------------------- > > Key: WTR-343 > URL: http://jira.openqa.org/browse/WTR-343 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Priority: Major > Fix For: Soon > > > 5) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds submit buttons matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:201: > 6) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds reset buttons matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:205: > 7) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds image buttons matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:209: > 8) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds the element matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:213: -- 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 Oct 28 14:49:19 2010 From: watirjira at gmail.com (Jari Bakken (JIRA)) Date: Thu, 28 Oct 2010 13:49:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-343) watirspec: element_by_xpath should return Watir::Element objects Message-ID: <2462551.441.1288291759935.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19976#action_19976 ] Jari Bakken commented on WTR-343: --------------------------------- ...and Browser#elements > watirspec: element_by_xpath should return Watir::Element objects > ---------------------------------------------------------------- > > Key: WTR-343 > URL: http://jira.openqa.org/browse/WTR-343 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Priority: Major > Fix For: Soon > > > 5) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds submit buttons matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:201: > 6) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds reset buttons matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:205: > 7) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds image buttons matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:209: > 8) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds the element matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:213: -- 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 Oct 28 15:40:30 2010 From: jarmo.p at gmail.com (Jarmo) Date: Thu, 28 Oct 2010 22:40:30 +0300 Subject: [Wtr-development] Watir 1.6.7 final released In-Reply-To: References: Message-ID: I have already similar idea and even have implemented some part of it. I had the idea before i knew Ethan's WinWindow, but just hadn't any time to do it. It is called RAutomation[1]. Currently it is only working with AutoIt as an API's proof of concept and to provide the platform itself for other implementations. The next "implementation" is in my TODO list to use FFI and windows API like Ethan did. The main difference between RAutomation and WinWindow in my mind is that i would like to offer Watir-like user-friendly and easy to use API, but WinWindow wants to offer windows API like API. I've also planned to make it easy to support multiple platforms (implementations in my words). RAutomation code should already support (haven't started with FFI yet, so there might be some not yet seen blockers) any possible future implementations/platforms/GUI-s which could be changed in runtime. So, let's say that in theory you could use one implementation for KDE and other for GNOME (if it's necessary, i don't know). As you can see from the readme then i'd be willing to get any OS X and Linux expertise and help to provide different implementations for RAutomation API - if it's even possible. [1] http://github.com/jarmo/rautomation Jarmo On Thu, Oct 28, 2010 at 6:44 PM, Bret Pettichord wrote: > That's a good idea. The hardest part will be finding a good name for the > gem. Watir-popups is a horrible name for it. > > If you can get consensus around a good name for this gem, I will volunteer > to extract the code to it. > > Bret > > On Thu, Oct 28, 2010 at 6:47 AM, ?eljko Filipin > wrote: >> >> On Wed, Oct 27, 2010 at 4:16 PM, Charley Baker >> wrote: >> > I think the only thing holding back from fully recommending >> > the latest of these is showModalDialog >> >> And if we removed popup support from Watir and created new gem? >> Watir-popups? That does not fix the problem, but it lets people that do not >> need popup support to use newer versions of Ruby. >> >> ?eljko >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From zeljko.filipin at wa-research.ch Thu Oct 28 15:50:02 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 28 Oct 2010 21:50:02 +0200 Subject: [Wtr-development] [wtr-general] Watir 1.6.7 final released In-Reply-To: References: Message-ID: On Thursday, October 28, 2010, Bret Pettichord wrote: > The hardest part will be finding a good name for the gem. Watir-popups is a horrible name for it. "popup" is free: http://rubygems.org/gems/popup Zeljko From watirjira at gmail.com Wed Oct 27 15:42:25 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:25 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-331) watirspec: Option#class_name not implemented Message-ID: <28791134.324.1288208545585.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-331: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: Option#class_name not implemented > --------------------------------------------- > > Key: WTR-331 > URL: http://jira.openqa.org/browse/WTR-331 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > (Option should be Element subclass!) > 105) > NoMethodError in 'Option#class_name is able to get attributes (select_list context)' > undefined method `class_name' for # > ./spec/watirspec/option_spec.rb:135: -- 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 Oct 27 15:42:25 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:25 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-340) watirspec: Image#save and FileField#set should fix path for windows Message-ID: <13126975.314.1288208545332.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-340: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: Image#save and FileField#set should fix path for windows > ------------------------------------------------------------------- > > Key: WTR-340 > URL: http://jira.openqa.org/browse/WTR-340 > Project: Watir > Issue Type: Sub-task > Components: Save File > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Fix For: Soon > > > 61) > 'Image#save saves an image to file' FAILED > expected true, got false > ./spec/watirspec/image_spec.rb:208: > 32) > 'FileField#set is able to set a file path in the field and click the upload button and fire the onchange event' FAILED > expected: "Z:/git/watir/spec/watirspec/filefield_spec.rb", > got: "" (using ==) > ./spec/watirspec/filefield_spec.rb:114: -- 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 Oct 27 15:42:26 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:26 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-231) Need a way to only call specific version of the Browser using firewatir Message-ID: <31144191.358.1288208546789.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-231: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > Need a way to only call specific version of the Browser using firewatir > ------------------------------------------------------------------------ > > Key: WTR-231 > URL: http://jira.openqa.org/browse/WTR-231 > Project: Watir > Issue Type: New Feature > Components: FireWatir > Environment: Windows XP > Installed Firefox2 and Firefox3 on my system > Reporter: Makarand > Priority: Major > Fix For: Soon > > > I have the windows XP system running > I have installed the FF2 and FF3 on my machine. > I want to run test cases against FF2 and FF3. > Need call only FF2 from my script so that i can run my test cases only for FF2 > Need a way to only call specific version of the Browser ( Firefox, IE ) -- 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 Oct 27 15:42:25 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:25 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-316) Watir::Image save issue with IE8 [patch] Message-ID: <28144856.336.1288208545930.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-316: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > Watir::Image save issue with IE8 [patch] > ---------------------------------------- > > Key: WTR-316 > URL: http://jira.openqa.org/browse/WTR-316 > Project: Watir > Issue Type: Bug > Components: Save File > Affects Versions: 1.6.2 > Environment: Internet Explorer 8 installed, WinXP or Vista. > Reporter: Jason Truesdell > Fix For: Soon > > Attachments: diff.txt, diff.txt > > > In IE8, image.save fails to set the path name for which to save an image. This is due to a change in IE. > With IE8, the control ID for the Save Picture edit control is no longer 1148. It appears to be 1001. I created a patch which resolves the issue, at least with AutoIt 3 installed, by replacing the hard-coded control ID with a [CLASS:Edit] selector. This appears to resolve the issue in IE7 and IE8. > The patch is attached as a file. > 125c125 > < system("ruby -e \"require 'win32ole'; @autoit=WIN32OLE.new('AutoItX3.Control'); waitresult=@autoit.WinWait 'Save Picture', '', 15; if waitresult == 1\" -e \"@autoit.ControlSetText 'Save Picture', '', '[CLASS:Edit]', '#{path}'; @autoit.ControlSend 'Save Picture', '', '1', '{ENTER}';\" -e \"end\"") > --- > > system("ruby -e \"require 'win32ole'; @autoit=WIN32OLE.new('AutoItX3.Control'); waitresult=@autoit.WinWait 'Save Picture', '', 15; if waitresult == 1\" -e \"@autoit.ControlSetText 'Save Picture', '', '1148', '#{path}'; @autoit.ControlSend 'Save Picture', '', '1', '{ENTER}';\" -e \"end\"") -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From alister.scott at gmail.com Thu Oct 28 22:16:21 2010 From: alister.scott at gmail.com (Alister Scott) Date: Fri, 29 Oct 2010 12:16:21 +1000 Subject: [Wtr-development] A solution for JavaScript dialogs in Watir Message-ID: Hi, One of the guys I am working with setting up Cucumber and Watir on a ThoughtWorks project told me about a way to get rid of the pesky JavaScript dialogs that cause Watir scripts to be unstable. It involves overriding the JavaScript function to always return true, so the dialogs never appear. I wrote an example for Watir: require 'rubygems' require 'watir' b = Watir::Browser.start "http://www.sislands.com/coin70/week1/dialogbox.htm " b.execute_script "window.confirm = function() { return true; }" b.execute_script "window.alert = function() { return true; }" b.execute_script "window.prompt = function() { return true; }" b.button(:value => 'confirm').click What do you think of this? Is it worthwhile putting this out for Watir users to see and use? Cheers, Alister Scott Brisbane, Australia Watir Web Master: http://watir.com 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* -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Thu Oct 28 22:51:57 2010 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 28 Oct 2010 21:51:57 -0500 Subject: [Wtr-development] Two Types of Dialogs Message-ID: OK, I'm restarting this thread, under a new subject, because it already has become hopelessly confused. Charley said something about showModalDialog, and then Zeljko said something about popups and then then Jarmo said he had something along these lines that didn't use AutoIt. We are already talking about completely different things. 1. showModalDialog = Watir#modal_dialog. It is one kind of dialog, that is only supported by IE. Watir has unique support for this kind of dialog. The support includes a custom version of win32ole and therefore adds ruby version dependencies to Watir. Charley understands this, and I thought Zeljko did in his reply, but now I realize he didn't. Like, I said, the hardest part about this is terminology. Until we all have confidence that we understand each other we can't start discussing solutions. showModalDialog windows include a web page and therefore cannot be handled by Windows-only tools, such as AutoIt. 2. There are lots of other popups as well, many of which can be handled by AutoIt. There are recurring discussions about using different libraries etc to handle them. This is all fine, but has nothing to do with #1. One of the reasons that Watir users have so much trouble handling dialogs is because we don't have a scientific language for discussing them. So I am going to declare that these will henceforth be known, by any one who wants to be taken seriously by me, as Type 1 and Type 2 dialogs. Now there are actually a lot of different kinds of Type 2 dialogs, so maybe there are more. I don't know. I mostly avoid Type 2 dialogs. But I have made a significant study of Type 1 dialogs. I have seen Type 1 dialogs that spawned more type 1 dialogs. I have seen type 1 dialogs that contained frames. And I have found ways to make Watir work with all of them. (Selenium gets quite lost with them). I wrote the special version of win32ole to support them and recently suggested we break this code out into a separate gem. That was when Jarmo said, "I was thinking of something similar" and discussed new code for handling type 2 dialogs. This is why I said the most difficult aspect of what I was proposing (making a separate gem for type 1 dialogs) was finding a suitable name. I said that Zeljko's "watir-popups" was horrible because i knew it would make people think of type 2 dialogs (which is exactly what happened faster than even I expected). Bret On Thu, Oct 28, 2010 at 6:47 AM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Wed, Oct 27, 2010 at 4:16 PM, Charley Baker > wrote: > > I think the only thing holding back from fully recommending > > the latest of these is showModalDialog > > And if we removed popup support from Watir and created new gem? > Watir-popups? That does not fix the problem, but it lets people that do not > need popup support to use newer versions of Ruby. > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Thu Oct 28 23:18:20 2010 From: watirjira at gmail.com (Bret Pettichord (JIRA)) Date: Thu, 28 Oct 2010 22:18:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-394) Basic Authenticaiton Message-ID: <4726252.444.1288322300739.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19977#action_19977 ] Bret Pettichord commented on WTR-394: ------------------------------------- Zeljko, could you please open up a separate ticket describing your proposal. > Basic Authenticaiton > -------------------- > > Key: WTR-394 > URL: http://jira.openqa.org/browse/WTR-394 > Project: Watir > Issue Type: Bug > Components: FireWatir > Affects Versions: Open QA Migration > Environment: any > Reporter: Zeljko > Assignee: Angrez > Fix For: Soon > > > - moved from http://code.google.com/p/firewatir/issues/detail?id=73 > Issue 73: Basic Authenticaiton > 2 people starred this issue and may be notified of changes. > Status: New > Owner: ---- > Type-Defect > Priority-Medium > Reported by mfurrer, Jul 06, 2008 > Sorry, this is not a bug, rather a question / feature request. > I have a need to do basic authentication with firewatir, I cannot find > anywhere in the documentation or in Google a way of doing it. > So is there a solution ? > If not is there a workaround ? > Thanks for your help. > Marc. > --- > > Comment 1 by angrez, Jul 06, 2008 > Can you give some example of what you want Firewatir to do for you? > --- > > Comment 2 by lastobelus, Oct 05, 2009 > he means basic authentication: entering username & password for standard htttp basic auth. -- 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 Oct 28 23:22:19 2010 From: watirjira at gmail.com (Bret Pettichord (JIRA)) Date: Thu, 28 Oct 2010 22:22:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-343) watirspec: element_by_xpath should return Watir::Element objects Message-ID: <24981119.446.1288322539832.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19978#action_19978 ] Bret Pettichord commented on WTR-343: ------------------------------------- Like it or not, element_by_xpath has been part of the Watir API for a long time and is well known and used by many people. So it should be documented as such. I'm not opposed to eventually deprecating it some day in favor of a more consistent API, but first we need to 1. Develop and release a more consistent API 2. Publicize and document the new API 3. Let people know the old API will be deprecated 4. Release a version that gives a warning when the old API is used. Regardless, this should be tracked as a separate ticket. Please create one on this topic if you would like to pursue this further. > watirspec: element_by_xpath should return Watir::Element objects > ---------------------------------------------------------------- > > Key: WTR-343 > URL: http://jira.openqa.org/browse/WTR-343 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Priority: Major > Fix For: Soon > > > 5) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds submit buttons matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:201: > 6) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds reset buttons matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:205: > 7) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds image buttons matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:209: > 8) > WIN32OLERuntimeError in 'Browser#element_by_xpath finds the element matching the given xpath' > unknown property or method `exist?' > HRESULT error code:0x80020006 > Unknown name. > ./spec/watirspec/browser_spec.rb:213: -- 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 Oct 28 23:24:19 2010 From: watirjira at gmail.com (Bret Pettichord (JIRA)) Date: Thu, 28 Oct 2010 22:24:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-93) ie.divs.show not working Message-ID: <15115126.448.1288322659861.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19979#action_19979 ] Bret Pettichord commented on WTR-93: ------------------------------------ I am also in favor of deprecating the show methods. But this isn't the place to discuss it. Could you please create a separate ticket where we can discuss and vote on this idea properly? Bret > ie.divs.show not working > ------------------------ > > Key: WTR-93 > URL: http://jira.openqa.org/browse/WTR-93 > Project: Watir > Issue Type: Bug > Components: HTML Controls > Affects Versions: 1.5.0/1.5.1 > Environment: Microsoft Windows XP Professional, Version: 5.1.2600, Service Pack: 2.0 > ruby 1.8.4 (2006-04-14) [i386-mswin32] > watir-1.5.1.1065 > Reporter: Zeljko > Priority: Major > Fix For: Soon > > > - go to irb > irb(main):001:0> require 'watir' > => true > irb(main):002:0> ie = Watir::IE.start("http://www.yahoo.com/") > => # [...] > > > irb(main):003:0> ie.divs.show > index id className > 1 > 2 > [...] > 74 > 75 > => nil > - only indexes are printed, all ids are empty > - this is snippet of html of that page (divs have ids) > [...] >
                    >
                    >
                    >
                    >
                    > [...] -- 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 Oct 28 23:28:19 2010 From: watirjira at gmail.com (Bret Pettichord (JIRA)) Date: Thu, 28 Oct 2010 22:28:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-365) watirspec: no default how for Link Message-ID: <10266518.450.1288322899997.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19980#action_19980 ] Bret Pettichord commented on WTR-365: ------------------------------------- I am also -1 on doing this. > watirspec: no default how for Link > ---------------------------------- > > Key: WTR-365 > URL: http://jira.openqa.org/browse/WTR-365 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Priority: Major > Fix For: Soon > > > 10) > TypeError in 'Link#exist? returns true if the element exists (default how = :href)' > expected [String, Regexp, Fixnum, Watir::Element], got nil:NilClass > Z:/git/watir/watir/lib/watir/locator.rb:21:in `normalize_specifiers!' > Z:/git/watir/watir/lib/watir/locator.rb:7:in `each' > Z:/git/watir/watir/lib/watir/locator.rb:7:in `normalize_specifiers!' > Z:/git/watir/watir/lib/watir/locator.rb:45:in `set_specifier' > Z:/git/watir/watir/lib/watir/container.rb:823:in `locate_tagged_element' > Z:/git/watir/watir/lib/watir/link.rb:24:in `locate' > Z:/git/watir/watir/lib/watir/element.rb:279:in `exist?' > ./spec/watirspec/link_spec.rb:28: -- 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 Oct 28 23:42:19 2010 From: watirjira at gmail.com (Jari Bakken (JIRA)) Date: Thu, 28 Oct 2010 22:42:19 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-365) watirspec: no default how for Link Message-ID: <6926149.452.1288323739977.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19981#action_19981 ] Jari Bakken commented on WTR-365: --------------------------------- -1 for me too. These bugs were filed based on failures from watirspec master - "default hows" are gone in the watir2 branch. > watirspec: no default how for Link > ---------------------------------- > > Key: WTR-365 > URL: http://jira.openqa.org/browse/WTR-365 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Priority: Major > Fix For: Soon > > > 10) > TypeError in 'Link#exist? returns true if the element exists (default how = :href)' > expected [String, Regexp, Fixnum, Watir::Element], got nil:NilClass > Z:/git/watir/watir/lib/watir/locator.rb:21:in `normalize_specifiers!' > Z:/git/watir/watir/lib/watir/locator.rb:7:in `each' > Z:/git/watir/watir/lib/watir/locator.rb:7:in `normalize_specifiers!' > Z:/git/watir/watir/lib/watir/locator.rb:45:in `set_specifier' > Z:/git/watir/watir/lib/watir/container.rb:823:in `locate_tagged_element' > Z:/git/watir/watir/lib/watir/link.rb:24:in `locate' > Z:/git/watir/watir/lib/watir/element.rb:279:in `exist?' > ./spec/watirspec/link_spec.rb:28: -- 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 Oct 28 23:42:20 2010 From: watirjira at gmail.com (Jari Bakken (JIRA)) Date: Thu, 28 Oct 2010 22:42:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-365) watirspec: no default how for Link Message-ID: <10328227.454.1288323740022.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jari Bakken closed WTR-365. --------------------------- Resolution: Won't Fix > watirspec: no default how for Link > ---------------------------------- > > Key: WTR-365 > URL: http://jira.openqa.org/browse/WTR-365 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Priority: Major > Fix For: Soon > > > 10) > TypeError in 'Link#exist? returns true if the element exists (default how = :href)' > expected [String, Regexp, Fixnum, Watir::Element], got nil:NilClass > Z:/git/watir/watir/lib/watir/locator.rb:21:in `normalize_specifiers!' > Z:/git/watir/watir/lib/watir/locator.rb:7:in `each' > Z:/git/watir/watir/lib/watir/locator.rb:7:in `normalize_specifiers!' > Z:/git/watir/watir/lib/watir/locator.rb:45:in `set_specifier' > Z:/git/watir/watir/lib/watir/container.rb:823:in `locate_tagged_element' > Z:/git/watir/watir/lib/watir/link.rb:24:in `locate' > Z:/git/watir/watir/lib/watir/element.rb:279:in `exist?' > ./spec/watirspec/link_spec.rb:28: -- 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 Oct 27 15:42:25 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:25 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-330) watirspec: unable to locate Option element by :id Message-ID: <1286491.326.1288208545630.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-330: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: unable to locate Option element by :id > ------------------------------------------------- > > Key: WTR-330 > URL: http://jira.openqa.org/browse/WTR-330 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXp > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 94) > Watir::Exception::MissingWayOfFindingObjectException in 'Option#exists? returns false if the element does not exist (select_list context)' > Option does not support attribute id > Z:/git/watir/watir/lib/watir/input_elements.rb:166:in `initialize' > Z:/git/watir/watir/lib/watir/input_elements.rb:132:in `new' > Z:/git/watir/watir/lib/watir/input_elements.rb:132:in `option' > ./spec/watirspec/option_spec.rb:55: -- 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 Oct 27 15:42:25 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:25 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-328) watirspec: Browser#elements_by_xpath should return an empty Array if there are no matching elements Message-ID: <30929697.330.1288208545750.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-328: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: Browser#elements_by_xpath should return an empty Array if there are no matching elements > ---------------------------------------------------------------------------------------------------- > > Key: WTR-328 > URL: http://jira.openqa.org/browse/WTR-328 > Project: Watir > Issue Type: Sub-task > Components: Xpath Support > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 11) > 'Browser#elements_by_xpath returns an empty Array if there are no matching elements' FAILED > expected nil to be a kind of Array > ./spec/watirspec/browser_spec.rb:236: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From alister.scott at gmail.com Fri Oct 29 00:42:02 2010 From: alister.scott at gmail.com (Alister Scott) Date: Fri, 29 Oct 2010 14:42:02 +1000 Subject: [Wtr-development] A solution for JavaScript dialogs in Watir In-Reply-To: References: Message-ID: I forgot to mention, I can't get this working in Firefox, only IE at the moment. Cheers, Alister On Fri, Oct 29, 2010 at 12:16 PM, Alister Scott wrote: > Hi, > > One of the guys I am working with setting up Cucumber and Watir on a > ThoughtWorks project told me about a way to get rid of the pesky JavaScript > dialogs that cause Watir scripts to be unstable. It involves overriding the > JavaScript function to always return true, so the dialogs never appear. > > I wrote an example for Watir: > > require 'rubygems' > require 'watir' > b = Watir::Browser.start " > http://www.sislands.com/coin70/week1/dialogbox.htm" > b.execute_script "window.confirm = function() { return true; }" > b.execute_script "window.alert = function() { return true; }" > b.execute_script "window.prompt = function() { return true; }" > b.button(:value => 'confirm').click > > > What do you think of this? Is it worthwhile putting this out for Watir > users to see and use? > > Cheers, > > Alister Scott > Brisbane, Australia > Watir Web Master: http://watir.com > 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* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Fri Oct 29 01:44:05 2010 From: jarmo.p at gmail.com (Jarmo) Date: Fri, 29 Oct 2010 08:44:05 +0300 Subject: [Wtr-development] A solution for JavaScript dialogs in Watir In-Reply-To: References: Message-ID: Jari did something like that in watir-webdriver some time ago with an extension: http://stackoverflow.com/questions/3652582/alert-box-in-waitr-webdriver/3662741#3662741 I don't see any reason why not implement something similar or even the exactly same thing into Watir also. Also, you might not to return always "true" for confirm :) Jarmo On Fri, Oct 29, 2010 at 5:16 AM, Alister Scott wrote: > Hi, > > One of the guys I am working with setting up Cucumber and Watir on a > ThoughtWorks project told me about a way to get rid of the pesky JavaScript > dialogs that cause Watir scripts to be unstable. It involves overriding the > JavaScript function to always return true, so the dialogs never appear. > > I wrote an example for Watir: > > require 'rubygems' > require 'watir' > b = Watir::Browser.start > "http://www.sislands.com/coin70/week1/dialogbox.htm" > b.execute_script "window.confirm = function() { return true; }" > b.execute_script "window.alert = function() { return true; }" > b.execute_script "window.prompt = function() { return true; }" > b.button(:value => 'confirm').click > > > What do you think of this? Is it worthwhile putting this out for Watir users > to see and use? > > Cheers, > > Alister Scott > Brisbane, Australia > Watir Web Master: http://watir.com > 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 > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From watirjira at gmail.com Wed Oct 27 15:42:26 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:26 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-257) Attach method in Firewatir doesnot wait for the window to be loaded completely before returning from the method. [patch] Message-ID: <3725111.348.1288208546406.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-257: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > Attach method in Firewatir doesnot wait for the window to be loaded completely before returning from the method. [patch] > ------------------------------------------------------------------------------------------------------------------------ > > Key: WTR-257 > URL: http://jira.openqa.org/browse/WTR-257 > Project: Watir > Issue Type: Bug > Components: Window Attachment > Affects Versions: 1.6.0 > Environment: Windows xp, FireWatir 1.2 > Reporter: Tony > Priority: Major > Fix For: Soon > > > After attaching to the firefox window, the method returns even if the window is loading. > In Watir the attach method returns only after the window has been loaded. > Expected: > Attach to a window and wait for the window to load. > Solution: > add wait() to the method attach(how, what) before self > def attach(how, what) > window_number = find_window(how, what) > if(window_number == 0) > raise NoMatchingWindowFoundException.new("Unable to locate window, using #{how} and #{what}") > elsif(window_number > 0) > # Push the window_title and window_url of parent window. So that when we close the child window > # appropriate handle of parent window is returned back. > @@window_stack.push(@window_title) > @@window_stack.push(@window_url) > @@current_window = window_number.to_i > set_browser_document() > end > wait() ######## -- wait() added so attached window will wait for page to be loaded > self > end -- 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 Oct 27 15:42:25 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:25 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-329) watirspec: Option#selected? not implemented Message-ID: <8115066.328.1288208545670.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-329: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > watirspec: Option#selected? not implemented > ------------------------------------------- > > Key: WTR-329 > URL: http://jira.openqa.org/browse/WTR-329 > Project: Watir > Issue Type: Sub-task > Components: HTML Controls > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Assignee: Jari Bakken > Priority: Major > Fix For: Soon > > > 99) > NoMethodError in 'Option#select selects the option when found by text (select_list context)' > undefined method `selected?' for # > ./spec/watirspec/option_spec.rb:97: -- 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 Oct 29 04:47:20 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Fri, 29 Oct 2010 03:47:20 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-340) watirspec: Image#save and FileField#set should fix path for windows Message-ID: <26669767.462.1288342040568.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19983#action_19983 ] Zeljko commented on WTR-340: ---------------------------- I did not even know that Watir could save images. This is for saving image from a web page? Not for taking a screen shot and saving that as an image? > watirspec: Image#save and FileField#set should fix path for windows > ------------------------------------------------------------------- > > Key: WTR-340 > URL: http://jira.openqa.org/browse/WTR-340 > Project: Watir > Issue Type: Sub-task > Components: Save File > Affects Versions: 1.6.2 > Environment: Watir::IE on WinXP > Reporter: Jari Bakken > Fix For: Soon > > > 61) > 'Image#save saves an image to file' FAILED > expected true, got false > ./spec/watirspec/image_spec.rb:208: > 32) > 'FileField#set is able to set a file path in the field and click the upload button and fire the onchange event' FAILED > expected: "Z:/git/watir/spec/watirspec/filefield_spec.rb", > got: "" (using ==) > ./spec/watirspec/filefield_spec.rb:114: -- 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 Oct 27 15:42:26 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:26 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-315) Firewatir does not accept options supplied through Watir::Browser Message-ID: <23268905.338.1288208546004.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-315: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > Firewatir does not accept options supplied through Watir::Browser > ----------------------------------------------------------------- > > Key: WTR-315 > URL: http://jira.openqa.org/browse/WTR-315 > Project: Watir > Issue Type: Bug > Components: FireWatir > Affects Versions: 1.6.2 > Environment: Ruby 1.8.6 > Watir 1.6.2 > On Windows XP > Reporter: Alex Collins > Fix For: Soon > > > I think there should be an options() method on the Firefox class to support this, with this used for configuration options. FireWatir actually takes the options through the constructor method. > Needs proper investigation. > Needs method implemented and tests created, to ensure that options supplied through the Watir.options_file are correctly passed to FireWatir. > From the email: > I'm trying to override the :waitTime option that is seen on firewatir-1.6.2\lib\firewatir\firefox.rb by using an external .yml file to config my system. > The easy way is just to modify Firefox.initialize and hard code the value (line 134 of firefox.rb), but it seems that setting the value via a yml config should be do'able too. > > Ideally, I would like to use something like this > require 'Watir' > Watir.options_file = 'Q:\\Ruby\\Data\\browser_options.yml' > b=Watir::Browser.new() > # New FF window appears with a 20 second connection timeout, instead of the normal 2 second timeout > > with the following optionfile settings > browser: firefox > waitTime: 20 > > to load up all the options for use in FireFox - specifically set the default timeout for trying to connect to FireFox. > > I've done some investigation to see how the options are sent to FireWatir, but I'm afraid that I'm missing something. Also seeing if this is the long way around, or am I on the right track? > > Some things that I tried: > Modified watir/browsers.rb to send in :options => [:waitTime] when using Firefox > Modified watir/options.rb to add_choice named :waitTime of :type => :integer and :default => 10 > Modified firewater/Firefox.rb - initialize to puts waitTime - so I can see the current value > > I'm pretty sure that I need to find out how to send in :waitTime to Firefox.initialize, but I'm unsure on how to accomplish this. -- 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 Oct 27 15:42:26 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:26 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-224) FireWatir support for Multiple Browsers [patch] Message-ID: <6383345.360.1288208546887.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-224: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > FireWatir support for Multiple Browsers [patch] > ----------------------------------------------- > > Key: WTR-224 > URL: http://jira.openqa.org/browse/WTR-224 > Project: Watir > Issue Type: New Feature > Components: FireWatir > Reporter: Bret Pettichord > Priority: Major > Fix For: Soon > > > patch for multiple browsers from http://pastie.caboo.se/111648 firewatir group post: http://groups.google.com/group/firewatir/browse_thread/thread/9111c7a10f119a13 > see also commit 134 to the firewatir/googlecode repository, where this was initially comitted (before being backed out). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From zeljko.filipin at wa-research.ch Fri Oct 29 09:53:07 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Fri, 29 Oct 2010 15:53:07 +0200 Subject: [Wtr-development] Two Types of Dialogs In-Reply-To: References: Message-ID: On Fri, Oct 29, 2010 at 4:51 AM, Bret Pettichord wrote: > 1. showModalDialog = Watir#modal_dialog. All I know about popups is at our Pop Ups wiki page [1]. I do not have to deal with any kind of popups, except file uploads [2]. I guess you are talking about modal dialogs [3]. > 2. There are lots of other popups as well, many of which can be handled by AutoIt. Pop Ups page lists 11 other types of popups. > I wrote the special version of win32ole to support them and recently suggested we break this code out into a separate gem. I think I understand now. I agree that it is a good idea. It is not good that we are tied to one particular version of Ruby only to support just one feature, that most of the people do not use. ?eljko -- [1] http://wiki.openqa.org/display/WTR/Pop+Ups [2] http://wiki.openqa.org/display/WTR/File+Uploads [3] http://wiki.openqa.org/display/WTR/Modal+Dialogs -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Fri Oct 29 11:32:25 2010 From: bret at pettichord.com (Bret Pettichord) Date: Fri, 29 Oct 2010 10:32:25 -0500 Subject: [Wtr-development] Two Types of Dialogs In-Reply-To: References: Message-ID: Yes, this is what I meant. I am proposing to extract the support for http://wiki.openqa.org/display/WTR/Modal+Dialogs Into a separate gem. Please understand that nearly all the various popups can properly be described as modal and as dialogs. Thus the problem of terminology. The best solution i have right now is to call these showModalDialogs, as that is the name of the javascript method that creates them. Bret On Fri, Oct 29, 2010 at 8:53 AM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Fri, Oct 29, 2010 at 4:51 AM, Bret Pettichord > wrote: > > 1. showModalDialog = Watir#modal_dialog. > > All I know about popups is at our Pop Ups wiki page [1]. I do not have to > deal with any kind of popups, except file uploads [2]. I guess you are > talking about modal dialogs [3]. > > > > 2. There are lots of other popups as well, many of which can be handled > by AutoIt. > > Pop Ups page lists 11 other types of popups. > > > > I wrote the special version of win32ole to support them and recently > suggested we break this code out into a separate gem. > > I think I understand now. I agree that it is a good idea. It is not good > that we are tied to one particular version of Ruby only to support just one > feature, that most of the people do not use. > > ?eljko > -- > [1] http://wiki.openqa.org/display/WTR/Pop+Ups > [2] http://wiki.openqa.org/display/WTR/File+Uploads > [3] http://wiki.openqa.org/display/WTR/Modal+Dialogs > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Fri Oct 29 11:35:51 2010 From: bret at pettichord.com (Bret Pettichord) Date: Fri, 29 Oct 2010 10:35:51 -0500 Subject: [Wtr-development] A solution for JavaScript dialogs in Watir In-Reply-To: References: Message-ID: Yes, this is what Selenium has done from day one (which is why ThoughtWorkers know about it). It, in fact, is the only way that Selenium can handle these. There are pros and cons to using this technique. But no reason not to share with people. Some testers will be disturbed when they learn it eliminates the dialogs entirely. I don't use it personally, because I have other methods that work. Bret On Thu, Oct 28, 2010 at 9:16 PM, Alister Scott wrote: > Hi, > > One of the guys I am working with setting up Cucumber and Watir on a > ThoughtWorks project told me about a way to get rid of the pesky JavaScript > dialogs that cause Watir scripts to be unstable. It involves overriding the > JavaScript function to always return true, so the dialogs never appear. > > I wrote an example for Watir: > > require 'rubygems' > require 'watir' > b = Watir::Browser.start " > http://www.sislands.com/coin70/week1/dialogbox.htm" > b.execute_script "window.confirm = function() { return true; }" > b.execute_script "window.alert = function() { return true; }" > b.execute_script "window.prompt = function() { return true; }" > b.button(:value => 'confirm').click > > > What do you think of this? Is it worthwhile putting this out for Watir > users to see and use? > > Cheers, > > Alister Scott > Brisbane, Australia > Watir Web Master: http://watir.com > 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* > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Fri Oct 29 11:37:33 2010 From: bret at pettichord.com (Bret Pettichord) Date: Fri, 29 Oct 2010 10:37:33 -0500 Subject: [Wtr-development] A solution for JavaScript dialogs in Watir In-Reply-To: References: Message-ID: You can add the technique to this page: http://wiki.openqa.org/display/WTR/JavaScript+Pop+Ups Bret On Thu, Oct 28, 2010 at 11:42 PM, Alister Scott wrote: > I forgot to mention, I can't get this working in Firefox, only IE at the > moment. > > Cheers, > Alister > > > On Fri, Oct 29, 2010 at 12:16 PM, Alister Scott wrote: > >> Hi, >> >> One of the guys I am working with setting up Cucumber and Watir on a >> ThoughtWorks project told me about a way to get rid of the pesky JavaScript >> dialogs that cause Watir scripts to be unstable. It involves overriding the >> JavaScript function to always return true, so the dialogs never appear. >> >> I wrote an example for Watir: >> >> require 'rubygems' >> require 'watir' >> b = Watir::Browser.start " >> http://www.sislands.com/coin70/week1/dialogbox.htm" >> b.execute_script "window.confirm = function() { return true; }" >> b.execute_script "window.alert = function() { return true; }" >> b.execute_script "window.prompt = function() { return true; }" >> b.button(:value => 'confirm').click >> >> >> What do you think of this? Is it worthwhile putting this out for Watir >> users to see and use? >> >> Cheers, >> >> Alister Scott >> Brisbane, Australia >> Watir Web Master: http://watir.com >> 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* >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Wed Oct 27 15:42:26 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:26 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-281) add exists? for frames Message-ID: <11148364.344.1288208546207.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-281: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > add exists? for frames > ---------------------- > > Key: WTR-281 > URL: http://jira.openqa.org/browse/WTR-281 > Project: Watir > Issue Type: New Feature > Components: Frame > Affects Versions: 1.6.2 > Environment: x > Reporter: Charley Baker > Assignee: Bret Pettichord > Fix For: Soon > > > This has come up in the mailing list a few times. Monkey patch from MHwee: > Michael Hwee > to watir-general > > frame does not support exists?(). > However, you can *monkey-patch* as followed. > module Watir > class Frame > alias_method :_locate, :locate > def locate > begin > return _locate > rescue > return nil > end > end > def exists? > return @o != nil > end > end > end > Michael -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Wed Oct 27 15:42:26 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:26 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-285) FireWatir doesn't work on JRuby [patch] Message-ID: <11767903.340.1288208546100.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-285: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > FireWatir doesn't work on JRuby [patch] > --------------------------------------- > > Key: WTR-285 > URL: http://jira.openqa.org/browse/WTR-285 > Project: Watir > Issue Type: Improvement > Components: FireWatir > Affects Versions: 1.6.2 > Environment: JRuby > Reporter: Mike Andrzejewski > Priority: Blocker > Fix For: Soon > > Attachments: firewatir_jruby.patch > > > On JRuby, browser's binary detection according to platform does'nt work. > Here is a patch to lib/firewatir/firefox.rb to support JRuby on any platform : > --- gems/firewatir-1.6.2/lib/firewatir/firefox.rb 2009-02-05 12:26:00.000000000 +0100 > +++ gems/firewatir-1.6.2/lib/firewatir/firefox.rb 2009-02-05 14:33:42.000000000 +0100 > @@ -133,8 +133,12 @@ > > waitTime = options[:waitTime] || 2 > > - case RUBY_PLATFORM > - when /mswin/ > + platform = RUBY_PLATFORM > + if platform.start_with?("java") > + platform = java.lang.System.getProperty("os.name") > + end > + case platform > + when /mswin|windows/i > # Get the path to Firefox.exe using Registry. > require 'win32/registry.rb' > path_to_bin = "" > @@ -150,10 +154,8 @@ > > when /linux/i > path_to_bin = `which firefox`.strip > - when /darwin/i > + when /darwin|mac os/i > path_to_bin = '/Applications/Firefox.app/Contents/MacOS/firefox' > - when /java/ > - raise "Not implemented: Create a browser finder in JRuby" > end > @t = Thread.new { system("#{path_to_bin} -jssh #{profile_opt}")} > sleep waitTime -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From jarmo.p at gmail.com Fri Oct 29 12:26:31 2010 From: jarmo.p at gmail.com (Jarmo) Date: Fri, 29 Oct 2010 19:26:31 +0300 Subject: [Wtr-development] Two Types of Dialogs In-Reply-To: References: Message-ID: But why is the custom win32ole needed for these? Jarmo On Fri, Oct 29, 2010 at 6:32 PM, Bret Pettichord wrote: > Yes, this is what I meant. > > I am proposing to extract the support for > ? http://wiki.openqa.org/display/WTR/Modal+Dialogs > > Into a separate gem. Please understand that nearly all the various popups > can properly be described as modal and as dialogs. Thus the problem of > terminology. > > The best solution i have right now is to call these showModalDialogs, as > that is the name of the javascript method that creates them. > > Bret > > On Fri, Oct 29, 2010 at 8:53 AM, ?eljko Filipin > wrote: >> >> On Fri, Oct 29, 2010 at 4:51 AM, Bret Pettichord >> wrote: >> > 1. showModalDialog = Watir#modal_dialog. >> >> All I know about popups is at our Pop Ups wiki page [1]. I do not have to >> deal with any kind of popups, except file uploads [2]. I guess you are >> talking about modal dialogs [3]. >> >> > 2. There are lots of other popups as well, many of which can be handled >> > by AutoIt. >> >> Pop Ups page lists 11 other types of popups. >> >> > I wrote the special version of win32ole to support them and recently >> > suggested we break this code out into a separate gem. >> >> I think I understand now. I agree that it is a good idea. It is not good >> that we are tied to one particular version of Ruby only to support just one >> feature, that most of the people do not use. >> >> ?eljko >> -- >> [1] http://wiki.openqa.org/display/WTR/Pop+Ups >> [2] http://wiki.openqa.org/display/WTR/File+Uploads >> [3] http://wiki.openqa.org/display/WTR/Modal+Dialogs >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From jarmo.p at gmail.com Fri Oct 29 12:34:44 2010 From: jarmo.p at gmail.com (Jarmo) Date: Fri, 29 Oct 2010 19:34:44 +0300 Subject: [Wtr-development] A solution for JavaScript dialogs in Watir In-Reply-To: References: Message-ID: Why not add those working methods to that wikipage also? I'd vote to clean up that wikipage since it has a lot of complex and ugly code there. Also, i'm in favor of using the solutions provided by Jari, since javascript dialogs are usually pointless and if you really need to test the existence of them then you could it one time - at some specific test, which tests that the dialog appears. All the other time you could just ignore them and this solution would be the way to do it. Jarmo On Fri, Oct 29, 2010 at 6:35 PM, Bret Pettichord wrote: > Yes, this is what Selenium has done from day one (which is why > ThoughtWorkers know about it). It, in fact, is the only way that Selenium > can handle these. > > There are pros and cons to using this technique. But no reason not to share > with people. Some testers will be disturbed when they learn it eliminates > the dialogs entirely. I don't use it personally, because I have other > methods that work. > > Bret > > On Thu, Oct 28, 2010 at 9:16 PM, Alister Scott > wrote: >> >> Hi, >> >> One of the guys I am working with setting up Cucumber and Watir on a >> ThoughtWorks project told me about a way to get rid of the pesky JavaScript >> dialogs that cause Watir scripts to be unstable. It involves overriding the >> JavaScript function to always return true, so the dialogs never appear. >> >> I wrote an example for Watir: >> >> require 'rubygems' >> require 'watir' >> b = Watir::Browser.start >> "http://www.sislands.com/coin70/week1/dialogbox.htm" >> b.execute_script "window.confirm = function() { return true; }" >> b.execute_script "window.alert = function() { return true; }" >> b.execute_script "window.prompt = function() { return true; }" >> b.button(:value => 'confirm').click >> >> >> What do you think of this? Is it worthwhile putting this out for Watir >> users to see and use? >> >> Cheers, >> >> Alister Scott >> Brisbane, Australia >> Watir Web Master: http://watir.com >> 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 >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From jari.bakken at gmail.com Fri Oct 29 12:38:26 2010 From: jari.bakken at gmail.com (Jari Bakken) Date: Fri, 29 Oct 2010 22:08:26 +0530 Subject: [Wtr-development] A solution for JavaScript dialogs in Watir In-Reply-To: References: Message-ID: <283480053526741930@unknownmsgid> watir-webdriver has a decent Ruby API for this as an optional require: http://github.com/jarib/watir-webdriver/blob/master/lib/watir-webdriver/extensions/alerts.rb Feel free to use it in Watir. I might change it when WebDriver provides its own solution though. Den 29. okt. 2010 kl. 21:23 skrev Bret Pettichord : You can add the technique to this page: http://wiki.openqa.org/display/WTR/JavaScript+Pop+Ups Bret On Thu, Oct 28, 2010 at 11:42 PM, Alister Scott wrote: > I forgot to mention, I can't get this working in Firefox, only IE at the > moment. > > Cheers, > Alister > > > On Fri, Oct 29, 2010 at 12:16 PM, Alister Scott wrote: > >> Hi, >> >> One of the guys I am working with setting up Cucumber and Watir on a >> ThoughtWorks project told me about a way to get rid of the pesky JavaScript >> dialogs that cause Watir scripts to be unstable. It involves overriding the >> JavaScript function to always return true, so the dialogs never appear. >> >> I wrote an example for Watir: >> >> require 'rubygems' >> require 'watir' >> b = Watir::Browser.start " >> http://www.sislands.com/coin70/week1/dialogbox.htm" >> b.execute_script "window.confirm = function() { return true; }" >> b.execute_script "window.alert = function() { return true; }" >> b.execute_script "window.prompt = function() { return true; }" >> b.button(:value => 'confirm').click >> >> >> What do you think of this? Is it worthwhile putting this out for Watir >> users to see and use? >> >> Cheers, >> >> Alister Scott >> Brisbane, Australia >> Watir Web Master: http://watir.com >> 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* >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord _______________________________________________ Wtr-development mailing list Wtr-development at rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-development -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Fri Oct 29 13:59:21 2010 From: bret at pettichord.com (Bret Pettichord) Date: Fri, 29 Oct 2010 12:59:21 -0500 Subject: [Wtr-development] Two Types of Dialogs In-Reply-To: References: Message-ID: Because I wasn't smart enough to figure out how to do it without changing win32ole. Our support for show-modal-dialogs is written in C. Some have suggested rewriting this C code so that it doesn't have this dependency. I'm all for it. Bret On Fri, Oct 29, 2010 at 11:26 AM, Jarmo wrote: > But why is the custom win32ole needed for these? > > Jarmo > > On Fri, Oct 29, 2010 at 6:32 PM, Bret Pettichord > wrote: > > Yes, this is what I meant. > > > > I am proposing to extract the support for > > http://wiki.openqa.org/display/WTR/Modal+Dialogs > > > > Into a separate gem. Please understand that nearly all the various popups > > can properly be described as modal and as dialogs. Thus the problem of > > terminology. > > > > The best solution i have right now is to call these showModalDialogs, as > > that is the name of the javascript method that creates them. > > > > Bret > > > > On Fri, Oct 29, 2010 at 8:53 AM, ?eljko Filipin > > wrote: > >> > >> On Fri, Oct 29, 2010 at 4:51 AM, Bret Pettichord > >> wrote: > >> > 1. showModalDialog = Watir#modal_dialog. > >> > >> All I know about popups is at our Pop Ups wiki page [1]. I do not have > to > >> deal with any kind of popups, except file uploads [2]. I guess you are > >> talking about modal dialogs [3]. > >> > >> > 2. There are lots of other popups as well, many of which can be > handled > >> > by AutoIt. > >> > >> Pop Ups page lists 11 other types of popups. > >> > >> > I wrote the special version of win32ole to support them and recently > >> > suggested we break this code out into a separate gem. > >> > >> I think I understand now. I agree that it is a good idea. It is not good > >> that we are tied to one particular version of Ruby only to support just > one > >> feature, that most of the people do not use. > >> > >> ?eljko > >> -- > >> [1] http://wiki.openqa.org/display/WTR/Pop+Ups > >> [2] http://wiki.openqa.org/display/WTR/File+Uploads > >> [3] http://wiki.openqa.org/display/WTR/Modal+Dialogs > >> > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > > > > > -- > > Bret Pettichord > > Lead Developer, Watir, www.watir.com > > > > Blog, www.io.com/~wazmo/blog > > Twitter, www.twitter.com/bpettichord > > > > > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From notethan at gmail.com Fri Oct 29 15:27:25 2010 From: notethan at gmail.com (Ethan) Date: Fri, 29 Oct 2010 15:27:25 -0400 Subject: [Wtr-development] Two Types of Dialogs In-Reply-To: References: Message-ID: Bret > showModalDialog = Watir#modal_dialog. It is one kind of dialog, that is > only supported by IE. Watir has unique support for this kind of dialog. Vapir has a consistent API for dealing with showModalDialog windows across IE and firefox ( http://github.com/vapir/vapir/wiki/Modal-Dialogs ), which I've mentioned on this list before, to some discussion that didn't really go anywhere. For IE, only ruby 1.8 is supported as it relies on the same WIN32OLE extensions as watir - fixing this is a matter of compiling it for 1.9, and preferably not including a copy of the rest of WIN32OLE in the same file (since WIN32OLE has changed somewhat between 1.8 and 1.9). On other ruby versions, Vapir falls back to the included WIN32OLE and simply doesn't have IE support for showModalDialog dialogs. I don't see why this would belong in a different gem. Watir just needs to get a decent API and implementation down - I've suggested before (talking to Charley, if I recall correctly) that this would be good code to merge into Watir from Vapir. -Ethan On Fri, Oct 29, 2010 at 13:59, Bret Pettichord wrote: > Because I wasn't smart enough to figure out how to do it without changing > win32ole. > > Our support for show-modal-dialogs is written in C. Some have suggested > rewriting this C code so that it doesn't have this dependency. I'm all for > it. > > Bret > > > On Fri, Oct 29, 2010 at 11:26 AM, Jarmo wrote: > >> But why is the custom win32ole needed for these? >> >> Jarmo >> >> On Fri, Oct 29, 2010 at 6:32 PM, Bret Pettichord >> wrote: >> > Yes, this is what I meant. >> > >> > I am proposing to extract the support for >> > http://wiki.openqa.org/display/WTR/Modal+Dialogs >> > >> > Into a separate gem. Please understand that nearly all the various >> popups >> > can properly be described as modal and as dialogs. Thus the problem of >> > terminology. >> > >> > The best solution i have right now is to call these showModalDialogs, as >> > that is the name of the javascript method that creates them. >> > >> > Bret >> > >> > On Fri, Oct 29, 2010 at 8:53 AM, ?eljko Filipin >> > wrote: >> >> >> >> On Fri, Oct 29, 2010 at 4:51 AM, Bret Pettichord >> >> wrote: >> >> > 1. showModalDialog = Watir#modal_dialog. >> >> >> >> All I know about popups is at our Pop Ups wiki page [1]. I do not have >> to >> >> deal with any kind of popups, except file uploads [2]. I guess you are >> >> talking about modal dialogs [3]. >> >> >> >> > 2. There are lots of other popups as well, many of which can be >> handled >> >> > by AutoIt. >> >> >> >> Pop Ups page lists 11 other types of popups. >> >> >> >> > I wrote the special version of win32ole to support them and recently >> >> > suggested we break this code out into a separate gem. >> >> >> >> I think I understand now. I agree that it is a good idea. It is not >> good >> >> that we are tied to one particular version of Ruby only to support just >> one >> >> feature, that most of the people do not use. >> >> >> >> ?eljko >> >> -- >> >> [1] http://wiki.openqa.org/display/WTR/Pop+Ups >> >> [2] http://wiki.openqa.org/display/WTR/File+Uploads >> >> [3] http://wiki.openqa.org/display/WTR/Modal+Dialogs >> >> >> >> _______________________________________________ >> >> Wtr-development mailing list >> >> Wtr-development at rubyforge.org >> >> http://rubyforge.org/mailman/listinfo/wtr-development >> > >> > >> > >> > -- >> > Bret Pettichord >> > Lead Developer, Watir, www.watir.com >> > >> > Blog, www.io.com/~wazmo/blog >> > Twitter, www.twitter.com/bpettichord >> > >> > >> > _______________________________________________ >> > Wtr-development mailing list >> > Wtr-development at rubyforge.org >> > http://rubyforge.org/mailman/listinfo/wtr-development >> > >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Wed Oct 27 15:42:27 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:27 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-197) IE7 - focus goes to address bar after certain actions, and .focus doesn't work when focus is in address bar Message-ID: <32020073.370.1288208547368.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-197: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > IE7 - focus goes to address bar after certain actions, and .focus doesn't work when focus is in address bar > ----------------------------------------------------------------------------------------------------------- > > Key: WTR-197 > URL: http://jira.openqa.org/browse/WTR-197 > Project: Watir > Issue Type: Bug > Components: Inputs > Affects Versions: 1.5.3 > Environment: IE7 > Windows XP SP2 and Windows 2003 Server SP1 > Watir 1.5.3 - 1.5.6 > Ruby 1.8.5 > Reporter: sCrIpT mUnKeE > Priority: Major > Fix For: Soon > > > In the example below I have demonstrated that when > you use the focus method on a text_field in IE7, the actually browser > focus is not set. The field does not receive the inputed text for > "send_keys" and the "Enter" key is not registered with the "search" > button. > I first noticed this issue with the web application I am testing. Our > web application contains iFrame, but I don't think this is an issue, > and I have noticed that when the page starts the address bar of IE 7 > never looses focus. It start active not matter what interactions I do > with the browser. > IE 7 Focus Example: > # starting the test > require 'watir' > ie = Watir::IE.start() > ie.goto("http://flickr.com") > # focusing the text field, because the web site does not set focus > automatically > ie.div(:id, 'featured-search').text_field(:index, 1).focus() > # adding text to the search field > ie.send_keys("{self}") > #ie.div(:id, 'featured-search').text_field(:index, 1).set("self") # > This also failes > # sending an Enter key to execute the search > ie.send_keys("{ENTER}") -- 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 Oct 27 15:42:26 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:26 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-221) Get the text from a frame [patch] Message-ID: <892443.362.1288208546950.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-221: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > Get the text from a frame [patch] > --------------------------------- > > Key: WTR-221 > URL: http://jira.openqa.org/browse/WTR-221 > Project: Watir > Issue Type: New Feature > Components: FireWatir > Affects Versions: 1.6.7 > Reporter: Bret Pettichord > Priority: Major > Fix For: Soon > > > Paul Rogers on the firewatir list: > try this > class Frame > def url > locate > jssh_socket.send("#{DOCUMENT_VAR}.URL;\n", 0) > window_url = read_socket() > return window_url > end > def text > assert_exists > get_frame_text > end > end > class Element > def get_frame_text > jssh_socket.send("var htmlelem = > #{DOCUMENT_VAR}.getElementsByTagName('html')[0]; htmlelem.textContent; > \n", 0) > result = read_socket() > return result > end > end > jst add these lines after your require 'firewatir' line > Paul > On May 26, 6:58 am, MarioRuiz wrote: > > > A full example: > > > > > > require 'firewatir' > > > require 'watir' > > > ie=Watir::IE.new() > > > ff=FireWatir::Firefox.new() > > > url="http://www.tlwilliams.net/NOCCC/0005/0005pFrame.html" > > > frame="menu" > > > > > > ff.goto(url) > > > ie.goto(url) > > > > > > puts "************************ FIREFOX *************************" > > > myframe=ff.frame(frame) > > > puts myframe.text() > > > > > > puts "************************ INTERNET EXPLORER > > > *************************" > > > myframe=ie.frame(frame) > > > puts myframe.text() > > > > > > ff.close() > > > ie.close() > > > > > > The result is: > > > > > > Starting Firefox using the executable : C:\Program Files\Mozilla > > > Firefox\firefox.exe > > > Waiting for 2 seconds for Firefox to get started. > > > ************************ FIREFOX ************************* > > > > > > ************************ INTERNET EXPLORER ************************* > > > Web Publishing - Using Frames in HTMLFrames > > > > > > __5.0_Introduction_to_Frames > > > > > > __5.1_Using_Frames > > > > > > __5.2_Complex_Frames > > > > > > __5.3_Floating_Frames > > > > > > __5.4_References > > > > > > As you can see we don't have any text content from firewatir. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From alister.scott at gmail.com Fri Oct 29 17:52:36 2010 From: alister.scott at gmail.com (Alister Scott) Date: Sat, 30 Oct 2010 07:52:36 +1000 Subject: [Wtr-development] A solution for JavaScript dialogs in Watir In-Reply-To: <283480053526741930@unknownmsgid> References: <283480053526741930@unknownmsgid> Message-ID: <5041064815485816556@unknownmsgid> Any ideas why my code won't work in FireWatir? Cheers, Alister. On 30/10/2010, at 6:47 AM, Jari Bakken wrote: watir-webdriver has a decent Ruby API for this as an optional require: http://github.com/jarib/watir-webdriver/blob/master/lib/watir-webdriver/extensions/alerts.rb Feel free to use it in Watir. I might change it when WebDriver provides its own solution though. Den 29. okt. 2010 kl. 21:23 skrev Bret Pettichord : You can add the technique to this page: http://wiki.openqa.org/display/WTR/JavaScript+Pop+Ups Bret On Thu, Oct 28, 2010 at 11:42 PM, Alister Scott < alister.scott at gmail.com> wrote: > I forgot to mention, I can't get this working in Firefox, only IE at the > moment. > > Cheers, > Alister > > > On Fri, Oct 29, 2010 at 12:16 PM, Alister Scott < > alister.scott at gmail.com> wrote: > >> Hi, >> >> One of the guys I am working with setting up Cucumber and Watir on a >> ThoughtWorks project told me about a way to get rid of the pesky JavaScript >> dialogs that cause Watir scripts to be unstable. It involves overriding the >> JavaScript function to always return true, so the dialogs never appear. >> >> I wrote an example for Watir: >> >> require 'rubygems' >> require 'watir' >> b = Watir::Browser.start " >> http://www.sislands.com/coin70/week1/dialogbox.htm" >> b.execute_script "window.confirm = function() { return true; }" >> b.execute_script "window.alert = function() { return true; }" >> b.execute_script "window.prompt = function() { return true; }" >> b.button(:value => 'confirm').click >> >> >> What do you think of this? Is it worthwhile putting this out for Watir >> users to see and use? >> >> Cheers, >> >> Alister Scott >> Brisbane, Australia >> Watir Web Master: http://watir.com >> 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* >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord _______________________________________________ Wtr-development mailing list Wtr-development at rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-development _______________________________________________ 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 Wed Oct 27 15:42:26 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:26 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-270) Watir 1.6.2: Watir::Exception::UnknownObjectException when accessing image via :src (Firefox) Message-ID: <17842411.346.1288208546321.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-270: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > Watir 1.6.2: Watir::Exception::UnknownObjectException when accessing image via :src (Firefox) > --------------------------------------------------------------------------------------------- > > Key: WTR-270 > URL: http://jira.openqa.org/browse/WTR-270 > Project: Watir > Issue Type: Bug > Components: FireWatir > Affects Versions: 1.6.2 > Environment: Windows XP > Reporter: John Fitisoff > Priority: Major > Fix For: Soon > > > I'm starting to look at porting our test framework over to 1.6.2 from 1.4.1 and ran into a problem clicking on images. See steps below. > require 'watir/browser' > Watir::Browser.default = 'firefox' > b.goto('www.google.com') > b.image(:src, 'http://www.google.com/intl/en_ALL/images/logo.gif').click > No problems with IE. Don't have a Safari environment yet. Stack trace: > Watir::Exception::UnknownObjectException: Unable to locate element, using :src, "http://www.google.com/intl/en_ALL/images/logo.gif" > from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.2/lib/firewatir/MozillaBaseElement.rb:967:in `assert_exists' > from c:/ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.2/lib/firewatir/MozillaBaseElement.rb:1112:in `click' > from (irb):3:in `breakpoint' > from c:/ruby/lib/ruby/site_ruby/1.8/breakpoint.rb:563:in `breakpoint' > from C:/eclipse/perforce_workspace/eng/test/watir/framework/ui.rb:144:in `start_session' > from C:/eclipse/perforce_workspace/eng/test/watir/framework/ui.rb:218 -- 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 Oct 27 15:42:26 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:26 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-232) Add down_load_time feature Message-ID: <19705632.356.1288208546739.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-232: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > Add down_load_time feature > -------------------------- > > Key: WTR-232 > URL: http://jira.openqa.org/browse/WTR-232 > Project: Watir > Issue Type: New Feature > Components: FireWatir > Environment: Windows XP > Reporter: Ravid Te > Fix For: Soon > > > Would it be possible to add this feature, which is present in Watir, into FireWatir? This way people who use the down_load_time function in Watir, would not have to edit their scripts so much to make them work for FF as well. -- 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 Oct 27 15:42:26 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:26 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-238) .flash method Message-ID: <8668784.354.1288208546657.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-238: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > .flash method > ------------- > > Key: WTR-238 > URL: http://jira.openqa.org/browse/WTR-238 > Project: Watir > Issue Type: New Feature > Components: FireWatir > Affects Versions: 1.5.3, 1.5.4, 1.5.5, 1.5.6 > Environment: Firewatir - MacOSX > Reporter: Sameh Abdelhamid > Fix For: Soon > > > .flash mehod does not work in Firewatir. Same code was tested in Watir (windows) and it works succesfully > The objects I have found work when i use the .click method. Which proves the object is being identified correctly. The object does "flash" yellow, when it is being clicked. > For example if you navigate to the google page: > @f ||= FireWatir::Firefox.new() > @f.button(:name,'btnG').click > (.click clicks the button and flashes yellow as it should > and > @f.button(:name,'btnG').flash > Does not work > Would be great if this feature was added -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From watirjira at gmail.com Wed Oct 27 15:42:26 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:26 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-255) Remove show* methods from Watir Message-ID: <6378030.350.1288208546497.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-255: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > Remove show* methods from Watir > ------------------------------- > > Key: WTR-255 > URL: http://jira.openqa.org/browse/WTR-255 > Project: Watir > Issue Type: Task > Components: Show commands > Affects Versions: 1.5.6 > Reporter: Charley Baker > Fix For: Soon > > > show* methods should be removed in 1.6 version of Watir, elements.show exists already as a wrapper around to_s -- 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 Oct 27 15:42:27 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:27 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-203) Container#forms method and Forms class Message-ID: <33288516.367.1288208547276.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-203: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > Container#forms method and Forms class > -------------------------------------- > > Key: WTR-203 > URL: http://jira.openqa.org/browse/WTR-203 > Project: Watir > Issue Type: New Feature > Components: HTML Controls > Reporter: T. Alexander Lystad > Fix For: Soon > > > Container#forms method and Forms class -- 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 Oct 27 15:42:26 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:26 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-249) Error in Wait Logic [FireWatir] Message-ID: <12424821.352.1288208546602.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-249: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > Error in Wait Logic [FireWatir] > ------------------------------- > > Key: WTR-249 > URL: http://jira.openqa.org/browse/WTR-249 > Project: Watir > Issue Type: Bug > Components: FireWatir > Reporter: Bret Pettichord > Priority: Major > Fix For: Soon > > > -------- Original Message -------- > Subject: wait() and http redirects > Date: Fri, 22 Aug 2008 08:46:35 -0700 (PDT) > From: Cam McHugh > Reply-To: firewatir at googlegroups.com > To: FireWatir > I'm having a problem with a firewatir script that is used to test some > functionality on an page requiring authentication. The authentication > process involves an http redirect (or two) to the auth server and > another redirect back to the desired url after successful > authentication. However, the code being executed after > goto(authenticated_url) is being executed prior to the authentication > process completing. I think the problem is in the wait() function, > specifically this test: > while isLoadingDocument != "false" > isLoadingDocument = > js_eval("#{BROWSER_VAR}=#{WINDOW_VAR}.getBrowser(); > #{BROWSER_VAR}.webProgress.isLoadingDocument;") > #puts "Is browser still loading page: > #{isLoadingDocument}" > ... > end > Does the isLoadingDocument logic take http redirects into > consideration? It seems to evaluate to false in a rather > nondeterministic manner during the redirection process (I "puts'd" the > current url along with the current value of isLoadingDocument), > sometimes waiting until the desired page is loaded, but sometimes > evaluating to false while the browser is still being redirected. > I see code in wait() to account for meta refresh style redirection, so > I'd assume that isLoadingDocument is intended to remain true when the > server response is 301/302, but my results seem to contradict this. > Can anyone shed some light on this for me, and if there's a workaround > that can be used? > Thanks, > Cam -- 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 Oct 27 15:42:27 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:27 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-183) Form doesn't work when used with a parent container [patch] Message-ID: <21346292.373.1288208547552.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-183: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > Form doesn't work when used with a parent container [patch] > ----------------------------------------------------------- > > Key: WTR-183 > URL: http://jira.openqa.org/browse/WTR-183 > Project: Watir > Issue Type: Bug > Components: HTML Controls > Affects Versions: 1.5.2 > Environment: x > Reporter: Charley Baker > Assignee: Bret Pettichord > Priority: Major > Fix For: Soon > > Attachments: form_tests.patch > > > Form code needs to be cleaned up and adhere to the standard element or in this case noncontrolelement definition. This should fix the problem accessing forms by using something like: > ie.div(:name, 'foo').form(:name, 'bar') > which currently throws this exception: > WIN32OLERuntimeError: unknown property or method `forms' > HRESULT error code:0x80020006 > Unknown name. > Unit test and updated html patch is attached to this ticket. -- 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 Oct 27 15:42:27 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:27 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-212) using 1.5.4 modal web page dialog support with ie7 not working Message-ID: <12698141.365.1288208547213.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-212: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > using 1.5.4 modal web page dialog support with ie7 not working > -------------------------------------------------------------- > > Key: WTR-212 > URL: http://jira.openqa.org/browse/WTR-212 > Project: Watir > Issue Type: Bug > Components: Modal Web Dialog > Affects Versions: 1.5.4 > Environment: windows xp, ie7 > Reporter: Marco > Fix For: Soon > > > I am using ie7, xp, ruby 1.8.2, rexml 1.7.3 and watir 1.5.4 and > noticed the attaching to modal web pages did not work. > I found that in modal_dialog.rb if I changed the line > ".... title = "#{what} -- Web Page Dialog" ..." to "....title = > "#{what} -- Webpage Dialog"...." > all started to work nicely. > I guess there must be a difference between ie6 and ie7 on the way it > pops up modal web page dialogs. > I could see two options 1) have the title string built differently > based on IE version or 2) alter the title search method to be in the > style of a regexpression or title contains variant. -- 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 Oct 27 15:42:28 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:28 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-125) Updates to support IE7 Message-ID: <14837597.386.1288208548203.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-125: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > Updates to support IE7 > ---------------------- > > Key: WTR-125 > URL: http://jira.openqa.org/browse/WTR-125 > Project: Watir > Issue Type: Bug > Affects Versions: 1.5.0/1.5.1 > Reporter: Bret Pettichord > Assignee: Charley Baker > Priority: Major > Fix For: Soon > > > In reviewing, the fix for http://jira.openqa.org/browse/WTR-123 in commit http://svn.openqa.org/fisheye/changelog/watir/?cs=1145 i noticed that there are 13 instances of "Microsoft Internet Explorer" in the Watir code base that were not touched by this fix. A quick glance suggests that all of them require changes to work with IE7. -- 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 Oct 27 15:42:27 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:27 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-137) Too many failures in all_tests.rb Message-ID: <10049981.383.1288208548000.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-137: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > Too many failures in all_tests.rb > --------------------------------- > > Key: WTR-137 > URL: http://jira.openqa.org/browse/WTR-137 > Project: Watir > Issue Type: Bug > Affects Versions: 1.5.0/1.5.1 > Reporter: Bret Pettichord > Assignee: Bret Pettichord > Priority: Major > Fix For: Soon > > > We have a number of failures with this suite, many of which are intermittent. We need to figure out what to do -- fix them, remove them -- because these failures just scare our users. -- 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 Oct 27 15:42:27 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:27 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-175) buttons.length method doesn't count > > > WATIR CODE: > ie.buttons.length > #-->0 > ie.buttons[1].exists? > #-->true -- 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 Oct 27 15:42:28 2010 From: watirjira at gmail.com (Charley Baker (JIRA)) Date: Wed, 27 Oct 2010 14:42:28 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-115) modal dialog title text has changed in IE 7.0 Message-ID: <4398403.390.1288208548376.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charley Baker updated WTR-115: ------------------------------ Fix Version/s: (was: 1.6.7) Soon > modal dialog title text has changed in IE 7.0 > --------------------------------------------- > > Key: WTR-115 > URL: http://jira.openqa.org/browse/WTR-115 > Project: Watir > Issue Type: Bug > Components: Modal Web Dialog > Affects Versions: 1.5.0/1.5.1 > Environment: IE 7.0, Windows XP > Reporter: Dara Lillis > Assignee: Charley Baker > Priority: Major > Fix For: Soon > > > in IE 6, the title text of a modal dialog is "Microsoft Internet Explorer" > in IE 7.0, the title text is "Windows Internet Explorer" > the code in watir\dialog.rb expects the IE 6.0 text. > I was able to click on a dialog in IE 7.0 by manually editing dialog.rb and changing "Microsoft" to "Windows" > I would think it shouldn't be too hard to accomodate both, presuming there is a way to get the IE version number from OLE. I'd be happy to work on a fix if someone could give me some help with the WIN32OLE end of things. -- 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