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
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
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
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
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.
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.
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)
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
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:
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
It's very hard to explain to our customers that to work around this bug
they must tack a suffix onto a query string.
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).
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
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
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.
Bug 6: Disabled input to ActiveX controls
April 11, 2006
One can turn off this annoying behavior via IE Options.
Internet Custom Level button
Miscellaneous->Display mixed content->Enable
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:
Information on workarounds is available here: