IE 11 fullscreen inside iframe needs workaround #1764
Comments
|
Comment author: dmethvin Can you add a link to the IE bug you've reported/found at https://connect.microsoft.com/IE/Feedback ? If they're addressing this with a slipstream patch there's no reason for us to attempt a fix. Also if you haven't found a reliable way to correct the numbers (couldn't tell from a quick read) there's nothing we'll be able to do. |
|
Comment author: christopher@… The IE bug I've reported is here: https://connect.microsoft.com/IE/feedback/details/838286/ie-11-incorrectly-reports-dom-element-sizes-in-fullscreen-mode-when-fullscreened-element-is-within-an-iframe When the error condition is detected (in this case, offsetWidth/Height < clientWidth/Height, which should never happen), the correct numbers are easily obtainted by calling Element.getBoundingClientRect() and multiplying the results by 100, and subtracting .right from .left or .bottom from .top. |
|
Comment author: dmethvin Can you post a link to a screen shot showing the problem still exists? Here is what I see on IE 11.0.9600.16659: http://i.imgur.com/VQLC9a0.png |
|
Comment author: anonymous You have to click the "Click Here" link, and look at the values for offsetWidth/offsetHeight, and the values shown for getBoundingClientRect. I'll post a screen shot later today, if you still need one. |
|
Comment author: dmethvin Still puzzled, maybe I'm just not getting it. http://i.imgur.com/DnD3kDL.png |
|
Comment author: anonymous It's possible that revision has fixed it; I don't have access to a Windows machine at the moment, so I will retest and get back to you later today. |
|
Comment author: christopher@… I can confirm that this still exists in IE 11.0.9600.16659. The screenshot is here: http://imgur.com/EStRAki Judging by the dialog above the screen content, it looks like your second screenshot looks like it was taken from Chrome, not IE 11. If it's IE 11, it has the prompt at the bottom of the screen, as shown in the screenshot. |
|
Comment author: dmethvin You're right, I got confused because I was trying to reproduce the issue and can't get anything like you've described. When I run IE11 and go to that page, then click the second "Click Me" link in the box, IE11 goes full screen and shows a prompt but the screen is totally white. I'll try to do a screen recording if that doesn't make any sense but I need to install some software. |
|
Comment author: christopher@… I've seen the "totally white" issue before, specifically on Windows 8 on a Surface. For us, Window 8.1 Update (KB 2919355) released just last Tuesday resolved the "totally white" issue, but left the bad measurements unresolved. |
|
Comment author: dmethvin After several updates and reboots I have been able to finally arrive in the same place as you. http://i.imgur.com/GzQ5tvX.png I've reported this to the IE team privately to see if they have immediate plans to fix it in a slipstream update. Given that the previous issue was a white screen there seems to be some instability in this area. |
|
Comment author: christopher@… Thanks, I appreciate you taking the time to look at it. FWIW, the "white screen" issue was only ever on Windows 8; Windows 7 has been in the current state for a while (some number of weeks), though I don't know how long Microsoft been aware of it. |
|
Hello, what about a workaround similar to videojs/video.js#1333 (comment)? |
|
This problem seems obscure enough that we wouldn't attempt to fix it inside jQuery. Microsoft has been much more responsive recently, introducing fixes in slipstream updates. If you haven't reported this directly to Microsoft via https://connect.microsoft.com/ you should. |
|
I just had to fix this bug in our copy of jQuery UI and will try to
Any objections? |
|
Sounds good to me!
|
|
Right, the test case can be found here: http://codepen.io/AVGP/pen/jPBWje I'll try to write a unit test, too - I might need a bit of help there. Let's see. |
|
Argh, I just realised that part of the manifestation of the bug that I was fixing is actually jQuery UI using |
|
Right, basically I was an idiot two weeks ago. Using that I have now written a small patch, but I wasn't able to construct a reasonable unit test for this :( What do you think? |
|
I'll reopen this for now as IE11 is now frozen and we have a PR. |
IE 11 used to have an issue where if an element inside an iframe was put in fullscreen mode, the element dimensions started being 100 times too small; we've added a workaround that would multiply them by 100. However, the IE 11 issue has been unexpectedly fixed and since our detection was really detecting the browser and not a bug, we've started breaking the browser instead of fixing it. Since there's no good way to detect if the bug exists, we have to back the workaround out completely. Fixes gh-3041 Refs gh-1764 Refs gh-2401 Refs 90d828b
IE 11 used to have an issue where if an element inside an iframe was put in fullscreen mode, the element dimensions started being 100 times too small; we've added a workaround that would multiply them by 100. However, the IE 11 issue has been unexpectedly fixed and since our detection was really detecting the browser and not a bug, we've started breaking the browser instead of fixing it. Since there's no good way to detect if the bug exists, we have to back the workaround out completely. Refs ff1a082 Fixes gh-3041 Refs gh-1764 Refs gh-2401 Refs 90d828b
IE 11 used to have an issue where if an element inside an iframe was put in fullscreen mode, the element dimensions started being 100 times too small; we've added a workaround that would multiply them by 100. However, the IE 11 issue has been unexpectedly fixed and since our detection was really detecting the browser and not a bug, we've started breaking the browser instead of fixing it. Since there's no good way to detect if the bug exists, we have to back the workaround out completely. Refs ff1a082 Refs fb9adb9 Fixes gh-3041 Refs gh-1764 Refs gh-2401 Refs 90d828b
Originally reported by christopher@… at: http://bugs.jquery.com/ticket/14903
IE 11 has a bug in its fullscreen support. If the element being made fullscreen is inside of an iframe, the values for offsetWidth/offsetHeight and the results of getBoundingClientRect are 100x too small.
Details of the issue are here:
http://christophercurrie.github.io/technology/2014/03/20/internet-explorer-11-fullscreen-bug.html
It's also been noticed that click positions *may* be off by 100x in the opposite direction. I'll update the ticket if we find a repro for that issue as well.
Issue reported for jQuery 2.1.0
The text was updated successfully, but these errors were encountered: