markus’ blog

Adobe PDF Reader 6 plugin and IE 6 problem

Today we had to track a pretty nasty problem where PDF, served via a PHP script, wouldn’t display properly in some Internet Explorer browsers (worked fine in others). The PDFs content didn’t show up at all, even the plugin was not properly started (no toolbar, etc.), the page just remained white, blank, empty.
The prerequisites:

• Adobe Reader plugin 6.0.0 19.05.2003
• Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
• A PHP script serving a PDF from database

After some testing with IE, Firefox, wget and Fiddler the differences were finally found:

• We only sent the Content-Type header, not the Content-Length
• The actual PHP script serving the PDF was masked as .html with mod_rewrite

Once we made the script name as .php visible to the browser and added the appropriate header, all problems were solved.

Add comment May 3rd, 2006

IE – Having fun with JS and links

Today IE gave me another fun with its neverending behaviour. So what kind of acrobatic thing did I do today? I simply tried to change the href on a link. Bad, bad idea.

For some reasons I wanted to have the HTML code of a link look like this:

<a
	href="http://www.real.link/"
	onclick="this.href='http://some.other.url/'"
	target="_blank">
	www.real.link
</a>

So the expected behaviour in a Javascript enabled browser would be:

1. Internally change the real href of the link
2. Open a new page with the URL from the onclick-handler

What does IE do?

1. Internally change the real href of the link
2. Change the content of the link to the new URL (under certain conditions)
3. Open a new page with the URL from the onclick-handler

Don’t believe? See yourself (needs IE browser, if course). This link has onclick="this.href='http://but.it.goes.here/'":
www.real.link

The not-so-expected behaviour of this is that the link after the change looks like this:
http://but.it.goes.here/

Detailed analysis

As it seems, when the content of the link starts with www.something (no other tags between) it will automatically replace this the content of the link also when the href attribute is changed in Javascript, even though they do not match.

Testcases

All testcases have the onclick-handler from above and the target set to _blank and their real href set to http://www.real.link/ if not noted otherwise.

Testcases which change the content of the link:

• www.real.link (href: http://the.real.link/)
• www.real.link
• www.real
• www.a
• www.secondpart nothing more neede

Testcases which don’t change the content of the link:

• the.real.link (href: http://the.real.link/)
• real.link

Workaround

Put some dummy tags inside the content of the link to prevent the replacement, like <span>:

<a
	href="http://www.real.link/"
	onclick="this.href='http://some.other.url/'"
	target="_blank">
	<span>www.real.link</span>
</a>

So, what’s left at the end of the day?

Thanks, M$, for another wasted hour of my live.

2 comments October 17th, 2005

M$ IEBlog-Team asks for “Please check your pages”

The IE developer team now discovered, after it fixed some if it’s nasy CSS bugs, that quite some pages will start to break if IE is put into Standards mode and you’re using CSS Hacks to work around the current < = IE 6 bugs.

So what’ you’re take on it? Help or dismiss the news?

I for myself don’t have much time and even haven’t access to their current IE7 beta (it has only been released to a small audience). One of the comments in the blog sums it up for me (but not that harsh):

I have wasted a lot of time finding workarounds for your standard-ignorant browser. I had to make a lot of design tradeoffs because your unability to e.g. render PNG properly.

Honestly, I do not care about the issues you got now. I won’t remove a single workaround for your buggy stuff again. You messed it up, now it’s also your turn to find a solution for it.

Microsoft never paid my time I’ve wasted to get the pages in their browser right. Right, my company did, but M$ browser was responsible for increasing the time to work and the countless hours of pain without free proper tools to find the problems (I don’t consider the ScriptDebugger proper, compare it to Venkman. It’s not only about functionality but also how it integrations).

Another good one:

First you’re building cars with triangular tires, and people had to build roads with holes on it, and now you’re complaining your new car with round tires can not drive on these roads.

1 comment October 13th, 2005

PeekABoo, again!

This is bug is really nothing new. Still it’s so damn annoying when you build your interfaces and have to waste your time with fixing IEs damn bugs. Compare the screenshots yourself.

1. Everything is fine …
2. … until you hover over the link, fortunately …
3. … the fix is easy: use position: realtive on the red box

Still, the margin gets screwed up, even with the workaround. Anyway, thanks Microsoft.

Add comment November 18th, 2004