HYPE iframes appear to be broken in iOS 11.2.5


(Antiphones) #1

I created a HYPE based iPad interactive for a visitor’s centre which which uses iframe to load external content into HYPE pages. It’s been working fine for months, but someone just updated the OS on the iPads the iframes no longer work. What happens is that instead of the HYPE page loading, the content of the iframe loads full screen instead.

This breaks the whole interactive as the navigation and other elements are on the HYPE page and only part of the content is in an iframe within that page.

These screens are very simple, just HYPE’s built in html widget placed on a page, the Specified URL is button is selected and a url is pasted into the box below. That’s all I need to do to demonstrate the problem. In fact I have just tried creating a fresh hype document with nothing in it except this in it and the problem happens on an iPad.

Is anyone else aware of this problem and does anyone know of a fix or a workaround?

Thanks for any help.


#2

Loaded on Mobile Safari or IBooks?
You might be able to fix this issue by using https instead of http.

Do you know what the previous IOS version was?


(Antiphones) #3

Thanks for your reply.

It’s on mobile safari.

iOS 11.2.5

It happens even if you load a local html file in the html widget.


(Antiphones) #4

Actually, after some tests I think it may not be the iOS update the broke it, but the update of KioskPro. HYPE iframes seem to work fine if I put the project on my server on the web using mobile safari. But they don’t work when stored locally on the iPad with KioskPro which is what I’ve been using. So it looks like that latest Kiosk Pro update does not work with HYPE iframes.


(Jonathan Deutsch) #5

Are you using the Specified URL or Embedded HTML for the HTML Widget element?

I’d recommend contacting KioskPro support and see what they say – our iframes are pretty standard.

If they don’t get back to you or say it is our fault, please email their reply along with a zip of your .hype document and we can look further!


(Antiphones) #6

I’m using Specified URL for the html widget element.

If I create an html file by hand with an iframe it works fine in KisokPro on the iPads.

Recreating the problem is simple, open a new hype project, add an html widget, past a url into Specified URL and load this file into KoskPro on an iPad with the latest iOS. So no need to send you my project.


(Jonathan Deutsch) #7

We ask for your document because there are a lot of variables that might be done differently that may not have all been tested. For example, the URL you choose may be a http://, https://, //, or some other protocol URL. The server you choose may be a deciding factor in if it is shown as well. So it saves a lot of time on both our parts to have the exact reproducible case. In fact, having the working case is also useful for comparison!

In this manner, I cannot reproduce the problem. I used http://tumult.com as the URL and then exported a basic Hype document. I put this on a local server, and set Kisok Pro Lite to use this as a URL. It loaded for me.

As I said, I recommend contacting their support since the problem started with an update that they did. They may have other users reporting the problem and even be able to suggest a workaround. Also we don’t have much by way of debugging facilities that they will have for testing the app.

If they don’t satisfactorily help, then let us know – we do want folks using Hype to have success even if the issue isn’t one we’re responsible for.


(Antiphones) #8

I have narrowed it down after a lot of experimentation. It turns out that the problem is only with local files loaded into iframes. It works fine if external www files are loaded into the iframes. But I don’t now think it has anything to do with Hype.

I have narrowed it down to a change in KoiskPro’s latest update. I also realised that my hand coded iframe html files behave exactly the same as the hype created ones. I thought they behaved differently, but in fact it was just because I was loading a local file into one and a web based file into the other.

Turns out the crucial factor was that KioskPro is no longer supporting display of local files in iframes.

So I am now convinced that it has nothing whatsoever to do with Hype. Sorry for the confusion, but I really appreciate your help none the less!


(Jonathan Deutsch) #9

Glad you were able to figure it out!


(Antiphones) #10

Now I’m stuck with the fact that KioskPro has a bug which stops iframes from working on iOS. Since my entire project is based on using iframes this is pretty disastrous.

I’m wondering if there is an alternative iOS kiosk app that is known to work with HYPE using content stored locally on the iPad and the WKWebView engine.

HYPE does not seem to work with UIWebView. When you select the UIWebView engine in KioskPro HYPE projects go haywire with scenes changing of their own accord. However WKWebView engine works perfectly with HYPE.

I just tried eCrisper, and that uses UIWebView, and as expected the HYPE project breaks exactly like it does with KioskPro’s UIWebView. Unfortuantely eCrisper doesn’t have a WKWebView option.

If anyone knows a kiosk app which works with local content and uses WKWebView as the browser engine I would be hugely grateful.


(Mark Hunte) #11

UIWebView is effectively depreciated .

I would contact the Vendors and ask them to update to WKWebView.
The Change should not be that hard for them to implement.


#12

Here’s other Kiosk options:


(Antiphones) #13

