Adapt Learning Community: Fullscreen state and iOS incompatibility

Skip to main content

Hi - I'd be interested to know if this has cropped up before, and if there's a standard solution.

I have an Adapt course that will be accessible via an iFrame. The iFrame assumes embedded objects will be operating in full screen state.

This assumption doesn't appear to play very well with my Adapt 2.0 course (which is using trickle) when viewed on an iOS device. It's essentially impossible to scroll down through the content.

I believe some adjustments to the body and html CSS are the avenues to explore, but I'm a little concerned about trying to unpick and re-stitch this -- I wondered if this had come up for anyone else, and whether there was an established fix?

Thanks.

Hi Gareth,

I've used iframes in several places in a Wikispaces website but had not tested them on mi iDevices until I saw your comment. You're right, they don't work! I'll have to fix them if I can.

I haven't yet tried this solution, but the writer has posted a demo & it works perfectly. I don't know if the code will work in Adapt, but I thought I'd share it anyway ---

http://davidwalsh.name/scroll-iframes-ios

-S

Show parent | Reply

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;
}

Show parent | Reply

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.

Show parent | Reply

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

Show parent | Reply

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.)

Show parent | Reply

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.
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.
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.

Show parent | Reply

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

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

/* TODO
	* on ios need to make jquery.scrollTo use fake scroll.
	* on ios need to make sure overflow notify and drawer scroll
	* on ios need to correct trickle as tranformation + z-index cause the button to disappear
	*/

	/*WHAT WORKS
	* on ios don't use PLP as scrollTo doesn't work (or huge plp as scrolling won't work)
	* on ios don't use huge notify feedback as scrolling won't work
	* on ios don't use trickle
	* otherwise all good - works perfectly on a desktop and android fullscreen iframe
	*/

Show parent | Reply

There seems to be a fix for this described online (although it can require some tweaking depending on the version of IOS being used). These links may provide a good starting place for getting this to work:

(1) http://davidwalsh.name/scroll-iframes-ios. [The demos don't work like an iframe on my iPhone. Almost immediately, the actual webpage that should be inside the iframe appears like a regular link. I never get more than a momentary glimpse of the iframe page. However, judging by the comments, this works for others.]

(2) http://stackoverflow.com/questions/26046373/iframe-scrolling-ios-8 [I can scroll the iframe on this page with 1 finger on my iPhone.]

You may have to read the comments to find out how various people got this to work.

-S

Show parent | Reply

Hi sue.

The fix you mention is my 3rd point and causes my 2nd issue. It isn't the iframe content that scrolls it is the parent of the iframe which is scrolling. This fix means that the adapt toolbar will scroll out of screen and the notify won't calculate its height properly. The extension I've made overcomes this somewhat by allowing the content inside the iframe to fake-scroll but requires some extra work to get trickle going and yo induce scrolling when the notify and drawer are too large for the viewport. Otherwise the responsiveness works well with the extension.

Thanks for the response, but I had thoroughly considered the -webkit-overflow-scroll fix already whilst hacking around and want something far more robust.

I'll let you know if I get some more time to work on a full solution as it's a real shame adapt doesn't do what it should in an iframe on iOS. Finger's crossed I come up trumps. I've posted the code and the issues here to see if anyone else can help.

Cheers,

Ollie

Show parent | Reply

Hi Oliver,

Thanks for such a clear outline of the iFrame issues on iOS. It's the best summary I've seen - and that's after a lot of googling/stackoverflowing!

I'm grateful someone is taking a crack at this. Looking briefly at the code in github it's clear my very modest skills aren't going to offer much help with the outstanding issues, but I'm very happy to do some testing if that's ever of any help. Am I right that this should be treated like any other extension in terms of how it's installed and used?

Gareth

Show parent | Reply

It's not a problem, I quite enjoyed the challenge but it is a lot harder than I'd initially anticipated.

