.width() in fullscreen mode in iframe is too large in IE 11

[heporap]

.width() is incorrect value in fullscreen mode of iframe.

I got 12800 on IE11. IE Edge is OK.

<iframe src="iframe.html" allowFullscreen webkitAllowFullscreen></iframe>

iframe.html, html

<div id="fs" style="width:100%;height:100px;background-color:green;color:black;">
    <p><input type="button" value="fullscreen" id="run"></p>
    <p><input type="button" value="test" id="test"></p>
    <p id="output"></p>
</div>

iframe.html, javascript

jQuery(function($){
    $('#test').click(function(){
        $('#output').text( $('#fs').width() );
    });
    $('#run').click(function(){
        pageEnterFullScreen( $('#fs')[0] );
    });

});

function pageEnterFullScreen(element){

    if( element.requestFullscreen ){
        element.requestFullscreen();

    }else if( element.msRequestFullscreen ) {
        element.msRequestFullscreen();

    }else if(element.mozRequestFullScreen ){
        element.mozRequestFullScreen();

    }else if(element.webkitRequestFullscreen ){
        element.webkitRequestFullscreen();

    }

}

[mgol]

Could you create a test case on jsfiddle.net or jsbin.com? Also, I assume you mean it works fine in Edge and not the edge mode of IE? (There's no such thing as IE Edge)

[heporap]

I could not create iframe page with allowfullscreen attribute on jsfiddle.net. I made a sample in github pages instead.
http://heporap.github.io/testcase/iframe_fullscreen.html

IE 11 of Windows 8 outputs 128000, and IE Edge of Windows 10 outputs 1920.

[dmethvin]

Ref gh-1764 and its PR gh-2401. There is no feature check (it would be pretty much impossible I think) so we're just blindly multiplying by 100 if we see fullscreen mode. Maybe IE11 fixed this?

[mgol]

I fired up the test case at /test/integration/gh-1764-fullscreen.html and it now fails (click the second button to see) in IE 11 on Windows 10 which means the bug was fixed in IE 11. I don't know if it was fixed in Windows 8.1 & Windows 7 variants of IE 11 (at least in BrowserStack they still have the bug) but it was definitely fixed in Windows 10.

@jacobrossi you said in #2401 (comment) that you're not going to fix this bug and purely based on that comment we landed the workaround... Why was it fixed contrary to that declaration? :(

[mgol]

I've added this to the 1.12.4/2.2.4 milestone so that we don't lose it. If Microsoft did fix it and the fix is going to stay we should just revert our "fix" and let people deal with it themselves.

I'd still like someone from the IE/Edge team to give more light here. @jacobrossi, @jdalton, could you help us here?

[jdalton]

Yep, I'll poke around. By poke around I mean ping Jacob :P

[jacobrossi]

I'm seeing IE11 on Windows 10 behave incorrectly and Microsoft Edge on Windows 10 behaving correctly. So to me it looks like we only fixed this in Edge.

(My screen is a 3000px display with a 2x DPI, so 1500 is the right value here)

[mgol]

@jacobrossi The issue was that IE was setting values 100 times too small so we started to multiply them by 100 if in fullscreen mode in iframes (the code is here). So the fact that you see values 100 times too large in IE means that IE got fixed and our workaround is now broken (this test case uses jQuery 2.2.2 which includes the workaround).

[mgol]

The test case from our repo can be viewed via rawgit.com. If you click the second link in IE 11 you'll see the red background which means our workaround now breaks IE instead of fixing it.

[jacobrossi]

Got it. OK and you can confirm that IE11 on Windows 7 works differently?

[mgol]

I don't have a VM with current Windows 7 & IE 11, the BrowserStack version still has the bug but it might not be 100% up to date.

[jacobrossi]

Ok, I'll spin up a patched VM and see.

[dmethvin]

For me it's giving the incorrect results (due to our patch) in IE11.212.10586.0 on Windows 10, which would indicate the bug was fixed at some point in IE11.

[mgol]

OK, thanks to Linked Clones in Parallels I could get the IE 11 on a Windows 7 machine running pretty quickly.

The bug existed (as expected) in IE 11.0.9600.17843 but it no longer exists in 11.0.9600.18282 which is the latest version for Windows 7.

@jacobrossi Could you check why it was fixed despite earlier claims? If the fix is going to stay, we'll need to revert the workaround. That would also mean asking BrowserStack to update their IE 11 copies so that we test on IEs behaving consistently.

[mgol]

@jacobrossi Since this seems to be fixed in Windows 7 & Windows 10 versions of IE 11, we're going to assume it's most likely fixed in Windows 8.1 as well and we'll revert our hacky workaround.

We'd still love to hear a confirmation that it was fixed and why it happened so if you could share that, that'd be great.

[mgol]

The fix landed on master (ff1a082), 2.2-stable (fb9adb9) & 1.12-stable (fb9adb9).

[yuhong]

Do anyone know exactly which IE11 cumulative update fixed the problem?

[dmethvin]

We didn't get an answer from Microsoft on this so unfortunately, no. If you find out please post that information in the ticket.