Internet Explorer Bugs
Notes on/demos of major bugs in IE support for ActiveX controls
 

This page contains notes on and tests demonstrating some of the worst unfixed problems we have found with ActiveX control support in Internet Explorer.

These bugs seriously affect our customers and the functionality and usability of our SwiftView ActiveX product. Using our plugin in the Netscape/Mozilla/Firefox browser family exhibits none of these bugs and is recommended wherever possible.

Note - it's been several years some some of these bugs were reconfirmed; some may have finally been fixed by Microsoft.

Most of the major problems arise because IE repeatedly violates the following two rules in http data handling:

1. The URL returned to the ActiveX control MUST be the entire, original, unmodified, fulll-path URL that can be used to obtain the data, including the full query string and any #fragment. This is because the winINET api's must accept the URL in it's original form from a control to obtain the corresponding cached data - there is no other explicit API communication available to the control to download the data.

This means that a POST query fundamentally cannot work with the IE+ActiveX+wininet architecture, because unlike with GET, the POST URL does not contain the full query information. IE developers have repeatedly changed the behavior of IE+ActiveX with POST queries, without fixing anything.

Providing the original URL is also the only means to allow an Active-X control to download other support files from a web site - a capability fundamental to our control.

2. IE should always use the MIME type first when determining what application to run. If the MIME type is "unknown", or does not resolve to a registered ActiveX control, plugin, or executable program, then and only then is it OK for IE to intuit a content type from the suffix, or by examining the data.

Bug 1:

Various POST problems. 12/2/98 We have contacted Microsoft on the following problem. It's fairly serious, stopping many customers that are either choosing to switch to IE or forced to support IE in their customer base, and that really need to use POST rather than GET for security reasons. The worst part is, the problem is actually worse with SAX. This problem was reopened as Microsoft case #SRX001017606553 on 10/17/00.

Summary:

IE may fail to download the SwiftView-MIME-typed file returned for an HTML-based POST request. The probability of failure increases from near 0% to near 100% with file size in the plugin; it fails regardless of file size with SAX. Also, IE is requesting multiple transfers, slowing the process; this problem also occurs with GETs. Microsoft claims to have fixed this in IE 5.5 SP1, see Q254337, but experience leads us to believe that it will still happen in certain cases such as with a POST. The POST failure has been reproduced with Apache and Netscape servers, both http: and https:.

Before version 5.5, IE returned a cache filename as the URL, and sometimes the cache file doesn't exist. This also makes it impossible to obtain other files from the web site. IE 5.5 passes a valid URL to the control, but still does not work reliably.

some PCL files: URL is just the cgi script, control is loaded, can't load file.

tiff file: doesn't load control, IE file info reports that the URL is just the cgi script, type text/html.

4/6/00: After learning about the basis of this change in IE 5.5 from http://access.adobe.com/browser/iebugs.html (no longer available) and Q247663, we did testing with our newest SAX, version 5.2, that does all URL access in the control. It now works on some files, but not others, with no discernable pattern as to which files fail.

Note that the tiff file problem above was solved by renaming the cgi script to send_ics.pcl.cgi.

9/2001: IE 6.0 beta reverted to the pre-5.5 failure mode.

10/2001: IE 5.5/SV5.5/NT 4.0 exhibits yet different failure modes.

I've also seen 3 requests for large files with IE 4.0, http: or https:, plugin or ActiveX. The Adobe page above expounds on this problem.

Here is a demo of this problem. It uses this CGI script, which just returns whatever file name you fill in and hit return, with a SwiftView MIME type. Try tech/tests/generala.pcl or tech/tests/byer.tif, which usually work with IE 5.5 and SwiftView ActiveX 5.2, and tech/tests/univers.pcl or tech/tests/molecul1.pcl, which don't. When it fails, no parameters are passed to the cgi script! Previous versions of IE return an unopenable cache file, or fail in other obscure and sometimes intermittent ways.


File to display (GET)

This POST query once worked around all of the IE problems, by using this CGI script, which returns an HTML page that contains an EMBED that in turn fetches the actual file with a GET query. Try any of the files listed above. Lately, however, with IE 5.50.4134.0600 (no service pack) and SwiftView 5.5, it sometimes refuses to display anything, or behaves the same as the above test, which for this configuration is displaying only the first file accessed until the cache is cleared.


File to display (POST to HTML, then GET)

The only reliable workarounds to this bug:

- use GET

- Write the document to a temporary file on the web server, and return an HTML page with an EMBED with SRC=temporary_document_file.

- use Netscape/Mozilla/Firefox family browsers and the SwiftView plugin.

Bug 2:

IE does not consistently pass the conventional "#fragment" (anchor) syntax in a URL to an ActiveX control, as Netscape does to plugins. IE may strip the #fragment. It may fail to load ActiveX control at all - apparently the lack of a file suffix confuses it. (Microsoft IE problem report #SRX991013600855, October-December 1999)

example:

href="http://www.swiftview.com/tech/svrel.zhp#fragment test"

Netscape correctly ignores the #fragment part ("anchor"), passing the URL unchanged to the plugin so it can extract the #fragment part. SwiftView 5.0 uses the #fragment syntax to implement hrefs to positions in a document, following the usual conventions.

Bug 3:

