From zeljko.filipin at wa-research.ch Thu Jul 1 03:49:59 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 1 Jul 2010 09:49:59 +0200 Subject: [Wtr-development] Fwd: Donate to Watir In-Reply-To: References: Message-ID: If you like the Watir project, you can make a donation. There is donate button at http://watir.com/. We have raised $595 this year. We will spend it on hosting and stuff like that. You can see list of donors and Bret's thank you note at http://pledgie.com/campaigns/2982 ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Mon Jul 5 16:44:22 2010 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 5 Jul 2010 15:44:22 -0500 Subject: [Wtr-development] cleaning up watir's repo In-Reply-To: References: Message-ID: Thanks for this. Looks like Charley pulled in your changes. Bret On Wed, Jun 16, 2010 at 11:04 AM, marekj wrote: > Hi, I've made some documentation cleanup and rdoc fixes to unify the 3 > separate gems as one project > and I've made a pull request but due to time constraints I didn't > follow up with the maintainers > Here is the branch. > http://github.com/marekj/watir/tree/rdocfix > It has fixes to some of the things you mention. > I resend the pull request > > marekj > > > On Fri, Jun 11, 2010 at 3:13 PM, Jarmo wrote: > > Hello. > > > > I've cloned Watir's whole repo from http://github.com/bret/watir and > > started to take a look on the current situation. > > > > I've started to notice that there's some things which should not be > > maybe there anymore. I propose that these things should be deleted or > > changed (that's why there's version control, isn't it?). Anyway, my > > preliminary proposal is to change these things: > > > > > > * commonwatir: > > 1) History.txt - is there any plan to use it? Currently it just seems > > too empty and has wrong version in it. Delete it? > > 2) README.txt - has a lot of missing information there plus "FIX" > > statements. Clean it up and just leave the license part maybe? > > > > How to run all tests for commonwatir? rake -T doesn't show any tasks > > related with running all the tests from commonwatir... > > > > > > * doc: > > Is 'doc' directory a source for the website wtr.rubyforge.com a.k.a > > watir.com up to date? For me, it seems not to be - so, deleting it or > > making it up to date seem only reasonable options to me. > > > > > > * firewatir: > > 1) CHANGES - it seems to be out of date because latest FireWatir seems > > to be also 1.6.5, but in that file it's 1.2.1... what to do? > > 2) attic directory - delete? > > > > How to run just all firewatir tests? > > > > * watir: > > 1) 'installer' directory seems to be obsolete... correct me if i'm > > wrong. Delete? > > 2) lib/readme.rb - out of date > > 3) unittests/.cvsignore - delete > > 4) building-watir.txt - delete? > > 5) CHANGES - no changes for 1.6.5? > > 6) coding_conventions.txt - is it really needed? delete? > > 7) install_dev_gems.bat - shouldn't .gemspec be used for development > > dependencies instead? delete? > > 8) NEWCHANGES? Why is it even a separate file? And if it has changes > > for Firewatir and Watir, then maybe delete CHANGES from Firewatir > > altogether and/or move it's contents to Watir's CHANGES? delete? > > 9) watir-rdoc.rb - why not have these in .gemspec again? delete? > > 10) watir_release.txt is necessary? delete? > > > > Again, no rake-task for just running Watir's tests? > > > > commonwatir, firewatir/watir have different license types... what > > about using the same license for all of these subprojects? > > > > If someone can give me answers to the proposals above then i could > > start making the changes and perform some pull requests on github. > > > > 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 > -- 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 Jul 8 13:50:31 2010 From: watirjira at gmail.com (christine cheng (JIRA)) Date: Thu, 8 Jul 2010 12:50:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Created: (WTR-447) Click does nothing when the link element is inside the nested frame Message-ID: <19869748.627.1278611431315.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Click does nothing when the link element is inside the nested frame ------------------------------------------------------------------- Key: WTR-447 URL: http://jira.openqa.org/browse/WTR-447 Project: Watir Issue Type: Bug Components: Frame Affects Versions: 1.6.5 Environment: operating system: XP watir-webdriver 0.02 watir 1.6.5 selenium-webdriver 0.0.24 Browser: Chrome 6.0 Reporter: christine cheng Priority: Blocker We are trying to find a tool that support web application automation test on googlechrome and safari, and just start investigating Watir. We experienced a blocker issue that some click are not working when running on Windows XP. The same code works fine on Linux. Here is the scenario: 1. Instruct my web app to the point where a link can be clicked, this page contains nested frames. 2. Call element_by_xpath to get the element, calling click() does nothing. I tried the same code against firefox using firewatir, no problem. The code snippet: require 'rubygems' require 'selenium-webdriver' require 'watir-webdriver' b = Watir::Browser.new(:chrome) test_site = "http:///index.html" b.goto test_site sleep 3 b.frame(:name, "TICKET").link(:text,"Login or Sign Up.").click If I output b.frame(:name, "TICKET").link(:text,"Login or Sign Up.").href, it returns correct value. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Jul 8 14:39:31 2010 From: watirjira at gmail.com (Jari Bakken (JIRA)) Date: Thu, 8 Jul 2010 13:39:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-447) Click does nothing when the link element is inside the nested frame In-Reply-To: <19869748.627.1278611431315.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <19275765.629.1278614371104.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jari Bakken closed WTR-447. --------------------------- Resolution: Won't Fix Thanks for reporting! watir-webdriver is (still) a separate project, using its own tracker at: http://github.com/jarib/watir-webdriver/issues Could you reopen the issue there? It would also be helpful if you could provide the actual HTML (or a minimal version) needed to reproduce the problem. > Click does nothing when the link element is inside the nested frame > ------------------------------------------------------------------- > > Key: WTR-447 > URL: http://jira.openqa.org/browse/WTR-447 > Project: Watir > Issue Type: Bug > Components: Frame > Affects Versions: 1.6.5 > Environment: operating system: XP > watir-webdriver 0.02 > watir 1.6.5 > selenium-webdriver 0.0.24 > Browser: Chrome 6.0 > Reporter: christine cheng > Priority: Blocker > > We are trying to find a tool that support web application automation test on googlechrome and safari, and just start investigating Watir. We experienced a blocker issue that some click are not working when running on Windows XP. The same code works fine on Linux. Here is the scenario: > 1. Instruct my web app to the point where a link can be clicked, this page contains nested frames. > 2. Call element_by_xpath to get the element, calling click() does nothing. > I tried the same code against firefox using firewatir, no problem. > The code snippet: > require 'rubygems' > require 'selenium-webdriver' > require 'watir-webdriver' > b = Watir::Browser.new(:chrome) > test_site = "http:///index.html" > b.goto test_site > sleep 3 > b.frame(:name, "TICKET").link(:text,"Login or Sign Up.").click > If I output b.frame(:name, "TICKET").link(:text,"Login or Sign Up.").href, it returns correct value. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Jul 8 17:01:31 2010 From: watirjira at gmail.com (christine cheng (JIRA)) Date: Thu, 8 Jul 2010 16:01:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-447) Click does nothing when the link element is inside the nested frame In-Reply-To: <19869748.627.1278611431315.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <46019.631.1278622891628.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19701#action_19701 ] christine cheng commented on WTR-447: ------------------------------------- page source: .... .... > Click does nothing when the link element is inside the nested frame > ------------------------------------------------------------------- > > Key: WTR-447 > URL: http://jira.openqa.org/browse/WTR-447 > Project: Watir > Issue Type: Bug > Components: Frame > Affects Versions: 1.6.5 > Environment: operating system: XP > watir-webdriver 0.02 > watir 1.6.5 > selenium-webdriver 0.0.24 > Browser: Chrome 6.0 > Reporter: christine cheng > Priority: Blocker > > We are trying to find a tool that support web application automation test on googlechrome and safari, and just start investigating Watir. We experienced a blocker issue that some click are not working when running on Windows XP. The same code works fine on Linux. Here is the scenario: > 1. Instruct my web app to the point where a link can be clicked, this page contains nested frames. > 2. Call element_by_xpath to get the element, calling click() does nothing. > I tried the same code against firefox using firewatir, no problem. > The code snippet: > require 'rubygems' > require 'selenium-webdriver' > require 'watir-webdriver' > b = Watir::Browser.new(:chrome) > test_site = "http:///index.html" > b.goto test_site > sleep 3 > b.frame(:name, "TICKET").link(:text,"Login or Sign Up.").click > If I output b.frame(:name, "TICKET").link(:text,"Login or Sign Up.").href, it returns correct value. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Sat Jul 10 10:44:00 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Sat, 10 Jul 2010 16:44:00 +0200 Subject: [Wtr-development] =?utf-8?q?Watir_Podcast_=2335_=C5=BDeljko_Filip?= =?utf-8?q?in_on_Watir_Stack_Exchange_Site?= Message-ID: Felipe Knorr Kuhn and I talk about Watir Stack Exchange Site ( http://bit.ly/watirse): http://watirpodcast.com/35-zeljko-filipin-on-watir-stack-exchange-site/ If you have an hour, take a listen and find out why I think Stack Exchange is the best thing that could happen to Watir support. ?eljko -- watir.com - community manager watirpodcast.com - host testingpodcast.com - audio podcasts on software testing. all of them vidipodkast.com - pri?amo o hardveru, softveru i ?asopisu Vidi -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Tue Jul 13 12:13:31 2010 From: watirjira at gmail.com (Bret Pettichord (JIRA)) Date: Tue, 13 Jul 2010 11:13:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Resolved: (WTR-103) implement IE#element and IE#elements Message-ID: <13894863.37.1279037611029.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret Pettichord resolved WTR-103. --------------------------------- Resolution: Fixed Fix Version/s: (was: Soon) Next Merged implementation by Hugh McGowan into master. > implement IE#element and IE#elements > ------------------------------------ > > Key: WTR-103 > URL: http://jira.openqa.org/browse/WTR-103 > Project: Watir > Issue Type: New Feature > Components: HTML Controls > Reporter: Bret Pettichord > Priority: Major > Fix For: Next > > > Instead of specifying the tag you are looking for, you will only specify an attribute of that tag. > Example: > instead of > ie.link(:id, "id").click > you could click the same link with > ie.element(:id, "id").click > Usable when you know an attribute of a tag, but do not know the tag type. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Jul 19 06:53:30 2010 From: watirjira at gmail.com (Jeugene (JIRA)) Date: Mon, 19 Jul 2010 05:53:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Created: (WTR-448) Firewatir Frame usage cause firewatir reattach to frame window Message-ID: <2353324.83.1279536810754.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Firewatir Frame usage cause firewatir reattach to frame window -------------------------------------------------------------- Key: WTR-448 URL: http://jira.openqa.org/browse/WTR-448 Project: Watir Issue Type: Bug Components: FireWatir Affects Versions: 1.6.5 Environment: Win Xp pro sp2, Ruby 1.8.7 Reporter: Jeugene Priority: Major Attachments: firewatir.jpg After attaching firefox window any action on frame cause firewatir reattach to frame window instead f main window. example in attachment. action result : ***.page8.cfm?request_id=******* expected result : ***.main.cfm -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Jul 27 07:56:14 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 27 Jul 2010 13:56:14 +0200 Subject: [Wtr-development] [wtr-general] Re: Check out the Watir Stack Exchange site! In-Reply-To: <2562285e-50ee-4405-a865-6c692640b0a2@k39g2000yqb.googlegroups.com> References: <97e8febe-77d9-4eb7-a85a-5793525d1490@i28g2000yqa.googlegroups.com> <3c9112da-81fd-4560-9725-091d248f9fc1@w15g2000pro.googlegroups.com> <2562285e-50ee-4405-a865-6c692640b0a2@k39g2000yqb.googlegroups.com> Message-ID: I was away for a few weeks snorkeling and brewing, but I see Watir community was busy. :) Our Stack Exchange site [1] just got 60th follower! (Thanks to our old friend MarekJ.) But why did not it move from "define" to "commit" phase?! (Like Selenium site [2] did some time ago?) The answer is in the top right hand corner of the front page: "This proposal is in: Definition. The topic and audience are still being decided. It needs 0 followers, 5 on-topic questions, 5 off-topic questions to move to the next phase." We have 35 example questions, but for a question to count as on- or off-topic, it has to have at least 20 votes (if I got it right by looking other sites). What do you have to do? - go to http://bit.ly/watirse - take a look at the questions (35 of them, it would take you a few minutes) - vote if questions are on- or off-topic (you have 5 votes, so again just a few minutes) If you have the time, you can submit more questions (again up to 5). Thanks a lot to all of you who have contributed to the site. I think it is the best thing that could happen to Watir support. If you want more information, you can listen to a podcast [3] where Felipe and I talk about the site in detail for about an hour. ?eljko -- [1] http://bit.ly/watirse [2] http://area51.stackexchange.com/proposals/4693/selenium [3] http://watirpodcast.com/35-zeljko-filipin-on-watir-stack-exchange-site/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Wed Jul 28 04:46:57 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 28 Jul 2010 10:46:57 +0200 Subject: [Wtr-development] watir.com/installation comments Message-ID: Installation page at watir.com is one of the most visited and commented: http://watir.com/installation/ I have noticed that people are asking for support there (3 comments are pending moderation at the moment, all 3 asking for support). Since comments are moderated, I do not approve such comments. I send e-mail to the author pointing them to watir.com/support page. Today I have took a look at existing comments and found one that is support question. I have deleted it, just to make it clear that we do not provide support via comments. Please let me know if you disagree. ?eljko -- watir.com - community manager watirpodcast.com - host testingpodcast.com - audio podcasts on software testing. all of them vidipodkast.com - pri?amo o hardveru, softveru i ?asopisu Vidi -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Wed Jul 28 07:34:16 2010 From: alister.scott at gmail.com (Alister Scott) Date: Wed, 28 Jul 2010 21:34:16 +1000 Subject: [Wtr-development] watir.com/installation comments In-Reply-To: References: Message-ID: I agree! Thanks. I might update the site to let people know not to ask questions, else disable commenting on certain pages? 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 Wed, Jul 28, 2010 at 6:46 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > Installation page at watir.com is one of the most visited and commented: > > http://watir.com/installation/ > > I have noticed that people are asking for support there (3 comments are > pending moderation at the moment, all 3 asking for support). Since comments > are moderated, I do not approve such comments. I send e-mail to the author > pointing them to watir.com/support page. > > Today I have took a look at existing comments and found one that is support > question. I have deleted it, just to make it clear that we do not provide > support via comments. > > Please let me know if you disagree. > > ?eljko > -- > watir.com - community manager > watirpodcast.com - host > testingpodcast.com - audio podcasts on software testing. all of them > vidipodkast.com - pri?amo o hardveru, softveru i ?asopisu Vidi > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Wed Jul 28 07:37:42 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 28 Jul 2010 13:37:42 +0200 Subject: [Wtr-development] [wtr-general] Re: watir.com/installation comments In-Reply-To: References: Message-ID: 2010/7/28 Alister Scott > I might update the site to let people know not to ask questions, else disable commenting on certain pages? I would leave comments on all pages, but moderated. Feel free to update the site, but I am not sure how to make it clear where to ask questions. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Wed Jul 28 16:56:30 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 28 Jul 2010 15:56:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Resolved: (WTR-443) Watir::IE#close doesn't close the browser if #wait throws an exception In-Reply-To: <27975824.402.1276377151050.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <18882067.171.1280350590696.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarmo Pertman resolved WTR-443. ------------------------------- Resolution: Fixed Fix Version/s: Next Fixed in master http://github.com/bret/watir/commit/d02804ba5680d2d022b109d91c208b5e6569654a > Watir::IE#close doesn't close the browser if #wait throws an exception > ---------------------------------------------------------------------- > > Key: WTR-443 > URL: http://jira.openqa.org/browse/WTR-443 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.5 > Environment: All environments > Reporter: Jarmo Pertman > Fix For: Next > > > Watir::IE#close should close the browser even if #wait throws an exception - for > example caused by a #run_error_checks > Fix is available at http://github.com/jarmo/watir/commit/70c9b4a705cf91ebe47725a7aed9d77f4013e1ff with tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Jul 28 16:56:30 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 28 Jul 2010 15:56:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-443) Watir::IE#close doesn't close the browser if #wait throws an exception In-Reply-To: <27975824.402.1276377151050.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <32240206.173.1280350590884.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarmo Pertman closed WTR-443. ----------------------------- Assignee: Jarmo Pertman > Watir::IE#close doesn't close the browser if #wait throws an exception > ---------------------------------------------------------------------- > > Key: WTR-443 > URL: http://jira.openqa.org/browse/WTR-443 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.5 > Environment: All environments > Reporter: Jarmo Pertman > Assignee: Jarmo Pertman > Fix For: Next > > > Watir::IE#close should close the browser even if #wait throws an exception - for > example caused by a #run_error_checks > Fix is available at http://github.com/jarmo/watir/commit/70c9b4a705cf91ebe47725a7aed9d77f4013e1ff with tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Jul 28 16:58:30 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 28 Jul 2010 15:58:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-444) Watir::Element#style returns only inline style In-Reply-To: <3441033.404.1276377450444.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <1383198.175.1280350710534.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarmo Pertman closed WTR-444. ----------------------------- Assignee: Jarmo Pertman Resolution: Fixed Fix Version/s: Next Fixed in master http://github.com/bret/watir/commit/ebf38031c92c800ca0b0897706d10d9c4240a4a7 > Watir::Element#style returns only inline style > ---------------------------------------------- > > Key: WTR-444 > URL: http://jira.openqa.org/browse/WTR-444 > Project: Watir > Issue Type: Bug > Components: HTML Controls > Affects Versions: 1.6.5 > Environment: All environments. > Reporter: Jarmo Pertman > Assignee: Jarmo Pertman > Fix For: Next > > > Currently Watir::Element#style returns only the style associated with the element inline thus: >
> would work: > browser.div(:index => 1).style.width > But when CSS is defined in HTML or CSS file, then this method would return empty string. CurrentStyle should be used instead of Style. > You can read more about it from: > http://msdn.microsoft.com/en-us/library/ms535231(VS.85).aspx > Get the fix from http://github.com/jarmo/watir/commit/15c420eb43f8b37946e2dbbcbc92f0eefa72c53e with tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Jul 28 17:00:30 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 28 Jul 2010 16:00:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Closed: (WTR-445) Watir::Table#to_a doesn't return TH elements and inner tables. Also Watir::TableRow#to_a is missing In-Reply-To: <15912535.406.1276377870527.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <16569234.177.1280350830551.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarmo Pertman closed WTR-445. ----------------------------- Assignee: Jarmo Pertman Resolution: Fixed Fix Version/s: Next Fixed in master http://github.com/bret/watir/commit/4f8d2b94cdf096ecb190f309b04f66ad979095dd > Watir::Table#to_a doesn't return TH elements and inner tables. Also Watir::TableRow#to_a is missing > --------------------------------------------------------------------------------------------------- > > Key: WTR-445 > URL: http://jira.openqa.org/browse/WTR-445 > Project: Watir > Issue Type: Bug > Components: Table > Affects Versions: 1.6.5 > Environment: All environments. > Reporter: Jarmo Pertman > Assignee: Jarmo Pertman > Fix For: Next > > > Currently, Watir::Table#to_a doesn't return texts from TH elements. > Also, inner tables are ignored and Watir::TableRow#to_a method doesn't exist although it would be logical to exist. > I've made a solution where Table#to_a uses recursively TableRow#to_a method, thus keeping code DRY. Also optional parameter *max_depth* got introduced for #to_a, which is by default 1, thus inner tables are not returned by #to_a. It is possible to specify higher value for *max_depth* to return inner tables. > In short, this change would do the following changes: > 1) TH elements' texts will be returned instead of an empty string when using #to_a > 2) Watir::TableRow will get also #to_a method > 3) Multi-dimensional arrays will be returned if max_depth parameter is higher than 1 and inner tables exist. > It is possible to get the changes and tests from http://github.com/jarmo/watir/commit/ec63460f3e594ae5b0430c857beaccb45990ef61 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Jul 28 17:02:30 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 28 Jul 2010 16:02:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-446) Watir::IE#wait doesn't finish at certain circumstances In-Reply-To: <20485293.408.1276378110448.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <30937862.179.1280350950540.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19728#action_19728 ] Jarmo Pertman commented on WTR-446: ----------------------------------- Charley proposed that this change should be tested by wider audience. I have been using this change at my work for almost a half of year now and haven't yet caught any problems. What would be the next steps to get this fixed, because this is a serious bug in my opinion due to blocking all tests? > Watir::IE#wait doesn't finish at certain circumstances > ------------------------------------------------------ > > Key: WTR-446 > URL: http://jira.openqa.org/browse/WTR-446 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.5 > Environment: All environments. > Reporter: Jarmo Pertman > > Watir::IE#wait method won't finish if: > 1) Go to some page with the browser - readystate will be READYSTATE_COMPLETE (4) > 1) Open file save as dialog from the browser > 2) Either save the file or close the dialog > 3) For some reason readystate is READYSTATE_INTERACTIVE (3) > Now, if you want to do something with Watir, which issues Watir::IE#wait, then it will block forever. > My suggestion would be to also allow READYSTATE_INTERACTIVE. > Get the fix from http://github.com/jarmo/watir/commit/7df8932946462f9284c63ca045b4fefe76a222d6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Jul 28 17:04:30 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 28 Jul 2010 16:04:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (WTR-446) Watir::IE#wait doesn't finish at certain circumstances In-Reply-To: <20485293.408.1276378110448.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <22036536.181.1280351070567.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarmo Pertman updated WTR-446: ------------------------------ Priority: Major (was: Minor) > Watir::IE#wait doesn't finish at certain circumstances > ------------------------------------------------------ > > Key: WTR-446 > URL: http://jira.openqa.org/browse/WTR-446 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.5 > Environment: All environments. > Reporter: Jarmo Pertman > Priority: Major > > Watir::IE#wait method won't finish if: > 1) Go to some page with the browser - readystate will be READYSTATE_COMPLETE (4) > 1) Open file save as dialog from the browser > 2) Either save the file or close the dialog > 3) For some reason readystate is READYSTATE_INTERACTIVE (3) > Now, if you want to do something with Watir, which issues Watir::IE#wait, then it will block forever. > My suggestion would be to also allow READYSTATE_INTERACTIVE. > Get the fix from http://github.com/jarmo/watir/commit/7df8932946462f9284c63ca045b4fefe76a222d6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Jul 28 17:53:31 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 28 Jul 2010 16:53:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Created: (WTR-449) making Element#click_no_wait faster and easier debuggable Message-ID: <16766026.183.1280354011131.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> 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 'watir/core';" << "#{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 - 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 modest laptop)! I call this as a quite big improvement if we think about all the Web 2.0 websites where #click_no_wait is often used. 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 debuggable, just use this monkey-patch: {noformat} Watir::PageContainer.class_eval {def spawned_click_no_wait_command(command) "ruby -e #{command.inspect}" end} {noformat} Maybe make it even more easier by using $DEBUG and if-statement or something similar? 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 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Jul 28 17:55:30 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Wed, 28 Jul 2010 16:55:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Updated: (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: <29375081.185.1280354130589.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarmo Pertman updated WTR-449: ------------------------------ Description: 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 'watir/core';" << "#{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 - 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 modest laptop)! I call this as a quite big improvement if we think about all the Web 2.0 websites where #click_no_wait is often used. 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 debuggable, just use this monkey-patch: {noformat} Watir::PageContainer.class_eval {def spawned_click_no_wait_command(command) "ruby -e #{command.inspect}" end} {noformat} Maybe make it even more easier by using $DEBUG and if-statement or something similar? 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 within commits: http://github.com/jarmo/watir/commit/7333081e30568ec73eb63f9f75562c2078c55481 http://github.com/jarmo/watir/commit/c71cee1ac820493372d299b8f3a258b497b22e66 was: 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 'watir/core';" << "#{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 - 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 modest laptop)! I call this as a quite big improvement if we think about all the Web 2.0 websites where #click_no_wait is often used. 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 debuggable, just use this monkey-patch: {noformat} Watir::PageContainer.class_eval {def spawned_click_no_wait_command(command) "ruby -e #{command.inspect}" end} {noformat} Maybe make it even more easier by using $DEBUG and if-statement or something similar? 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 added urls for fix commits > 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 'watir/core';" << > "#{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 - 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 modest laptop)! > I call this as a quite big improvement if we think about all the Web 2.0 websites where #click_no_wait is often used. > 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 debuggable, just use this monkey-patch: > {noformat} > Watir::PageContainer.class_eval {def spawned_click_no_wait_command(command) "ruby -e #{command.inspect}" end} > {noformat} > Maybe make it even more easier by using $DEBUG and if-statement or something similar? > 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 within commits: > http://github.com/jarmo/watir/commit/7333081e30568ec73eb63f9f75562c2078c55481 > http://github.com/jarmo/watir/commit/c71cee1ac820493372d299b8f3a258b497b22e66 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Jul 29 05:09:33 2010 From: watirjira at gmail.com (Jarmo Pertman (JIRA)) Date: Thu, 29 Jul 2010 04:09:33 -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: <27505526.188.1280394573562.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19730#action_19730 ] Jarmo Pertman commented on WTR-449: ----------------------------------- I forgot to add a comment to the benchmark test that this test was more of a less ideal scenario. In the real world you would probably have loaded tons of other libraries as well in your tests like maybe ActiveRecord and ActiveSupport and so on. What this currently means is that current implementation of #click_no_wait also loads these libraries (!!!) - method _code_that_copies_readonly_array is to blame. But these libraries are never-ever-never-ever needed when performing #click_no_wait. I couldn't think of any case where any external file or library might be needed for #click_no_wait. I guess the reason being that there isn't any case (prove if i'm wrong). Only case when something like this might be needed would be a situation where #click_no_wait itself is monkey-patched - but then again the method for spawning the process might be also monkey-patched so no problems there also. So, if you have ActiveRecord or ActiveSupport loaded and you perform #click_no_wait you'll lose another ~2 seconds: irb(main):001:0> t = Time.now; require 'activerecord'; puts Time.now - t 2.039117 irb(main):001:0> t = Time.now; require 'active_support'; puts Time.now - t 2.122121 Now add it up for every #click_no_wait and you'll understand how much time is lost for absolutely nothing :) > 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 'watir/core';" << > "#{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 - 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 modest laptop)! > I call this as a quite big improvement if we think about all the Web 2.0 websites where #click_no_wait is often used. > 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 debuggable, just use this monkey-patch: > {noformat} > Watir::PageContainer.class_eval {def spawned_click_no_wait_command(command) "ruby -e #{command.inspect}" end} > {noformat} > Maybe make it even more easier by using $DEBUG and if-statement or something similar? > 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 within commits: > http://github.com/jarmo/watir/commit/7333081e30568ec73eb63f9f75562c2078c55481 > http://github.com/jarmo/watir/commit/c71cee1ac820493372d299b8f3a258b497b22e66 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Jul 29 22:44:31 2010 From: watirjira at gmail.com (ethen.hu (JIRA)) Date: Thu, 29 Jul 2010 21:44:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Created: (WTR-450) Computer will be crashed when ie start Message-ID: <7741395.195.1280457871247.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Computer will be crashed when ie start -------------------------------------- Key: WTR-450 URL: http://jira.openqa.org/browse/WTR-450 Project: Watir Issue Type: Bug Components: Wait Affects Versions: 1.6.5 Environment: MS win xp professional service pack2 Reporter: ethen.hu Fix For: 1.6.5 This is my process to show issue when run watir 1, First Ie6 exist, run watir to create ie instance, ie6 window will be created 2, But When I update IE6 to IE7, and run watir to create IE instance, In theory, IE7 will be created, Actually, The IE6 window has been created. Now I have update ie6 to ie7, IE6 is not exist; well, watir will create ie6 window which doesn't work one by one, more than 50 Now , I found a function named 'window' in ie-process.rb, the condition for return is "process_id == @process_id", Maybe this is the reason for issue I think. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Jul 29 22:48:30 2010 From: watirjira at gmail.com (ethen.hu (JIRA)) Date: Thu, 29 Jul 2010 21:48:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-450) Computer will be crashed when ie start In-Reply-To: <7741395.195.1280457871247.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <28205816.197.1280458110629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19731#action_19731 ] ethen.hu commented on WTR-450: ------------------------------ Sorry, the Priority is Major > Computer will be crashed when ie start > -------------------------------------- > > Key: WTR-450 > URL: http://jira.openqa.org/browse/WTR-450 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.5 > Environment: MS win xp professional service pack2 > Reporter: ethen.hu > Fix For: 1.6.5 > > > This is my process to show issue when run watir > 1, First Ie6 exist, run watir to create ie instance, ie6 window will be created > 2, But When I update IE6 to IE7, and run watir to create IE instance, In theory, IE7 will be created, Actually, The IE6 window has been created. Now I have update ie6 to ie7, IE6 is not exist; well, watir will > create ie6 window which doesn't work one by one, more than 50 > Now , I found a function named 'window' in ie-process.rb, the condition for return is > "process_id == @process_id", Maybe this is the reason for issue I think. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From basim at baassiri.ca Fri Jul 30 08:45:45 2010 From: basim at baassiri.ca (Basim Baassiri) Date: Fri, 30 Jul 2010 08:45:45 -0400 Subject: [Wtr-development] [JIRA] Commented: (WTR-450) Computer will be crashed when ie start In-Reply-To: <28205816.197.1280458110629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> References: <7741395.195.1280457871247.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> <28205816.197.1280458110629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: I don't think this is a bug and Microsoft is about to end of life Windows XP SP2 On Thu, Jul 29, 2010 at 10:48 PM, ethen.hu (JIRA) wrote: > > [ > http://jira.openqa.org/browse/WTR-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19731#action_19731] > > ethen.hu commented on WTR-450: > ------------------------------ > > Sorry, the Priority is Major > > > Computer will be crashed when ie start > > -------------------------------------- > > > > Key: WTR-450 > > URL: http://jira.openqa.org/browse/WTR-450 > > Project: Watir > > Issue Type: Bug > > Components: Wait > > Affects Versions: 1.6.5 > > Environment: MS win xp professional service pack2 > > Reporter: ethen.hu > > Fix For: 1.6.5 > > > > > > This is my process to show issue when run watir > > 1, First Ie6 exist, run watir to create ie instance, ie6 window will be > created > > 2, But When I update IE6 to IE7, and run watir to create IE instance, In > theory, IE7 will be created, Actually, The IE6 window has been created. Now > I have update ie6 to ie7, IE6 is not exist; well, watir will > > create ie6 window which doesn't work one by one, more than 50 > > Now , I found a function named 'window' in ie-process.rb, the condition > for return is > > "process_id == @process_id", Maybe this is the reason for issue I think. > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Fri Jul 30 09:05:45 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Fri, 30 Jul 2010 15:05:45 +0200 Subject: [Wtr-development] [JIRA] Commented: (WTR-450) Computer will be crashed when ie start In-Reply-To: References: <7741395.195.1280457871247.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> <28205816.197.1280458110629.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: On Fri, Jul 30, 2010 at 2:45 PM, Basim Baassiri wrote: > I don't think this is a bug and Microsoft is about to end of life Windows XP SP2 Please comment on the ticket directly: http://jira.openqa.org/browse/WTR-450 ?eljko -- watir.com - community manager watirpodcast.com - host testingpodcast.com - audio podcasts on software testing. all of them vidipodkast.com - pri?amo o hardveru, softveru i ?asopisu Vidi -------------- next part -------------- An HTML attachment was scrubbed... URL: From watirjira at gmail.com Fri Jul 30 09:08:30 2010 From: watirjira at gmail.com (Zeljko (JIRA)) Date: Fri, 30 Jul 2010 08:08:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-450) Computer will be crashed when ie start In-Reply-To: <7741395.195.1280457871247.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <30852758.200.1280495310693.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19732#action_19732 ] Zeljko commented on WTR-450: ---------------------------- I do not understand the problem. IE6 opens when you upgrade to IE7? > Computer will be crashed when ie start > -------------------------------------- > > Key: WTR-450 > URL: http://jira.openqa.org/browse/WTR-450 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.5 > Environment: MS win xp professional service pack2 > Reporter: ethen.hu > Fix For: 1.6.5 > > > This is my process to show issue when run watir > 1, First Ie6 exist, run watir to create ie instance, ie6 window will be created > 2, But When I update IE6 to IE7, and run watir to create IE instance, In theory, IE7 will be created, Actually, The IE6 window has been created. Now I have update ie6 to ie7, IE6 is not exist; well, watir will > create ie6 window which doesn't work one by one, more than 50 > Now , I found a function named 'window' in ie-process.rb, the condition for return is > "process_id == @process_id", Maybe this is the reason for issue I think. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Jul 30 10:11:31 2010 From: watirjira at gmail.com (Basim (JIRA)) Date: Fri, 30 Jul 2010 09:11:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-450) Computer will be crashed when ie start In-Reply-To: <7741395.195.1280457871247.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <19217791.203.1280499091053.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19733#action_19733 ] Basim commented on WTR-450: --------------------------- I recommend that you upgrade to Service Pack 3 as "Support for Windows XP Service Pack 2 ended on July 13, 2010. " and see if this problem is reproducible Source: http://www.microsoft.com/windows/windows-xp/default.aspx > Computer will be crashed when ie start > -------------------------------------- > > Key: WTR-450 > URL: http://jira.openqa.org/browse/WTR-450 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.5 > Environment: MS win xp professional service pack2 > Reporter: ethen.hu > Fix For: 1.6.5 > > > This is my process to show issue when run watir > 1, First Ie6 exist, run watir to create ie instance, ie6 window will be created > 2, But When I update IE6 to IE7, and run watir to create IE instance, In theory, IE7 will be created, Actually, The IE6 window has been created. Now I have update ie6 to ie7, IE6 is not exist; well, watir will > create ie6 window which doesn't work one by one, more than 50 > Now , I found a function named 'window' in ie-process.rb, the condition for return is > "process_id == @process_id", Maybe this is the reason for issue I think. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Jul 31 23:10:31 2010 From: watirjira at gmail.com (ethen.hu (JIRA)) Date: Sat, 31 Jul 2010 22:10:31 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-450) Computer will be crashed when ie start In-Reply-To: <7741395.195.1280457871247.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <11136286.207.1280632231162.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19734#action_19734 ] ethen.hu commented on WTR-450: ------------------------------ Thx, But is it the pack's problem? To Zeljko: Yes, after I upgrade ie6 to ie7, but watir still open ie6 window. > Computer will be crashed when ie start > -------------------------------------- > > Key: WTR-450 > URL: http://jira.openqa.org/browse/WTR-450 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.5 > Environment: MS win xp professional service pack2 > Reporter: ethen.hu > Fix For: 1.6.5 > > > This is my process to show issue when run watir > 1, First Ie6 exist, run watir to create ie instance, ie6 window will be created > 2, But When I update IE6 to IE7, and run watir to create IE instance, In theory, IE7 will be created, Actually, The IE6 window has been created. Now I have update ie6 to ie7, IE6 is not exist; well, watir will > create ie6 window which doesn't work one by one, more than 50 > Now , I found a function named 'window' in ie-process.rb, the condition for return is > "process_id == @process_id", Maybe this is the reason for issue I think. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 Jul 31 23:29:30 2010 From: watirjira at gmail.com (ethen.hu (JIRA)) Date: Sat, 31 Jul 2010 22:29:30 -0500 (CDT) Subject: [Wtr-development] [JIRA] Commented: (WTR-450) Computer will be crashed when ie start In-Reply-To: <7741395.195.1280457871247.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> Message-ID: <21812968.209.1280633370540.JavaMail.oqa-j2ee@openqa01.managed.contegix.com> [ http://jira.openqa.org/browse/WTR-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19735#action_19735 ] ethen.hu commented on WTR-450: ------------------------------ I was puzzled by the code as this: def window Waiter.wait_until do IE.each do | ie | window = ie.ie hwnd = ie.hwnd process_id = Process.process_id_from_hwnd hwnd return window if process_id == @process_id end end end This is defined in ie-process.rb, as described on jira, If I upgrade ie6 to ie7, So @process_id is for IE7, but acctully process_id is for ie6, not equal, the window can't be returned always, maybe add a timeout for this I think; > Computer will be crashed when ie start > -------------------------------------- > > Key: WTR-450 > URL: http://jira.openqa.org/browse/WTR-450 > Project: Watir > Issue Type: Bug > Components: Wait > Affects Versions: 1.6.5 > Environment: MS win xp professional service pack2 > Reporter: ethen.hu > Fix For: 1.6.5 > > > This is my process to show issue when run watir > 1, First Ie6 exist, run watir to create ie instance, ie6 window will be created > 2, But When I update IE6 to IE7, and run watir to create IE instance, In theory, IE7 will be created, Actually, The IE6 window has been created. Now I have update ie6 to ie7, IE6 is not exist; well, watir will > create ie6 window which doesn't work one by one, more than 50 > Now , I found a function named 'window' in ie-process.rb, the condition for return is > "process_id == @process_id", Maybe this is the reason for issue I think. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.openqa.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira