Browser issue XenForo misbehaves inside an iframe on iOS

When placed in an iframe, XenForo misbehaves when viewed on an iOS device.

Whenever we try to compose a post on XF on the iPhone the screen jumps to the top whenever we hit the space key.

On Windows, Mac OS X, and Android all this works perfectly fine. On iOS only, writing a post will make the screen scroll to the top whenever you hit the space key (and sometimes other keys too).

In the previous version of XF that we were using 1.4.something the problem was even worse - it would bounce back and forth between top of screen and the editor window on every key stroke. In 1.5 now it just goes to the top of the screen and stays there.

To test this for yourself, create a "test.html" file and put your own community forums in an iframe. Writing posts in the forums will no longer work correctly on iOS. Here is the code:

<!DOCTYPE html>
<html style="height:100%;">
<head>
<title>XenForo in iFrame</title>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body style="position:relative; margin:0; height:100%; overflow:hidden;">
<div style="position:absolute; top:0; right:0; left:0; bottom:0; overflow:auto; -webkit-overflow-scrolling:touch;">
<iframe style="box-sizing:border-box; width:100%; height:100%; border:none;" src="https://xenforo.com/community/">
</iframe>
</div>
</body>
</html>
 
Our XenForo site is one of many internal corporate websites we use - we also have a couple of Wordpress sites and an osTicket site. All are controlled by common log-in wrapper. One log in for all sites. We have some custom code to log the user into all of our sites at once. The wrapper also allows the user to navigate between our sites seamlessly. The wrapper uses an iframe to switch between sites while keeping the same UI look and feel.

Does that answer your question? :)
 
This has been an issue with iOS since long before it was called iOS (what we now refer to as version 1). The circumstances are hard to narrow down; it's not just frames that trigger the issue. From my experience, it's nearly impossible to eliminate in WYSIWYG editors. You may want to try playing around with different positioning methods and wrappers for the iframe; if you're lucky, you'll stumble upon a combination that works. You could also try using framesets instead of iframes--they've been deprecated in HTML5, but they still work and probably will for at least another decade. Rumor has it those work better. You may have some luck if you disable the rich text editor for iOS users, but the bug can still happen with normal textareas.
 
I'm also going to call this a browser issue and send this to Apple.

The quirkiness here isn't exclusive to loading XF in an iframe. I tried various sites and they all behave very erratically. It doesn't even seem exclusive to rich text editors, but I can confirm some really odd quirks in all of the other rich text editors that I've tried; admittedly some are worse than others.

I don't think there's anything specific we can change here.
 
It is most definitely an iOS Safari issue. None of the other platforms have this issue. Even Mac OS X Safari is fine. I was just hoping that maybe there is some kind of workaround you can add to the text editor in XF to get iOS Safari playing nicely. There was a change in behavior between this version of XF and the last version. The last version was even worse - with every keystroke it would bounce (scroll) between top of screen and the editor window. With the most recent update it would just scroll to the top of the screen and stay there (no more bouncing). So if code was changed in the text editor between those versions of XF then that is in the vicinity of what is going on. It is also possible that it wasn't actually a change in XF but a change in iOS - I believe iOS went from 9.1 to 9.2 recently.

There may be workaround - check out this thread - it involves changing the html and body css styles a bit - basically it seems like adding position:absolute and setting left, top, right to 0 could fix the issue. I will try this first, but I am not sure where in the XF templates or code I would need to look at.

https://www.scirra.com/forum/solved-iframes-and-ios-devices_t89144
 
Will check it out. Obviously we have to be cautious in making changes such as this that could have an adverse effect on other browsers or indeed this browser if they ever fix the bug.

I will also do some testing on iOS 9.3 beta later today. It may well be fixed there but I haven't tested it yet.
 
I think the iOS <iframe> bug has been around for at least since iOS 7 so I seriously doubt they have fixed it. :-\

I do appreciate the assistance. Most of our users are on iPhones so this kind of sucks for us.
 
Yeah I have a bug report open regarding RTL support for a specific bug since iOS 8.

Does it work better in Chrome on iOS by the way?
 
Nope - all browsers on iOS use Safari to render. It is a requirement by Apple. There are really no non-Safari HTML rendering engines on iOS. Chrome on iOS is really just Safari with a Chrome skin around it - the actual contents are handled by the Safari HTML rendering engine. So to answer your question, yeah the same bug is in "Chrome" on iOS :-\

Out of all the rendering engines that we develop for, iOS Safari is easily by far the worst. Oddly, Mac OS X Safari is much better. You'd think they'd be the same rendering engine... but no... it's completely different. :-\
 
Just a thought, you could try using the object tag instead.
Code:
<object height="600px;width:100%"
    type="text/html"data="http://example.com"></object>
 
We plan to try that as well - but from what I read online when Google searching for "iOS iframe scroll jumping" someone else tried that as well and apparently that didn't fix it.
 
Nope - all browsers on iOS use Safari to render. It is a requirement by Apple. There are really no non-Safari HTML rendering engines on iOS. Chrome on iOS is really just Safari with a Chrome skin around it - the actual contents are handled by the Safari HTML rendering engine. So to answer your question, yeah the same bug is in "Chrome" on iOS :-\

Out of all the rendering engines that we develop for, iOS Safari is easily by far the worst. Oddly, Mac OS X Safari is much better. You'd think they'd be the same rendering engine... but no... it's completely different. :-\
It's still worth checking. Most third party browsers use the old UIWebKitView and haven't yet updated to the newer version. Though Chrome is doing that soon.
 
It's still worth checking. Most third party browsers use the old UIWebKitView and haven't yet updated to the newer version. Though Chrome is doing that soon.

Ah - interesting I didn't realize there were different versions of UIWebKitView that apps hook up to. Is it safe to assume that the native Safari app would always be using the latest one?
 
Sort of. Since iOS 8 Safari has used WkWebKitView so since then we have seen quirks in Safari that aren't in other browsers and vice versa.

Chrome 48 looks like it will use WKWebKitView though so as a workaround it's likely short lived!
 
Huzzah! I found the solution! No need to make changes to XF. The solution is some custom JS code that is run in the parent document that contains the <iframe>. This is the code I wrote (it uses jQuery but I'm sure it can be done without jQuery):

/* because ios safari is too stupid to handle iframe content height changes
* properly we have to apply this workaround to set the iframe height manually
*/
$('iframe').load(function() {
var self = this;
function resizeiframe(eventObject) {
var height = $(self.contentWindow.document).height();
$(self).css("height", height);
}
resizeiframe();
$(self.contentWindow).resize(resizeiframe);
});

In other words - setting the "height" css value of the <iframe> to the content height fixes the jumping issue. The JS code updates the height value whenever the height of the contents change. This of course will only work on same origin contents.
 
Top Bottom