15

I have created a facebook fan page here:

http://www.facebook.com/apps/application.php?id=120196931351044&v=app_120196931351044

It incorporates iframes to call certain pages/image galleries which use jquery. Everything works fine in all browsers except for Chrome. Nothing shows up in Chrome from the iframes, just empty white background.

I tried using load event instead of ready handler but still no luck.
Has anyone witnessed the similar issue in chrome?

Your help will be greatly appreciated.

The big images in the header come through iframe,a page incorporating jquery.

Update:

As shown in the comments below, it doesn't seem to work even in Safari as well.

Update 2

The same code seems to work in chrome when run outside of the iframe, here is the link to working page:

http://jsbin.com/esame4/4

Update 3:

It seems that this problem persists in chrome when using iframes as can be seen here:

http://www.google.am/support/forum/p/Chrome/thread?tid=2c81c3e3fd99b388&hl=en
http://forums.sharethis.com/topic.php?id=2742

Sarfraz
  • 377,238
  • 77
  • 533
  • 578
  • 1
    This seems to be the case for safari too – Dr. Frankenstein Jun 23 '10 at 17:28
  • @yaya3: Yeah, that's true, safari also behaves like that in my case. – Sarfraz Jun 23 '10 at 17:34
  • It's not working in Safari 5.0 either – Claude Vedovini Jun 23 '10 at 17:39
  • I see this happening outside the `document.ready`, tried moving it inside? `var $curbox = ('#content_navigator .box:first');` – Nick Craver Jun 27 '10 at 10:21
  • @Nick Craver: I don't think that is the issue because same code runs when run directly into the chrome rather than an iframe. – Sarfraz Jun 27 '10 at 11:36
  • @sAc - It *sometimes* runs directly in chrome, at least in chrome 6, so you have a race condition going on. – Nick Craver Jun 27 '10 at 11:39
  • @Nick Craver: I have updated my question, not sure what is wrong but here is the link to working demo: http://jsbin.com/esame4/4 – Sarfraz Jun 27 '10 at 11:45
  • @sAc - jsbin puts your javascript *after* the element is declared, so it's there, when it's before and not in a `document.ready`, like the actual page it's not guaranteed to be available, it usually *isn't* available. As a side note, you have some validation errors...your page starts with a ` – Nick Craver Jun 27 '10 at 12:03
  • @Nick Craver: hmm right, i will look into that. – Sarfraz Jun 27 '10 at 12:09
  • @Nick: Tried putting jquery code at the bottom, i wonder why there are validation errors because things seem fine to me. DOCTYOE and style tags are properly setup: http://codedumper.com/axavi. No luck in chrome :( – Sarfraz Jun 28 '10 at 12:29
  • @sAc - You're including `app_css.php` **before** the `` tag, so you're getting `` to start with, need to fix that :) – Nick Craver Jun 28 '10 at 12:32
  • @Nick: now no errors but yet doesn't work in chrome, seems to be a serious issue.... – Sarfraz Jun 28 '10 at 12:45
  • I just tried it on Chrome 5.0.375.86 on Windows XP and it works fine. – bimbom22 Jul 02 '10 at 20:52

6 Answers6

5

The solution is actually simple. To get your iframe stuff display well in Chrome when you see a Facebook page/app, you have to call content or properties from an secured server.

You MUST ensure that all your required files and folders like the CSS, JS and image files are inside a secured folder.

  1. For this you need a SSL certificate for your domain.

  2. Alter your htaccess file and mod rewrite condition to force SSL for all or specific folders especially when you are using variables to call the files. If you're using absolute URL change them to https.

Hope this helps!

Rob
  • 415,655
  • 72
  • 787
  • 1,044
fbappsninja
  • 51
  • 1
  • 1
2

A few suggestions, mostly related to your Javascript setup on the gallery.php page:

My first instinct is to say it's a bug (or even an intended response) in the way Chrome/WebKit handles cross-site scripting and other similar potential security holes. I know some security holes involve running script from inside an iframe (as this former Chrome bug refers to).

Perhaps it's something to do with you referencing your jquery.min.js from ajax.googleapis.com instead of hosting it on the same domain as your gallery.php page. Try putting a copy of jquery.min.js on your server and linking to that and see if it helps.

Also, try moving your the jQuery library <link> tag to inside your <head> tag, as that's a more appropriate place for it.

You might also try using the jQuery Innerfade library to run your rotating banner. It would clean up your script and, who knows, perhaps convince the browser that you're not trying to exploit a hole in security.

If you're unable to switch to using Innerfade, at least change your JavaScript variables to not be named with a $ (e.g. change your "$curbox" variable to "curbox"). It might further clear up any confusion the browser may be having with your Javascript. At the very least, it's good practice, especially when using jQuery.

JoshMock
  • 1,291
  • 1
  • 9
  • 21
  • You sure? Still looks like you are using $ in your variable names. I doubt it'll make a difference, but it's good practice anyway. http://www.codelifter.com/main/tips/tip_020.shtml – JoshMock Jul 01 '10 at 15:26
  • Yeah, i had tried even replacing $ with jQuery but that isn't problem also. – Sarfraz Jul 01 '10 at 18:34
  • I mean in your actual variable names. Technically, you shouldn't have any special characters except for underscores in your variable names, but you have variables named "$curbox" and "$prevbox" when dollar signs aren't allowed in variable names. PHP is the only web language, to my knowledge, that requires or even allows that. Like I said, I doubt that'll fix the problem, but you should clean it up anyway. – JoshMock Jul 01 '10 at 20:51
  • “dollar signs aren't allowed in variable names”. According to *JavaScript: The Definitive Guide (5th Edition)*, “prior to JavaScript 1.1, dollar signs are not legal in identifiers”. [According to Wikipedia](http://en.wikipedia.org/wiki/JavaScript#Versions), JavaScript 1.2 was implemented by **Netscape 4.0**, and Chrome has, since version 1, supported JavaScript 1.5. I *think* we’re alright having dollar signs at the start of variable names now. – Paul D. Waite Dec 21 '10 at 17:40
  • My bad; I was completely neglecting the fact that $ is a variable name itself. That was dumb of me. – JoshMock Jul 16 '12 at 22:04
2

If it's a problem with document.ready not getting called in the iframe because the page has already been loaded at that point, is it possible to instead put the javascript that you want to load at the bottom of the new page instead of in document.ready, so that it'll load up once everything else has been loaded? I've done something similar on some pages, like put a bit of javascript at the top of the page to show a loading image, and another chunk at the bottom to hide it, etc...

<html>
    <head><script>function pop(){alert("Page Loaded");}</script></head>
    <body>Lorum ipsum...</body>
    <script>pop();</script>
</html>
AndyD273
  • 7,177
  • 12
  • 54
  • 92
1

Hey sAc, I've tryed it on Chrome 5.0.375.86 and it worked. Since safari and chrome uses the same web engine (webkit) it could inherit the same problem. Since it's a javascript problem, and now chrome uses google V8 javascript engine instead JavaScriptCore (default javascript engine from webkit), this problem seems to be solved in Chrome's last versions. Maybe it can be a problem on JavaScriptCore do not dispatching the ready or load events since DOM is already loaded on the document before the iframe has been constructed. A temporary solution could be set a flag to check if the content was initialized. Put a five to ten secs timer with setTimeOut to check this flag. If it not initialized, then call it on the setTimeOut callback. So if safari doesn't call the load or ready events, the setTimeOut could do it for you. Of course, don't put it inside your jquery layer. Put it as a pure javascript tag inside your HTML to be loaded by the iFrame.

mannysz
  • 951
  • 8
  • 19
0

Check the response headers in the page that you're trying to put into the iframe. You're looking for a header called x-frame-options.

This is a new security option that tells the browser not to load the frame content. Lots of web servers will add it by default.

It's something worth checking.

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Keith
  • 150,284
  • 78
  • 298
  • 434
  • Tried setting those headers with `header("x-frame-Options: SAMEORIGIN");` but still the problem persists. – Sarfraz Jul 01 '10 at 11:42
  • @sAc - so was there an _x-frame-options_ already set? If so changing it to SAMEORIGIN would help but only if your frame is a local page. Otherwise never mind - it was worth checking, just in case. – Keith Jul 02 '10 at 07:30
0

Reason for not working is because the browser mark the iframe as insecure. To fix this just add a charset to the head of the page that you want to display:

< head ><br/>
< meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2"/><br/>
< /head><br/>
Alexei - check Codidact
  • 22,016
  • 16
  • 145
  • 164
1024mb.ro
  • 1
  • 1