Thanks for your suggestions. Unfortunately I don’t think there are any viable options there.
Kiosk Pro - has a bug which stops iframes from working (they said won’t have a fix for a while).
Offline Kiosk - uses UIWebView which is not compatible with HYPE
HTML Presenter doesn’t look like it will only work with dropbox which I can’t use in this situation.
Xstand for iOS has been discontinued. It’s still on the app store but the company has been bought by another firm and they will end iOS support next month.

Surprisingly I can’t find any kiosk app that works with local content that uses WKWebView


(Mark Hunte) #14

I have never used Kiosk Pro but just downloaded the light version.

It seems that it offers a few ways of locking the device to it (the App).

What are you using… and what do you NEED to use.

I ask this because if you can get away with Guided Access mode, you could in theory make you own app in Xcode that takes the Hype HTML and the use Guided Access to lock the device to it…

The App does not need to be on the AppStore ( Unless thats what you need ) you can upload it to the iPad from your Mac.

You will need a Developer account with Apple. But I think the free ones now allow you to write and load to iOS devices.

9to5mac walkthrough how-to-create-free-apple-developer-account-sideload-apps/

Just a thought.


(Jonathan Deutsch) #15

This surprises me an might be a document issue. Hype Reflect previously UIWebView and the only real downside was that performance was not as good.

WKWebView previously did not allow local content, but there’s been ways to do this since iOS 9!


(Antiphones) #16

I have now tried three kiosk apps which use UIWebView and two which use WKWebView. Both WKWebView apps, Kiosk Pro and Xstand work perfectly with HYPE (except that Kiosk Pro currently has an iframes bug and Xstand has been discontinued).

However none of the three UIWebView based kiosk apps have worked with HYPE and all have exactly the same problem. Clicking on a button in HYPE doc which loads a the url for another HYPE doc does not act as it should.

So for example, I’ll have a hype doc with nothing at all in it except a single button and a graphic. That button is just a link to a second hype html doc. The second hype doc has a button which links to third hype html doc.

In any of the UIWebView apps, clicking on the button in hype doc one, jumps straight to hype doc three. Even though there is no link to hype doc three present in hype doc one. This can only mean that when hype doc two loads (which has the link to hype doc three), the link to hype doc three is loaded (without out anyone pressing the link button).

If the link in hype doc one is to a hype doc which only contains a number of scenes but no external links, then when doc two loads, it moves to a different scene within that doc (you can see the fade transition just after the doc loads) again without any user interaction.

What’s even stranger is that if you have three buttons with links in doc one, it will randomly choose one of the three links to jump to, it’s not the same every time. Same thing with scene changes if the link in doc one is to a doc with scenes it will randomly choose a different scene to move to each time you tap the link.

This same thing happens with all three UIWebView apps. It also happens in Kiosk Pro when you switch to UIWebView (Kiosk Pro offers both UIWebView and WKWebView)

But everything works perfectly in WKWebView.

All the links and scene transitions are done using the HYPE inspector, I’m not doing anything fancy or hand coding links or transition changes or anything.

Hence my conclusion that HYPE is not compatible with UIWebView but only with WKWebView at least on iPads with OS 11.


(Mark Hunte) #17

Huh, That sound so familiar… I am sure I had an issue like this once before that totally threw me. I cannot at the mo remember what it was or what project I was working on but I think it was one of my Xcode -Hype projects… which deals with multi Hype doc controls…

Which means I am not sure I solved it… I will look through my ole projects later to see if the jog my memory.

If this is true, as UIWebView is being depreciated I am not sure if there would be a point in trying to fix this.

But if these guys can I am sure they will…


(Antiphones) #18

I have an apple developer account. I have successfully created many apps using Adobe Edge and xcode via phonegap. When Edge was dropped by Adobe, I switched to HYPE.

However I was unable to get HYPE to work with xcode and phonegap. Not sure if the problem was with HYPE or phonegap but xcode threw a load of errors when I tried to load the HYPE project and it refused to compile it.

I tried for days and days to get it to work, but never got past the stage of long lists of red code errors xcode listed when I loaded HYPE projects. Again I don’t know if it was HYPE or phonegap that was the problem.

The process is so complicated anyway, it’s pretty crazy. Made worse by the fact that apple and phonegap have changed the process several times, so you get used to one very complex process and the next time you come to compile, it’s all changed. So I gave up on using xcode and phonegap even though I’d been using it fine for many years with Edge.


(Antiphones) #19

Thanks for having a look Mark I appreciate it.

At the moment my only solution is to use xStand as Kiosk Pro does not work with iframes which my project depend heavily upon. xStand has been discontinued, but it does work with HYPE as it uses WKWebView. However unlike every other kiosk app I tried, xStand does not seem to recognise the viewport size settings used by HYPE. So my projects appear too big to fit on the ipad Screen. They fit perfectly using Kiosk Pro. So I’m trying to find a different way to control the view port size setting.


(Mark Hunte) #20

Probably a combination of things…

We have put up examples of Apps built with Hype and Xcode.

A search for WKWebView… should bring up some example. I think must does not use Phonegap. I know my one do not…