views:

77

answers:

2

I've been debugging a curious issue with file paths in an instance of IE embedded in my application.

I have the following JavaScript/jQuery:

<script type="text/javascript">
function foobar(src) {
  $("img").attr("src", src);
}
</script>

And my DOM contains a single img tag:

<img src="loading.jpg" />

I have the following three links which call foobar when activated:

<a href="javascript:foobar('file:///C:/nospaces/someimage.bmp');">without spaces</a>
<a href="javascript:foobar('file:///C:/path spaces/someotherimage.bmp');">with spaces</a>
<a href="javascript:foobar('file:///C:/path%20spaces/someotherimage.bmp');">with spaces</a>

All of those links work great in IE/FF/Chrome, but only the first link works in my application where I'm using an embedded instance of IE.

If I right-click the image after clicking the second link (one of the two that doesn't work, the third one gives the exact same results), I can see the image URL is this:

file://C:\path%20spaces\someotherimage.bmp

which doesn't load if I paste that address into Start->Run.

Changing the address to add a third / after file:, like this:

file:///C:\path%20spaces\someotherimage.bmp

allows Start->Run to open the image.

Interestingly, non-embedded IE retains all 3 slashes (file:///), so all three links work.

Has anyone come across this sort of issue? Any ideas how to fix it?

A: 

For the sake of testing perhaps try:

foobar('file:///C:/path+spaces/someotherimage.bmp');
Fini
Thanks, but I've tried that one too with no luck!
Dominic Rodger
+1  A: 

Turns out it was due to the HTML being specified one URI Scheme (a proprietary one), and the images being specified in another (the File URI Scheme).

Changing them both to use file:/// fixed the problem.

That said, I still have no idea why paths without spaces worked, whilst path with spaces didn't. If anyone has any idea why (preferably with an authoritative source if there is one) - feel free to post it as an answer and I'll give you the accept.

Dominic Rodger
Hrm... IE is weird. If your proprietary scheme was implemented as a pluggable handler, then I suppose it may have had a bug in its implementation of the routine such handlers provide to resolve relative URLs; otherwise, I suspect the system routine had the same.
Shog9