Re: [Wtr-general] need a frame-recursive wait
On Jul 29, 2006, at 11:58 PM, Xavier Noria wrote: On Jul 28, 2006, at 7:30 PM, Bret Pettichord wrote: On 7/28/06, Xavier Noria [EMAIL PROTECTED] wrote: I'm gonna patch the method tomorrow to write some stack-based recursion. But before I do that I'd like to ask whether someone else already fixed this, or else if there is any technical reason that prevents that method from being recursive-like. Your solution sounds reasonable. Please submit a patch when you have it. Great, here it is. I think it is fair to say this contribution was paid by ASPgems, we have a few projects based on Watir and are very grateful to you guys for maintaining it. -- fxn ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] need a frame-recursive wait
On Jul 28, 2006, at 7:30 PM, Bret Pettichord wrote: On 7/28/06, Xavier Noria [EMAIL PROTECTED] wrote: I'm gonna patch the method tomorrow to write some stack-based recursion. But before I do that I'd like to ask whether someone else already fixed this, or else if there is any technical reason that prevents that method from being recursive-like. Your solution sounds reasonable. Please submit a patch when you have it. Great, here it is. I factored wait() out into wait_for_ie() and wait_for_document(). The patch is against 1.4.1, which is the one we are using. In addition to the stack-based recursion through frames I planned to add, I removed an unusued @pageHasReloaded flag, and added a do/while loop in wait_for_ie() because another reason why the program was crashing was that after the usual while busy + until readyState == complete the @ie object was again in a busy state! Argh! I have seen the do/while in wait_for_ie() sometimes executes more than once in that website with frames, for sure. That do/while loop is not a correct solution to the re-busy state. In principle it could happen that whatever puts @ie back in busy state may need a bit more to be triggered than those 0.02 seconds of sleep. But at least my program runs like a charm in my trials, and approach that problem properly I'd need to know more about those IE states than what I've found in the docs. In particular it's relationship with frames, DOM scripting, Ajax calls... Smells like an asynchronous thing to hook into if there's API for that. I am sure there's room for improvement there. -- fxn adds_robustness_to_watir.patch Description: Binary data ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
[Wtr-general] need a frame-recursive wait
A crawler that always works flawlessly in development regularly raises UnknownObjectException other computers. The same navigation done by hand via irb on those machines works. The website we are crawling has some frames, and the main frame contains yet another frameset so we have two levels. While reading watir.rb I noticed Watir::IE#wait does consider frames, but just one level of them. So my working assumption is that some inner frame is not completely loaded when the bot tries to access some element there. The PCs where it runs OK are slower than the PCs where it crashes. I don't know how that fits in the explanation (if it does), but it is a pattern. I'm gonna patch the method tomorrow to write some stack-based recursion. But before I do that I'd like to ask whether someone else already fixed this, or else if there is any technical reason that prevents that method from being recursive-like. -- fxn ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
