Truly a WTF-class bug in IE6Dec 10, 2007
I recently came across a truly bizarre bug in IE6 which seems to indicate, as absurd as it sounds, that client-side interactive behaviour somehow depends on the type of your internet connection.
The bug concerns URIs containing hash elements, also called fragment identifiers, or anchor links. The following is such a link: http://en.wikipedia.org/wiki/Hyperlink#Inline_link
In this case, the #Inline_link is the fragment identifier which, on page load, causes the client to scroll to an <a> element with name="Inline_link". Now this is all fine and dandy, and works properly in Opera, Firefox, and IE7. Supposedly it works in IE6 too, but...
If your connection is directly to the internet, IE6 handles these links just fine. However, if you are using any type of proxy server, IE6 will refuse to scroll to the named anchor on page load. Oddly enough, if you then click a link on that page which contains a fragment identifier, and it leads to another element within the same page, then IE6 will scroll to it normally. The bug only happens when the page is loaded or re-loaded using a URI ending with a fragment identifier.
I initially thought this bug was due to the OS (first found on Win 2000, and since found on XP), but then thought it was due to my test page using the id attribute of elements as targets rather than the old-style <a name="...">, but Wikipedia uses these old-style anchors and IE6 still shows the bug there.
This is when serendipity struck. I needed to reproduce the bug, so I borrowed a laptop with XP and IE6 on it which we had confirmed manifested the bug. I connected to the wireless network (a non-proxy connection) and suddenly the bug was gone. So we took the laptop back, hooked it into the wired network using the proxy server and lo, the bug reappeared!
Same computer, same browser, same instance (we hadn't even closed the browser between connections), just different proxy settings. It is definitely strange to have such a benign behaviour hinge upon the type of internet connection you are using, but I guess those are the breaks when you have to deal with IE.
Anyway, while trying to fix this infernal beast, I could find quite literally no documents online documenting bugs which matched this one. Hopefully, by posting this, I solve this hellish enigma for a few poor souls at least