IE11: Fullscreen inside iframe, video will seek to end when clicking on trackbar (seeking forward)

[leray]

IE11: Fullscreen inside iframe, video will seek to end when clicking on trackbar (seeking forward)

How to reproduce:

1. Put a video inside an iframe ( http://storage.eu.ee/testground/videojs/ )
2. Play video and enter fullscreen
3. trying to seek forward

FF, Chrome will change the current position
IE11 will seek to the end and stop the video

[mmcc]

Does this also happen with a vanilla video element?

[mmcc]

@leray ping. Any chance you've been able to test this with a vanilla video element?

[leray]

untouched video element works fine

http://storage.eu.ee/testground/videojs/test2.html

[heff]

I can confirm this is happening. (thanks for the reduced test case!)

It looks like there's something off with the percent calculation. If you click at the very beginning of the progress bar the play head will go to zero, but then if you start to drag to the right the playhead will move drastically faster than your mouse.

@leray Any chance you can help us dig in to this? It will likely start somewhere in the Slider. Especially since it appears the volume slider isn't working either.
https://github.com/videojs/video.js/blob/master/src/js/slider.js#L129

[leray]

@heff Method calculateDistance() logic itself is correct, this is the browser bug .

1. Fullscreen element inside iframe returns invalid offsetWidth in IE11 (as reported and confirmed here).

2. https://github.com/videojs/video.js/blob/master/src/js/slider.js#L134

   el.offsetWidth (or directly document.msFullscreenElement.offsetWidth) returns invalid width ("19" for reso 1920, "13" for 1366, the number is cropped off)

3. As a workaround, we can detect a bogus behavior (element is inside an iframe + check if offsetWidth is smaller than clientWidth) and calculate the correct width with getBoundingClientRect()

   if (window.self !== window.top && el.offsetWidth < el.clientWidth){
     boxW = boxH = Math.round(el.getBoundingClientRect().width * 100);
   } else {
     boxW = boxH = el.offsetWidth; //1: player box width
   }

The problem is that IE11 getBoundingClientRect() is also bogus inside an iframe, it returns values divided by 100. We can get the correct width by multiplying the value by 100, but if MS fixes the getBoundingClientRect() and forgets to fix offsetWidth, then this workaround won't work

Edits by @mmcc - Added some Markdown to help readability

[mmcc]

@leray That's a great writeup, thank you for the explanation. I agree that this is a bit of a scary one to try and work around because any one of these issues could be fixed at any time (in any order), which makes this one pretty awkward.

One option would be to build a plugin to account for this behavior...That would allow us to quickly update things without patches if things change as far as IE11 is concerned and wouldn't affect general users (I imagine this is affecting a relatively small number of folks). Thoughts?

[leray]

it may take years to get it fixed, so waiting for MS to solve the problem is not an option.

As alternative to writing a plugin, is to ensure that both offsetWidth and getBoundingClientRect() return incorrect values, in this case a temporary hack will help to calculate the correct width, and if these conditions are not met, we will simply use the default way to get the width.

it definitely won't do worse, but will return the correct width if certain conditions are met

if (window.self !== window.top && el.offsetWidth < el.clientWidth 
     && el.getBoundingClientRect().width < 100) {
  // IE 11 fix: inside an iframe + invalid offsetWidth + invalid getBoundingClientRect()
  boxW = boxH = Math.round(el.getBoundingClientRect().width * 100);
} else {
  //default
  boxW = boxH = el.offsetWidth;
}

[mmcc]

I agree, it's definitely not reasonable to just wait around for MS to solve this.

I can't think of a reason why that workaround would break anything else, but it feels a little hacky (although I guess that's par for the course considering what we're trying to fix). Want to put together a PR for this to get the ball rolling?

[mgol]

IE11 is not developed anymore and the bug is fixed in Edge. It seems checking "msFullscreenElement" in document should be enough to catch the "rogue" browser.

[darcnite3000]

I'd like to add that i think there is a related issue in here that the volume control doesn't work in this situation either. (fullscreen from iframe)

[forbesjo]

I can’t reproduce the issue on 11.0.9600.18762, perhaps this has been surprisingly fixed? Anyone else still seeing this?

I definitely see the problem on 11.0.9600.17420.

[banyan]

I see this problem on 11.0.9600.17280. I can't see on 11.0.9600.18860 anymore.

[gkatsev]

Given that this is a browser bug and it's fixed in a newer build of IE11, I'm going to close this issue.