Bret Pettichord wrote: > On 5/24/06, *David Schmidt* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > This is the same problem that was occurring in wait(). The COM object > document method is called when the document method isn't available. > I've seen this if a page or frame immediately kicks off a new page > load > before all the wait checks are complete or perhaps if the check is > called before the page/frame is completely ready. > > > The reason for my concern is that this error is in > check_for_http_error. This method isn't called until after all the > wait checks are complete and Watir thinks that the page is already > fully loaded. So that means that there is a bug in the core wait code. Not necessarily. I have pages in my web scraper that load and then immediately run code to load a *different* page, just like a redirect. Yes, this is ugly and not great web design, but it is being done. If Watir is still checking return codes on the first page while IE starts the process to load the NEXT page then the COM document method may not be valid when we're still trying to check the results of the first page load. > > > Fix would similar to the one in wait where you make sure a document is > available: > > (from IE#wait) > until suppress_ole_error [EMAIL PROTECTED] do > sleep 0.02; s.spin > end > > > The problem with this is that it would only suppress the symptom > without addressing the cause, and the same problem could just as > easily arise somewhere else. Do we wrap guards around every call in > Watir to @ ie.document and every other COM call we ever make? That > would only make errors nearly impossible to diagnose. Do we need to > add more wait checks to the core wait logic? Why haven't we seen the > problem before? I suspect that this isn't a common occurrence, which is why it hasn't shown up frequently in the past. In addition, wasn't the code to check the status of loaded frames added only recently? That could cause this to show up more frequently if the base page or a previous frame triggers a new page load.
I don't see what we can do but abort the checks and perhaps start checking all pages (base IE and frames) again, because we can't continue checking "old" pages if they're no longer there. This is why I recommended placing the frames.each inside the begin/rescue block for WIN32OLE errors in IE#wait, because we may have a different number of frames if a new page load is triggered while Watir is in IE#wait. Since calls to check_for_http_error would normally only occur when we're expecting a new page then I think we should just let the WIN32OLE exception filter to up the method calling check_for_http_error and then make sure those spots handle the exception as appropriate. In IE#wait I would propose we assume that we are seeing a new page load and re-start the entire wait, re-checking the base IE document and all the sub-frames. > This is the reason for my puzzlement. If there is really a flaw in the > wait logic i suspect we'll be seeing problems elsewhere. Is this a new > problem cause by the recent rearrangement of the wait code that i > thought would have no impact? Is this a problem that was previously > masked by other bugs and is only now showing up because we've added > guards to other places (where they reasonably belong)? Have i missed > something serious in my analysis of this area? > > We don't really have unit tests for this code, and it has always made > me the most nervous. These problems all show up as race conditions. > And yet the ability of Watir to have reliable synchronization has been > absolutely key to its success. So we have to get this right. I'm not sure there is a way to determine for sure if the page has been reloaded or not. The title and url may not change, and the COM object doesn't change either. We can restart the error checks and make sure any NEW page has completed successfully, but we just may not be able to detect a new page load while we're checking the status of the first page. > Bret BTW, since there can be framesets within an existing frame the code in IE#wait should really check each found frame to see if there are additional frames being loaded from within that frame. I have some sites where I see 3 levels of frames (@ie.frame(x,x).frame(x,x).frame(x,x).element). David _______________________________________________ Wtr-general mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-general