Unless the URL for a full-page control ends in one of the suffixes registered by the Active X control, Internet Explorer may erratically fail to start the control (displaying a small red x icon), even though the MIME type matches the control's MIME type list. This bug has been reproduced with SAX with a CGI query:

http://www.swiftview.com/cgi_bin/spsrv?file=file.txt&suff=.pcl

works,

http://www.swiftview.com/cgi_bin/spsrv?file=file

often works,

http://www.swiftview.com/cgi_bin/spsrv?file=file.txt

does not.

Note that IE correctly reports the MIME type in the page properties dialog in all cases. In some cases, a suffix on the cgi script itself is enough to make the control run, but in at least one observed case the suffix on the cgi script was not enough, and appending "&suff=.pcl" fixed it.

New related problem, 4/18/08, in IE7/XP: EMBEDs with a src parameter with a .ics suffix erratically fails to start, displaying the "three objects" icon". Replacing .ics with .zhp fixes the problem. Adding the CLASSID does not help.

Rationale: In general, URL's do not always have a suffix. Even if they do, the suffix may have no correlation to the data (MIME) type returned, or the correlation may apply only on the server, not the client machine. Therefore, suffixes should NEVER be used to select an application except as a possible fallback if an application cannot be found for the MIME type. Further, it is very important that browser controls function without modifying the local machine's suffix mapping - there is no guarantee of consistent suffix treatment between the web server and the local machine, and there is no guarantee that the user wants to use the browser control rather than some other standalone application for local files. So the Active-X installer must not be required to register suffixes, only MIME types, to access Web server files.

It's very hard to explain to our customers that to work around this bug they must tack a suffix onto a query string.

Bug 3a:

Forms that generate a complex GET request returning data of a non-HTML MIME type fail to start the Active-X control.

An HTML page, let's call it H1, contains a form that is submitted to a CGI/Perl/PJP3 script (via an http GET request). The script, let's call it S1, generates Content-Type = "application/vnd.SwiftView-ICS" and sends a SwiftView ICS command file to the browser.

IE apparently calls S1 once to determine the content type then generates a dummy HTML page to embed SwiftView. If the SRC parameter contains more than one name=value pair, the HTML embed fails to start the ActiveX control (displaying a small red x icon). Adding a suffix=.pcl does not make it work. Limiting the query to one name=value pair works.

This manufactured HTML "wrapper" may well be related to the fact that IE is making multiple requests to the server (see bug #1).

Bug 4:

Document files of certain lengths, most reproducibly 8193-8840 bytes, inclusive, frequently crashes the ActiveX control in various IE 5.5 versions, on some NT and win2k systems, in the wininet InternetReadFile() call, sometimes in other calls. A customer has also reported the crash with IE 4.0 and 5.0 on NT. It has not been seen when accessing local files, and seems to be masked by having files in http cache. The contents of the file do not matter. The crash occurs in the call which would have returned the last block of the file.

If we disable almost all of the ActiveX control's functionality except the file download, it still crashes, although less often (presumably because the damaged memory is less likely to be used). If we reduce the downloaded data block size from 16384 to 1024, it crashes less often. If we further reduce it to 1 or two bytes at a time, it has never crashed. Because the crash is not repeatable on all systems, we will never be sure that there are not other file size ranges that cause crashes. And always reading two bytes at a time is unacceptable; with a production control, it turned a 2 second startup on a 131200 byte file into 6 seconds.

A file obtained with a Form GET query doesn't crash - unfortunate because that would make it easier to search for file sizes that cause the crash.

So in version 5.5 or later of SwiftView, we are using a gross adaptive scheme - read in 1K blocks, except 1 byte at a time for the blocks that have previously crashed on this system. Initially, the 8th block is assumed to crash.

Bug 5:

When one updates Win2000 via windowsupdate.microsoft.com, you'll get security "fixes" for IE as well as the core OS. The unfortunate side effect is that you'll frequently see the "Security Information" dialog even though the page contains ONLY SECURE items (we proved this is yet another Microsoft bug by clearing then reviewing both the secure and non-secure weblogs after viewing a document ... the non-secure log was empty!).

Note: This problem does not appear on WinXP after a windowsupdate. Don't know about the other OS's.

The Workaround:
One can turn off this annoying behavior via IE Options. Tools->Internet Options...
Security tab
Internet Custom Level button
Miscellaneous->Display mixed content->Enable

Bug 6: Disabled input to ActiveX controls        April 11, 2006

Microsoft released security update #912945 to Internet Explorer in March 2006. It prevents immediate input to an ActiveX control embedded in a web page.

After the 912945 update is installed, an extra click is required to operate any ActiveX control that is embeded in a web page. For example, before the 912945 update it was possible to arrive at a webpage with an embedded SwiftView document and immediately scroll down using the "page down" key. After the update, the user would need to click on the SwiftView window first, then page down or any other operation.

Please refer to this KB article:
http://support.microsoft.com/kb/912945/en-us

The Workaround:
Information on workarounds is available here:
http://msdn2.microsoft.com/en-us/library/ms537508.aspx



SwiftView®, SwiftConvert, SwiftStamp, SwiftExtract, SwiftReprint, SwiftPublish, and LoanDocs®, are trademarks of eLynx
SwiftView, a division of Black Knight Financial Services, 9205 SW Gemini Drive Beaverton, OR 97008 USA
800.720.0196 or +1.971.223.2600
  ©2017 Black Knight Financial Services.