Problems With Internet Explorer

1222103804|%e %B %Y

TAGS: dev ie microsoft sucks wikidot

Do you ever wondered how much time Wikidot team spends on working on fixing things to let them work in Internet Explorer? A LOT!

Internet Explorer is hardly following any standard.
Microsoft claims to have right to produce their proprietary standards.
They don't even publish them, so working with Microsoft application is just like magic — the bad one.
They don't supply with any tool for Internet Explorer that would uncover the strange things that happen.

A few examples:

Cross-domain cookies problem

(This "feature" caused custom domains and private wiki files to not function properly in IE).

It seemed that cookies are not sent with a request, when requesting an image or script from other domain than the master page. The same happened when requesting a HTML file from other domain within an iframe.

Then, we discovered, that actually some of cookies are sent. But what the hell happens, that the WIKIDOT_SESSION_ID cookie is not sent? "It's the SESSION in the name of cookie — Michał said — we've done a little experiment and the name of cookie seemed NOT to be a problem. So, it is something else that stops Explorer from sending cookies.

As we cannot easily see what cookies IE sends (Oh dear! No tool like Firebug for IE), we had to create server-side scripts, that printed out the cookie table. As some of situation we analyzed were JavaScript related (the browser requests JavaScript code), we had to write also a server-side script that alerts the cookie table with JavaScript. That was frustrating as hell.

OK. Now we knew exactly what cookies were sent to server and which weren't. But why? Here's where Firebug and Webdeveloper Toolbar for Firefox comes. I printed the cookie table in Firefox and noticed that the cookies that are sent were cookies with no explicit expiration time — i.e. deleted when the browser quits. The cookies that were not sent had some expiration time set.

Without tools for Firefox this would not be so easy to determine what's the difference that makes some of cookies unusable.

NOTE: some of you may wonder if there is any point in not sending some cookies when issuing cross-domain requests. After hours of analysis — we don't see any. And The Rest Of Browsers send all the cookies.

Cross-domain cookies issue continued

Wonder if it's possible for Internet Explorer to set a cookie from an iframe with different domain?

Content-type ignoring

Internet Explorer ignores Content-type, which is completely non-standard and not the case of ANY OTHER browser.

Background

Suppose we know a file is a PNG image, or GIF. This is why we send the Content-type HTTP header before the content of some file requested by browser.

Content-type is also known as a MIME type. Examples: MIME type of HTML files is text/html, PNG images: image/png.

Internet Explorer Behavior

Internet Explorer, once downloaded a file, do a so-called "content sniffing" and decides by itself what's the type of a file. This means it can badly detect a file type and display HTML as a text or vice-versa.

Content-sniffing and JavaScript

It is possible to attach HTML files to Wikidot
uploaded file can be iframed within any Wikidot page
HTML can contain JavaScript
JavaScript is run and has the access to any properties and cookies of pages that runs the same domain as the JavaScript itself

How to disable this

We just set the Content-type header to text/plain for HTML files, and this makes browsers display the HTML as the source, so JavaScript is displayed and not run.

This is just the case I mentioned: "we know, this file is text file (we want it to be treated like text file), so we send the hint on this".

Unfortunately IE knows better (by ignoring Content-type and doing content-sniffing) and allows JavaScript to be run, fetch the session cookie and to export this to external service. This allows the external service to use your session — i.e. use Wikidot AS YOU.

The only way we know to disable this for even for IE

Move ALL USER-UPLOADED files to other domain. Then JavaScript has limited access to the original domain and can't grab cookies.

Why do we need to move ALL files? Actually we need to move only files that IE detects as HTML, but how to hell know it? IE is closed source and the mechanism itself is never published. We hate you Microsoft!

Tricky CSS

Internet Explorer completely sucks when it comes to CSS support. Even the shiny IE7 is a complete mess. I had to completely rewrite the CSS of the Green Fresh theme because IE6 and IE7 didn't display the search box at all. No need to say every other browser I tested displayed it.

UPDATE: Expires header

Expires and Cache-control HTTP headers are used to control the cache behavior of browser. It lets us decide if a page should be refreshed every time accessed or can be cached for some time to speed up things.

We use Expires headers for example for user-uploaded files. We allow caching them for 2 hours or so. But unfortunately Internet Explorer caches badly PDF (and possibly other) files. So when we allow it to cache it and user accesses it second time, the file is taken from IE cache and displayed as a total mess or not displayed at all!

Because of this BUG we disabled Expires header for IE for user-uploaded files including custom theme images and stylesheets. This leads to IE fetching the files that never changes again and again.

I'm pretty sure Wikidot is not the only service to disable Expires header for IE. That's one of reasons why browsing the Internet with IE is slower than with Firefox for example.

Summary

The popularity of Internet Explorer makes web developers spent extra time on making sure the service works "even on IE". Normally, once you get thing working in Firefox, it's not a big deal to make it work on:

Safari
Opera
Konqueror
Google Chrome
Epiphany
Galeon
Camino
any browser based on Gecko or WebKit (also KHTML) engine

Wonder why? Because they all follow W3C standards.

The Internet Explorer is the only one popular browser left that does not follow standards.

SHAME ON YOU MICROSOFT!

UPDATE: The Solution?

There are plugins for Internet Explorer. Someone could make a plugin that renders on the full page size and uses Gecko (the engine of Firefox) to display a page.

Technically — this would mean even Internet Explorer users use Firefox engine, so from this point you could support only standard-implementing engines. For the IE user — it would require them to install an IE plugin to use your service properly.

Previous post: Ekipa Wikidota: "Będziemy na Barcampie"

Next post: Lewoo Lewooooo