Internet Explorer 9 occasionally failing when video URLs do NOT contain scheme and domain

[Jpsy]

We had occasional reports of users not being able to watch videos on IE9 while most visitors had no problems at all. The affected users COULD in fact view the demo video on www.videojs.com without any problems. Only a small fraction of our users were affected by that problem and even those reported that playback occasionally worked for them (in about 20% of their trials).
After a long rally of ghost hunting and debugging we finally found the one difference that made it work for all users:
Video URLs have to contain the scheme and URL (as the videos on www.videojs.com do, e.g. src="http://vjs.zencdn.net/v/oceans.mp4"). Our URLs were starting with a slash to address local files (e.g. src="/videos/myvideo.mp4").
Why this does disturb IE9 on some machines and does work on others is beyond my grasp. I could never reproduce it on our development machines, but witnessed it with great stability on some user machines. The affected browsers were all IE9.0.8112.16421 on Win 7 32, but I would not count on the fact that these are the only affected versions. The problem seems to be connected with limited bandwidth and lengthy round trip times, so it could be some timing or syncing problem, which would explain why even the affected users can sometimes play the videos. But I have no idea why the problem is (reliably!) solved by adding scheme and host to the video URLs.
The Video.js versions that we tested with were 4.1.0 and 4.2.1, hosted on our own servers. preload parameter of <video> tag was set to "auto". autoplay was NOT active.
The symptoms of the problem are: Spinner is visible on the video right after opening the page in IE. Spinner does not rotate and does not vanish. Play button does either not appear or does not react to clicks.
It could be possible that this issue is related to #628 .

[heff]

Thanks for the detailed issue and for digging into it. Flash has always had issues with relative URLs, but we've fixed that in most cases, and in this case IE9 should be using HTML5 video. So very strange.

I'm able to reproduce this locally using a windows VM and a local phpserver, however the reason it's breaking for me is the local server is sending the wrong MIME type for the file. The content type should be video/mp4 and it's sending application/octet-stream.

When you add the full URL does it change where the file is served from, or can you tell if the headers are changing at all?

[heff]

Let me know if you have any more information on this. Closing the issue for now.

[Jpsy]

Hi heff,
I had posted an answer to your questions but do not find that answer here now. Strange. So let me repeat:
The full URLs and the relative URLs were addressing identical targets in all my use cases. So basically the missing scheme and host of the relative URLs were those of the web page's URL where the video was located.
Unfortunately I cannot give you any information about the headers as the problem is solved now (by adding scheme+host to all URLs).
Wouldn't it be a solution, to check the URLs in your JS code and add scheme+host from the URL of the surrounding website if they are missing in the Videojs parameters?

[heff]

That could be a solution. I'm cautious to do URL manipulation for everything because it has the potential to introduce other issues, but if that's what really fixes IE9 then I guess that's what we need to do.

Have you found any other mentions of this issue, with IE9 and HTML5? It'd be nice to have a little more confirmation that we're fixing the right thing.

Also, any idea if this is an issue in IE10?

[gkatsev]

And we could always do it on IE9 only.

[heff]

Yeah. @Jpsy, if you want to make a pull request for this that'd help. I think you can just use the getAbsoluteURL function.
https://github.com/videojs/video.js/blob/v4.4.2/src/js/lib.js#L646

[Jpsy]

Damn, I wish I could reproduce that problem locally.
So far it happend only on remote PCs spread all over the world in my customer's network.
We had issues with multiple machines, all running IE9, but could never find out why some were affected and others worked just fine.
Unfortunately I am not familiar with Github processes - so I have no idea of how to make a pull request.

[heff]

@Jpsy, I'm working on something to hopefully make that easier, that I might ask you to try out if you're up for it. Are you also not familiar with Git itself?

[Jpsy]

Yes @heff, no contact with Git.
Drop me a note, if you want me to test your code.

[heff]

Ok great, will do. It'll be a little bit though as I'm going out of town. Stay tuned. :)

[mmcc]

If these global browser stats are to be trusted, IE9 usage is < IE8 (and somewhere below 2.22% of global users). While I agree that we should try and fix this, code specific to this browser seems to me to be overkill.

@Jpsy regarding reproducing locally, any chance something like lvh.me would help you reproduce? It simply points back to your local machine, which can be useful for debugging things like this.

[mmcc]

Given the age of this, the tiny usage of IE9, and the fact that we've been unable to reproduce locally, I'm going to close this. If we can get a reduced test case ping this issue so we can reopen.