Curse you, google!

I’m not real happy with Google, right about now.

I’ve been working for months on trying to get cross-browser workings going using AJaX (finally discovered postMessage()), and I’m about to move on, when I decided to try my project in Chrome.

iFrame didn’t work.

Did some looking around, and discovered that Google is disabling iFrame in their apps, including Chrome. WTF! I’m reading that I’m supposed to replace iFrame with webview. Okay, so I put a conditional in my CF code to detect the user-agent, and if it has ‘chrome’ in it, use webview; if not, use iFrame.

webview isn’t appearing. It will display any text that I place between the open and close tags, but that’s it. NOT the page that is listed in the src attribute.

Has anyone else run across this? How did you fix it? (Other than you stopped coding for Chrome.)



EDIT: Can someone please explain to me why my title isn’t in all caps, like I typed it?

1 Like

I’m not aware of Chrome disabling iFrames. I still use it every day and see or interact with (or use) plenty of iFrames.

My guess (hope?) is that there’s a feature in Discourse or in SP settings that stop random caps-shouting titles :smiley:

Source? I use iframes every now and again, they are still essential in a lot of cases.

Your guess is correct.

@WolfShade, iframe works for me in Chrome using CodePen…

@WolfShade - is it possible that you stumbled across some misinformation while troubleshooting your iFrame usage, and this is a big headache that resulted from it?

Generically, here; and specifically webview, here.

Google Groups post on mixed iFrame content blocking since v29.

And a lame Mozilla article stating that instead of using both HTTP and HTTPS, you should just go all HTTPS. (Which is wonderful, if you’re Comodo or VeriSign.)



1 Like

So you are building a Chrome App, as that may well indeed not support iframes… :frowning:

Your first source is talking about apps that are signing up as Chrome Apps in the store, which is a different thing than a normal website or app, and it’s not barring iFrames, but specific usages of them, as far as I have quickly scanned, here. Does this apply to you?

Re: Mozilla - there’s always been (in any browser that I know of) issues with HTTPS pages pulling HTTP content in via iFrames - it’s a security hole.

Edit: If you’re building a Chrome App, I’m bowing out of the discussion, I’ve never had any interest or need to do that! But I’d be interested to hear the webview solution, at any rate, if there is one.

Edit 2: Actually I’m leaving work and gonna be on the road for hours on end, so I’m out anyway at least for now :wink: Good luck.

I did a Google search using “chrome iframe https” as the keyword search (after discovering that my iFrame in Chrome wouldn’t load the page from the same domain via HTTPS… works great in FF; IE10 at least gives the user a prompt asking if they want to load the HTTPS content.) I assumed that webview was Chromes answer to WEB mixed-content issue.

In my airgap dev network (which isn’t subject to all the security restrictions my NIPR system is), the iFrame in Chrome will display an error message. “Error 501 (net::ERR_INSECURE_RESPONSE): Unknown error”. I have postMessage working in FF and IE for pushing error messages from HTTPS iFrame to
HTTP parent page. But Chrome refuses to load it.

I’m hating Chrome more and more (although, I’ll be honest - not nearly as much as I despise IE.)


Do you have a simplified version you can throw into CodePen to show the issue? Does it have to be an HTTP host calling a HTTPS request? Is it HTTPS to HTTPS? I feel like this should be resolvable, but I’m trying to figure out what the underlying conditions are to cause the error.

Hmmm, since HTML5 I’ve come to expect that most of the “strictness” has been thrown out the window and left to rot at the roadside.

Anyway, IIRC at one time the object tag was intended to be the better alternative to iframes.

Might this be a step in that direction?

I’ll try to get something going.

Here’s yet another annoying thing. Govt recently announced that all federal websites should be all-HTTPS by 31 DEC 16, so this won’t be an issue after then. But anyone who has worked for the USG knows that not all sites actually will be all-HTTPS by that deadline. And, anyway, that’s a year and a half away.

I can tell you that in order for this project to go all HTTPS will require 10 - 12 forms/requests filled out, approved, second-approved, argued over, resubmitted, then the response will be that the sites will have to go through a testbed process, and then the requests will be dropped into the eternal pool of requests where it will linger in limbo until sometime around 2019.

The parent page is loading HTTP. The iFrame is loading a contact us form via HTTPS, and the reason for this is because all our forms are supposed to submit via HTTPS. I’m using AJaX to submit the form because I’m trying to bring this new public site into the 21st century (no standard form submit which will reload the page.) The postMessage is to deliver server-side form validation messages (success or fail). But Chrome (which, granted, is a small portion of the user-agents that currently access the public site) isn’t co-operating.



1 Like

Actually, I don’t think I can. I don’t have live domains that I can use as examples for the HTTP and HTTPS; and our DEV network is air-gapped, isolated from the internet, so that can’t be used. :frowning:


UPDATE: The issue may be the SSL certificates on the DEV network. I’ve got our incoming SA working on re-issuing SSL certs with exp dates FAR into the future. :slight_smile: Hopefully, that will fix it. But, if it doesn’t, then I’m back to square one.

Okay… I don’t understand it, so don’t ask. I have no clue.

The SA was working with the former SA to try to re-issue the SSL cert with a later date. They didn’t do anything with the SSL cert, yet, but made a change to the DNS server. Suddenly, the iFrame HTTPS is loading in the HTTP parent document. WTF?

(banging head into desk)



Yes the object tag was announced as the replacement for iframe way back in 1997 when HTML 4 was introduced.

There was an issue with using object instead of iframe with IE7 and earlier but object works perfectly as a replacement for iframe in IE8 and all more modern browsers.

HTML 5 has reintroduced iframe as a tag just after it had become completely unnecessary.


This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.