I was about to open a defect against 3.3.12.0, but decided for completeness to retest using the beta and sure enough my symptoms have gone away. Now I'm trying to find why, and none of the issues listed in the bug tracker seem likely. So I'm really looking for some reassurance that this was fixed and not something I'm going to see as a regression in the future.
I distilled the relevant bits of code down to the following reproduction.
Windows XP/IE 8/AutoIt 3.3.12.0 - seems fine.
Windows 8.1/IE 11/AutoIt 3.3.12.0 - _IEFrameGetObjByName fails ~0.5% of the time.
Windows 8.1/IE 11/AutoIt Beta 3.3.13.19 - seems fine.
AutoItSetOption("MustDeclareVars", 1) #include <IE.au3> Local $o_IE = _IEAttach("_IE_Example", "title") If Not IsObj($o_IE) Then $o_IE = _IE_Example("frameset") EndIf Local $oFrameMain = _IEFrameGetObjByName($o_IE, "Main") If IsObj($oFrameMain) Then ConsoleWrite("Object" & @CRLF) Else ConsoleWrite("Not an object" & @CRLF) EndIf
Line 701 (File "c:\Program Files (x86)\AutoIt3\Include\IE.au3"):
If $oFrames.length Then
If $oFrames& ERROR
Error: Variable must be of type "Object".
In my real app after generous attempts at recovery all of which fail (it acts like the IFrame is missing, but it's clearly there) the final recovery is to "clone" the current request by launching AutoIt with the current script, with the current parameters, and return the child return code. Presumably this simply pushes the failure rate from 0.5% down to 0.0025% (in fact it's recursive with no limit, so for that one in 40,000 failure it will just retry deeper and deeper clones until RunWait() fails).
I'm at a loss as to how AutoIt can _IEAttach() fine in every case, but when failing no amount of retrying _IEAttach, _IELoadWait, _IEFrameGetObjByName, added delays, etc. within that process can make that IFrame accessible, yet launching AutoIt again in a new process generally works. Yet the beta has mysteriously changed this for the better.