As stated in the bug, this problem was caused by some performance improvement patches I submitted a while back. I don't normally use Regexp matches in my :id or :name elements so I didn't see this problem in my working code.
There are actually two different problems in place here. First of all, IE doesn't understand regular expressions, so I've added code to make sure we only pass strings into getElementById() and getElementsByName(). That will stop the crashes caused by the regular expressions. The other problem is the one that causes the test case failure listed in WTR-77. That is caused by the fact that IE's getElementById() not only matches on :id, it will also matches on the first matching :name. I now double check the element returned by getElementById() to make sure that it really HAS a matching :id, else we fall back to the slow method. Lastly, not every element supports the fast get calls, but we can't use #respond_to? because these are OLE methods, not Ruby methods. Thus, the "fast" code is wrapped in a begin/rescue block so any element not supporting the get method will drop down to the slower code. All core tests now pass, including some new tests using regular expressions in :id and :name searches. David Schmidt Charley Baker wrote: > Actually I can tell you why this is happening, it's related to the > issue I was looking at yesterday, ie.element(:id, 'foo') actually > searches by Name: http://jira.openqa.org/browse/WTR-77 > > Both are failing in the locate_input_element method. In the case of > the Jira issue mentioned above > getElementById() isn't working as it should be. In the case of regular > expressions, it's simply sending the regular expression into > getElementById or getElementsByName, straight ole_methods which causes > problems for ie. We don't currently seem to have any regex searches on > the input elements I've been looking at which is why they don't show > up, regexs do work for non input elements which uses a different > locator. Once we figure out how to handle this I'll add more unit tests. > > This is also related to the other issue you mentioned: > WIN32OLERuntimeError: Unknown property or method `scrollIntoView' > HRESULT error code:0x80010004 > The caller is dispatching an asynchronous call and cannot make > an outgoing > call on behalf of this call. > > Somehow after the call gets screwed up there seems to be a hung > connection to ie or something so that further calls to connect to > other elements can cause this error. I've gotten it as well. > > As a temporary hack you can open watir.rb, go to the > locate_input_element method, delete the whole begin/rescue/end block > at the beginning and replace it with > elements = ole_inner_elements > > -Charley _______________________________________________ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