Assuming your LMS and Adapt content are being served from the same domain, the extension will inject javascript and styling into the iframe parent window and put some javascript and styling fixes into Adapt in the iframe content. So, yes it can be treated as a normal extension for installation and should 'just work' i.e. it'll make the parent iframe responsive. (I'm pretty sure it'll break the Authoring Tool though, as there is no schema - yet).

The extension is built in two stages. There are a series of styling and javascript fixes, these will have an effect on all containing iframes, in all browsers and will make the containing iframe responsive (on the assumption that the iframe should fill the window, i.e. that it is a full height + width iframe). The second stage is a preliminary attempt to overcome the iOS Safari problems, and that is the bit which isn't yet finished.

The last real iOS hitch is implementing my fake scrolling idea across all elements which require scrolling in Adapt. I'll have to build a little library to do this, but it is possible (in theory) to reimplement scrolling inside iframes using css 3d translation effects and a couple of touchstart/touchmove event handlers to capture the movement.

Testing, help and advice are always appreciated :D thanks for the friendly nudges!

Oh, the index.html file in the extension is really simple iframe for testing the fixes. Just build adapt and run it through that file or your own iframe file.

Show parent | Reply

Just discovered this thread.

We have discovered some major problems testing Adapt content within an iFrame on IOS devices.

This is a big problem as the LMS systems we use display all our courses within an iFrame.

We have chosen to use Adapt to produce responsive content that will run on phones and tablets so it is not going to be great if there are issues running Adapt content within an iFrame on IOS devices.

I was under the impression a lot of LMS systems use an iFrame to display courses but I may be wrong?

What is the latest take on this issue?

Show parent | Reply

https://github.com/cgkineo/adapt-iOSScrollFix

This repository might be worth a look. I've been meaning to give it a go but never had a chance. Would be glad to know if itworks and how to implement.

Show parent | Reply

Hi -- Coming back to this one after a while....

Is there an up-to-date, recommended approach for ensuring an Adapt course runs as well as it can on an iOS device via an iframe?

I'm aware of a couple of repositories related to this issue, specifically:

https://github.com/cgkineo/adapt-iOSScrollFix

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

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

Are these still current / in use? Or has the framework updated to make these unnecessary? If they should still be used, is there a recommended combination?

Thanks for any advice/experience.

Show parent | Reply

ios scroll fix is the nearest one. but it's quite flakey.

the best approach so far it to have a launch page to remove the course from the iframe.

Show parent | Reply

Hi Ollie,

By 'have a launch page' do you mean that when the learner clicked on the course title in the LMS it would launch, say, 'launch.html' (this would be set in the manifest file) and then that launch page would have a launch button linked to Adapt's index_lms.html?

I also see there's adapt-launchNewWindow extension. Haven't had a chance to try it yet but does that do something similar?

Also, for anyone else who winds up in this thread there are a couple of related threads here and here which are very insightful. It seems Kallidus also uses an iframe, so the issue could be quite widespread.

Finally, I looked at iOS-scrollFix this morning and it requires a patch in Trickle's .js and LESS files. Those Trickle files seem to have been completely re-written subsequently so the patch instructions are out of date and unuseable.

Cheers,

Chris

Show parent | Reply

By 'have a launch page' do you mean that when the learner clicked on the course title in the LMS it would launch, say, 'launch.html' (this would be set in the manifest file) and then that launch page would have a launch button linked to Adapt's index_lms.html?

Pretty much, yes. It actually tries to open Adapt's index_lms.html automatically. The link to do so is there as a fallback in case of popup blockers. There's an example here.

I also see there's adapt-launchNewWindow extension. Haven't had a chance to try it yet but does that do something similar?

Yes it does and quite frankly I would go for this option.

Finally, I looked at iOS-scrollFix this morning and it requires a patch in Trickle's .js and LESS files. Those Trickle files seem to have been completely re-written subsequently so the patch instructions are out of date and unuseable.

Which patch instructions?

Show parent | Reply

I've updated the ios-scrollfix readme and the example branch on trickle so that it reads correctly.

The patch instructions we correct, they just weren't clear.

Show parent | Reply