Archives for posts with tag: ie

My last few days have been spent on a lovely security feature of Internet Explorer, which manifests as an ambiguous “SCRIPT5: Access is denied” message. After some digging, and with some lucky previous experience, I figured out how to get around this.


IE sees you take some jQuery (or plain javascript) and do something like $('input:file').click(); and starts to get suspicious. But on the FreshAiR Editor we did this with no nefarious intent; we needed to check some things before file selection and get ready to crop the user’s image once they selected one. When we later called $('form').submit(); everything would load into a same-domain iframe to be ready to send, and then… Access is denied.

Workaround time.

How to solve this? There are Adobe Flash and myriad other uploaders, but I remember implementing an open-source AJAX photo uploader-with-progress-bar in LunchTable a while ago, called qqFileUploader (now, it appears, called Fine Uploader). It was pure HTML/JavaScript/CSS, so I took a peek at how it was done, and came up with this result:

  • Using input buttons with this structure (optionally substituting “Upload Here” for an image):
<div class="button">
    Upload Here
    <input type="file" name="media" />
  • And styling the transparent file input on top of the text / image to make it clickable:
.button {
    position: relative;
    overflow: hidden;
.button input[type=file] {
    position: absolute;
    right: 0px;
    top: 0px;
    font-size: 118px;
    margin: 0px;
    padding: 0px;
    opacity: 0;
    z-index: 1; /* In case you use an img for input button */
/* For effect emphasis... */
.button:hover {
    background-color: blue;
    color: white;

You have a customizable, clickable file input that won’t upset Internet Explorer. See the full result on jsFiddle.

$ logout


I’ve made a lot of from-scratch websites in the years Chrome has been around (and before that, Firefox). In the old days—around IE 7 or so—I remember hoping to support old versions of Internet Explorer. I would test thoroughly and spend hours on workarounds for the archaic browsers. But not anymore.

With Chrome and Firefox on a quick update schedule, it’s obvious that they are doing web browsers right: quick iterations of browsers that keep up with the web that they provide the lens to. Not faux-modern browsers.

So I no longer address older browsers in the websites I create with anything more than a message telling users to upgrade. One site I’ve made, LunchTable, will simply let you know your browser is out of date before you can log in if you’re using IE (made easy through conditional statements), since only IE 9 has some CSS3 features I use, and IE 10 finally supports WebSockets for chat. Other browsers get a lazier approach that works well: feature detection. Before a user can chat, I check if WebSockets are supported— no need for me to research and test exhaustively, or update the tests when new browser versions come out.

The company I work for has a web editor that utilizes a ton of browser APIs (like FileReader) to create a seamless “editor” that works entirely on the client-side. While Opera happens to break for mysterious reasons and IE apparently doesn’t know every CSS2 or 3 selector, every other browser can check for the needed functionality and alert the user about certain functions that just won’t work with their current browser. This allows, for example, Safari 5.1 users to still log in and use most features of the application, but when they can’t upload images, we expect they won’t be surprised.

This approach puts more of a burden on the end user, which my old CS professor used to argue vehemently against (that the developer should be trimming input data and formatting it correctly, for example). But it is only the burden of keeping your software up to date— a responsibility of any computer user. And in the case of IE, this approach encourages users to exercise their freedom of choice in the web browser market. Truly, a win for everyone.