iFrame content not loading on iOS devices

1

Hello all,

I’ve looked for a solution to this problem, and while it seems like something that others have come across in other situations I cannot find a solution as it pertains to the problem occurring in HYPE builds.

In my project I am changing the content of an iFrame using a javascript function (iframeElm.setAttribute (‘src’, theurl); ). This works perfectly fine on all platforms EXCEPT iOS devices. I can even recreate the issue if I simply change the user-agent in Safari on my Mac to any iOS (iPad, iPod touch, iPhone) version of Safari.

It isn’t that the content isn’t being displayed - it’s not loading: I have a script which is run by the content of the iFrame when it loads (which also works perfectly on desktop browsers) but it doesn’t run on iOS - because, I’m assuming, the content isn’t being loaded at all. Further, I’ve tested it by adding default content to the HTML widget itself, and THAT content appears but doesn’t change when the function is called.

Is this a know issue? Are there common workarounds?

Any and all help is very much appreciated.

2

hype documentstructure is not the same on iOS and desktop. you may confirm that your query to get the iFrame is working … on iOS

1 Like
3

Hi Hans,

I absolutely appreciate you taking the time to reply, but I’m sorry, I’m not sure what it is that you’re trying to say.

I can see, after examining the element (the HTML widget) via safari’s web inspector using both the default user-agent and an iOS user-agent that the frame appears to be structured differently - however I am unsure as to what change to make to get the frame to load on both desktop and mobile.

The content being loaded into the frame is an external page (on the same domain - but NOT included in the hype document itself).

Thanks again for any assistance you can offer.

4

I’ve got no Hype for the next days … You May provide a hypefile for someone to step in … :smile:

5

And the external code thats calling the change to the iframe

Also using a rect with your own iframe code may help solve this.. see this thread.

Also an idea without seeing exactly what you are doing would be to put this code in your head that declares the widget element in a global var.

Then you should be able to target it's iframe via querySelector.

    <script>

			function myCallback(hypeDocument, element, event) {
				HTMLWidget_  =hypeDocument.getElementById('HTMLWidget')
			  
 
		   return true;
			 
			}
		  
			if("HYPE_eventListeners" in window === false) {
			  window.HYPE_eventListeners = Array();
			}
			window.HYPE_eventListeners.push({"type":"HypeSceneLoad", "callback":myCallback});
		  
		   </script>

External button

<button type="button" onclick="HTMLWidget_.querySelector('iframe').setAttribute('src', 'rect.html');">Click Me!</button>

Can only test this on iOS simulator at the mo.

6

Off-Topic as it's not regarding the iOS but the suggestion: I don't understand the global variable approach? Isn't it the same as:
<button type="button" onclick="document.querySelector('#HTMLWidget iframe').setAttribute('src', 'rect.html');">Click Me!</button>

An ID always has to be unique on a page. Thats why I only use classes if you want truly local targeting inside the Hype Document DOM-Subtree scope. Specially if you start reusing symbols across scenes/layouts ID's are the worst and Hype actually renames them internally to avoid non unique ID's. That is also the reason Hype has the getter wrapper called hypeDocument.getElementById … as it first checks in a lookup if an ID has been renamed by Hype that you are requesting.

1 Like
7

yes, I just happen to be looking at head code so it made sense at the time.

querySelector(). is the main point of it.. :wink:
Also I do not think it's off topic as you are just refining a suggestion.

And yes I try and use classes in most cases but not kowing the setup and reasons behind said setup any and all suggestions may or may not be best.

8

Getting back to @elroy… do you see any errors in the console log with remote debugging? It would probably be useful if you could post a zip of your .hype document, or at least the code that you’re using to get the iFrameElm, assuming it is from a HTML Widget.

9

Thank you for replying Jonathan. I’ve managed to solve the issue after falling down a rabbit hole inspired by the post that Hans linked to. I’m using an embedded iframe in a rectangle now and it renders correctly on both desktop and mobile.

Thank you everyone for the help - once again, this community has been an amazing asset to Hype.

2 Likes
10

Sorry, correction - it was the link that Mark posted that led me down the rabbit hole :smiley:

3 Likes
11

For completeness’ sake if anyone else is researching this down the line also maybe in connection with a WKwebview in Xcode for an iOS project:

Make sure you serve your iFrame content over SSL or it will not display. It won’t throw an error; It’ll just be blank and drive you nuts…

2 Likes