An ActiveX IE plugin vendor is claiming, and it certainly seems to be the case in my tests, that an ActiveX’s <object /> tag is being transformed funny by jQuery rather than if it were not dynamically inserted.
plugin = $('<object ... >... </object>').get(0);
$('#pluginPlaceholder').append(plugin);
The result of dynamically adding the control is that the plugin DOES load, and some of the functionality works, but other parts do not work (no crash, just no response). (Though I believe that the specifics of the no-reaction vs crash vs something else is just how they implemented whatever is handling the error that it is encountering internally.)
To work around it, I must not use jQuery in the creation of the item, not even $('#pluginPlaceholder').html('<object id='obj' ... >... </object>'); plugin = document.getElementById('obj');
But if jQuery doesn’t touch it, it works correctly:
document.getElementById('pluginPlaceholder').innerHTML = '<object id='obj' ... >... </object>';
plugin = document.getElementById('obj'); // $('#obj').get(0); seems to be valid too
What might jQuery do to the tag to affect it in any way?
This sounds very similar to a problem we run into with FireBreath plugins in IE. What happens is that when jquery constructs the object tag it builds the tag in memory before putting it into the pluginPlaceholder element. The problem with this is that it actually instantiates the activex control there before putting it into the DOM.
When IE is told to put the activex control inside the DOM element, it calls InPlaceDeactivate on the ActiveX control before moving it, then places it inside the new element, and then calls InPlaceActivate. Many ActiveX controls aren’t expecting this and there are sometimes certain things lost (such as event handlers from the page) when that happens.
The solution to the problem is to not set the CLSID or TYPE of the object tag until after you have appended it to the new location.