We are working on using a 3rd party’s ActiveX control within a web page. Our page includes JavaScript to access and manipulate the control. Part of the control’s functionality requires it to access files on the local filesystem.
If we generate the page programmatically, this functionality fails – the ActiveX control appears unable to access the filesystem. If we take the generated page source, copy it into a static file, and serve that file from the same web server, everything works as expected – the ActiveX control gets the info it needs from the filesystem, and we go merrily on our way.
I have used a JavaScript debugger to walk through the two different pages, and verified that the calls to the ActiveX control have identical parameters. I have verified that both the static page and the dynamic page are listed in the “Local Intranet Zone” in IE so they should have the same security constraints.
I have used SysInternals’ ProcessMonitor to see what the ActiveX control is doing in the system, and what differs. Interestingly, when the calls to the control succeed, there are ProcessMonitor traces showing where the control is querying the registry for filenames, and accessing the filesystem. When the process fails, it’s not the case that there are failures accessing the filesystem, but rather, the control never queries the registry to find the filename, and never tries to hit the filesystem.
The vendor of this control is mystified, and I’ve run out of ideas of what to try. Is there something that I ought to be checking? Some difference between dynamically-generated pages and static pages that IE or an ActiveX control might be able to detect, that would cause behaviors to change? The URI is different, the static page has a “.html” extension…. There’s not much else that’s different, as far as I can tell.
Any ideas would be welcome….
We figured out what was wrong, and effectively uncovered a bug in the 3rd party’s ActiveX control.
They have a feature where they can optionally validate the URL of the page on which the control is loaded, or they can configure the control with a wildcard that is supposed to match any URL. The vendor had worked with us and configured the control with the wildcard, and assured us that this could not be the problem.
When we replaced the wildcard URL in the control’s configuration with our actual URL, the control started working. As far as we can tell, we were fighting all day yesterday against a bug in the control’s wildcard handling.