A while ago, I wrote about Internet Explorer security zones and dynamically created elements. Until such an element was attached to an existing document, all operations on that element were executed in the zone corresponding with
I ran into a similar situation while making changes to automatically activate an ActiveX control.
Because of the Eolas patent, which describes how a browser can use external applications, Microsoft is planning to release an update for Internet Explorer where users will need to click an ActiveX control before it becomes active. MSDN subscribers can already download a test release of this update.
... var obj = document.createElement('object'); obj.classid= "clsid:xxxxxxxx-xxxx-..."; ... container.appendChild(obj);
This worked magnifically: the control loaded and was activated immediately. One big problem however: the ActiveX control was unable to access the
IWebBrowser2 interface of the top level browser. The control accessed this interface as described in KB257717: How To Retrieve the Top-Level IWebBrowser2 Interface from an ActiveX Control, from the
OnSetClientSite method. The interface was then used to get the URL location and switch to/from full screen mode.
As I eventually found out, the reason for this malfunctioning had to do with object context. As long as the created object element has not been added to the document, there is no top level browser window. The
OnSetClientSite is called when setting the
classid, so it fails.
The solution, as in my previous post, is to add the element to the document tree as soon as possible, before filling out the
... var obj = document.createElement('object'); container.appendChild(obj); obj.classid= "clsid:xxxxxxxx-xxxx-..."; ...