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.
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?
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.
Bret
_______________________________________________ Wtr-general mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-general
