Example extension for all fixes i've managed so far:

https://github.com/oliverfoster/adapt-responsiveIFrame

1. iOS iframes do not calculate their width based upon the window.innerWidth of their containing window.
   • they use window.outerWidth which can be a few hundred pixels too large. this stretches the borders of the iframe beyond the viewport size.
   • width: 100% on an iframe will create bad widths as the orientation changes, even if the meta scale tag is restricted to 1. because of the outerWidth phenomenon.
   • it is possible to sidestep this using javascript to set the iframe width on body orientangechange="" events.
2. iOS iframes rarely honor css height values.
   • iFrames tend to be as high as their containing content
   • The iframe content height cannot be controlled by overflow:hidden or overflow:scroll but is defined by the height of all the display:!=none content, regardless if its parent is shorter.
   • This means that the window height inside the iframe is not representative of the viewport height of the device, but of the iframe content height. This means that anything centered horizontally with javascript will not be able to calculate the viewport height properly.
   • This can be sidestepped using a combination of the javascript from point 1 and some javascript inside Adapt, but both the iframe document and iframe content document need to be on the same domain for this to happen.
3. You cannot scroll inside an iOS iframe. (see Gareth Walker's point) 
   • The iframe does not respect the overflow properties on its content.
   • To make an iframe scroll with user interaction, you can only scroll the iframe in its container and not scroll the iframe content inside the iframe.
   • This means that any fixed position content will not stick to the viewport top and bottom but will instead scroll with the iframe out of the viewport.
   • This cannot be fixed but it can be hacked using transform: translate3d on the page or menu, but has adverse effects on trickle buttons and any other scrolling content such as the drawer or notify.

It seems until Apple fix the iOS iframe bugs, Adapt should not be used in an iframe on iOS.

Sorry.

Ollie.

Hi Matt,

Thanks for your thoughts. The set-up of iframes can certainly vary. In the case I'm currently testing it is very responsive and the Adapt content works well across the great majority of devices I've tested. 

I think the issue I've encountered is really a more specific one. Iframes on iOS appear to be particularly fussy when it comes to handling scrolling content. There are some established fixes for this, but I'm not sure quite how they can be best applied within the context of Adapt's CSS. 

I'll try to take a deeper look, but certainly if someone with more experience of the framework's CSS could offer any advice I'd be grateful for pointers!

(On the more general point: I guess my take would be that iframes are hard to escape in elearning, and while they'll always be fiddly and frustrating it's a worthwhile endeavour for the framework to give as much of a fighting chance for content to work in that context as possible.)

iframes are (normally) not responsive elements, therefore putting responsive content like Adapt into one is going to cause a problem, unless you're able to change the iframe to make it responsive

there are some hacks you can do to Adapt to make it work in an unresponsive iframe, I believe these effectively involve disabling the responsiveness of Adapt. Sorry I don't have any more info than that, my knowledge of the CSS side of Adapt is very poor

Update: I've tried just adding the overflow-y and -webkit-overflow-scrolling elements to html and body, without the height.

This again gets some minimal scrolling in iOS - but everything seems to break at the first 'trickle' element. On other platforms, e.g. desktop browsers, there are again some trickle related issues with lots of white space and also scrollbars-within-the-iframe.

 Hi Sue,

My initial attempts to fix have involved trying to add the below to the html and body elements, with some excessive use of !important to nix any overrides. 

The effect was to get scrolling sort-of working in iOS, but at the price of breaking a lot of stuff with scrolling/trickle.

Just selectively adding -webkit-overflow-scrolling doesn't seem to make any difference, however.

I'm a little surprised this hasn't come up before, given how often courses will be displayed in iFrames in LMS/VLE contexts. Any advice will be very welcome.

html {
height: 100% !important;
-webkit-overflow-scrolling: touch !important;
overflow-y: scroll !important;
}
body {
overflow-y: scroll !important;
height: 100% !important;
}

Hi Gareth,