The Facebook API doesn't work in Opera:
FB.Canvas.setSize - not change a canvas size.
FB.Canvas.getPageInfo - does not call callback function.
To reproduce:
Open http://apps.facebook.com/operafbbug/ in Opera and, to compare, in Chrome (or Firefox, IE)
Expected Behavior:
The Canvas height will changed to 1100, excepting Opera
When the FB.Canvas.getPageInfo function is called and returns data, this page will show alert 'info'. You will see this alert in all browsers, excepting Opera, again.
Bug in facebook bug tracker:
http://developers.facebook.com/bugs/188820761219553
Quoting myself from the FB bug tracker: Opera fires an asynchronous load event for about:blank which results in the canvas_proxy IFRAME being prematurely removed. Opera starts running into this because of hiding document.attachEvent to avoid another, related problem caused by the IE branch of the script ( https://github.com/operasoftware/browserjs/issues/1 ).
As for workarounds, doing
document.attachEvent=function(){}
before embedding the Facebook script should work as a workaround, but is very ugly and probably won't keep working in the future. This needs to be fixed by Facebook (by ignoring the problematic load event and not remove the IFRAME until it knows the real target content loaded) or by Opera (by figuring out what race condition or timing gotcha makes Opera fire an unexpected load event even though the IFRAME is being navigated to some other URL).
Opera should probably add a temporary workaround to browser.js too. You should probably ignore this issue altogether and hold off testing with Opera until Opera and/or Facebook sorts it out.
Related
I have a problem with setting cookies in an iframe (which loads a site from another domain).
On my site X.COM I load <iframe src='Y.COM'>
Y.COM tries to set cookies, but Safari blocks they, as this site was not visited before. So loading Y.COM fails because it can't work without cookies. Is there a way to solve this issue?
P.S. I cann't modify any data at Y.COM.
P.S.S. Also we can modify Safari's settings - "Accept cookies" = "Always", but it is not a solution for me - it seems to be impossible to lead every user to do it..
I experimented a similar problem. A web "parent" page open my "child" website in a jquery fancybox i-frame cross-domain. Not problem at all with Explorer, Chrome, Firefox, Opera and even with Safari (5.8.1) on MAC. But with iPhone, iPad and mini iPad, the session in the i-frame is lost.
That's mean that at every click on an element in the i-frame (web site is in aspx) a new session started.
We solve the problem in a very simple way:
when the parent website start, it call a page in the child site directly (not in an i-frame). In this page I just set a session variable and I redirect to the parent website. Now when the child website is open in an iframe, the session is kept.
I have a game in Facebook and suddenly a new problem came out. In Chrome, Safari, Opera and Internet Explorer work fine. In Firefox the Facebook page loads good but when the game iframe starts loading, it gets a points that automatically reload the whole page. I can not understand what's happening. Anyone could know the issue?
You need to either accept third party cookies or locate the one cookie it needs to load (seems to be the developers's own website usually - look into the list of cookies currently stored on your computer in ff options) and whitelist(allow) that.
Since that answer is nowhere on the net and I just spent one hour trying to figure it out to fix the same problem I'm putting it here in the hope it'll help.
Well, it is good know problem for me, about half year ago I got the same also with Firefox. In my app real problem was that, firefox with his AJAX action, lost somewhere access token from parent window/frame...
My advice: try to stick access token to AJAX's request too.
Edit in response to comment:
Unfortunatelly, now I can't see any token in url into my app frame... but what I did then was something like that: (using jQuery):
$.get("http://mydomain/getInfo?id=12345 + '&' + (location.href.split('?'))[1])
where location.href.split('?'))[1] add session/access token to my intern AJAX request.
Anyway, if application works fine few days ago, check official facebook dev forum, there is often some cause on facebook side...
Any site I see generated with the Lift framework displays strange behaviour in the Chrome browser - on page load, the browser tab is blanked for around 1/3 of a second before the page is displayed. It's very disconcerting. This behaviour does not appear on Firefox or IE, just Chrome. In IE and Chrome, there is a slight delay after requesting a page during which the old page remains visible, which is the expected behaviour.
The behaviour is visible in Chrome even in the Lift homepage:
http://liftweb.net/
Does anyone know why this happens?
It seems to be blank until style.css is loaded, from what I gather from the developer tools in Chrome itself. In the audit, it says style.css should be moved to head, but it is already there. I wonder if the <content> tags that enclose everything are causing problems?
I'm writing a ajax chatting webapp, just to test working with GWT.
To simulate server side push of chat messages from the server to the browser, I have a XHR request running behind. It all works fine - except on Chrome, the browser is displaying a loading icon (a spinner) because of the XHR request on background.
Is there any way to avoid this? I've tested it in Firefox, and it doesn't display such behavior.
EDIT - I found the solution. http://groups.google.com/group/google-web-toolkit/browse_thread/thread/a0330cb47e05c485?fwc=2
quoting the GWT groiup post:
Chrome shows the loading indicator if connection was made immediately
from the "body onload()", i.e. from onModuleLoad().
Chrome shows the loading indicator if connection was made immediately from the "body onload()", i.e. from onModuleLoad().
No, there is now way to disable this.
All AJAX requests cause Chrome to display this. I'm guessing it's for security reasons. (The user is aware of any AJAX requests that he/she might not be aware of.) Also, it indicates that data is being fetched - a type of status indicator.
I've got a form in a web page with an action that is "mailto:email" (where email is a real email address). When I load this page in Mobile Safari in regular mode (ie, not launched from home screen with app-capable mode), this works fine - after I submit the form, the email app comes up. However, when I'm in app-capable mode and have launched from the home screen (so, no Safari chrome), and submit the form I get the error "URL can't be shown". However, a regular mailto: link (ie, not in a form) does work when in app-capable mode.
Has anyone else noticed this? Any workarounds? Are forms disallowed in app-capable mode?
Thanks,
Elisabeth
This accurately describes the issue. There is nothing wrong with the mailto link, the mailto link fails to load. Often the webapp crashes.
The funny thing is that tel: link for telephone numbers work fine.
window.location.replace does in-fact work. Thanks!
Here is the jQuery to fix this automatically...
$('a[href^=mailto]').click(function (event) {
event.preventDefault();
window.location.replace = $(this).attr('href');
return false;
});
I think I've figured this out. I noticed when in app-capable mode, any http link will take you out of the app and launch a separate mobile safari window, take you to the page and show the Safari chrome. Makes sense (typically one wouldn't link to anything from an "all in one" app-capable web app. I noticed this because I implemented a 4 page app with my own "tab bar" at the bottom and was linking amongst the .html files with plain http links in the a element. When I replace this with a javascript function to load the pages using document.location.replace this doesn't happen.
So, on the form - I think what must be happening is that because I'm using a scheme (in this case, mailto:) somehow the browser is needed in "regular mode" to interpret the scheme and do the right thing by launching the email app and this clearly doesn't work when submitting a form. I haven't yet found anything in the Apple documentation specifically about this, so if anyone knows the technical details, please do post!
UPDATE: I did find that I can access a server side script using a form in web-app mode, so I'm still curious about the mailto: issue, if anyone has an answer.
Thanks,
Elisabeth
I am having the exact same issue with mailto links not working in the web capable mode. I just got done submitting a bug report to Apple. Let's see what happens, meanwhile I found another dev. platform for web apps that works in web capable mode and mailto links work, but it is funny how it works in this even--it is not as fluid as it is in Safari. Because even in this new web dev tool that I found, it closes your app and launches mail client, which is lame. In Safari it just slides in a mail window that slides back out if you hit cancel or send--it doesn't actually close your app.
Here is a workaround that does not depend on JQuery:
aTmp = document.createElement("a");
aTmp.href="mailto:example#example.com?subject=Test&body=Hello.";
aTmp.click();
Update: To run this code from a bookmarklet you have to wait about 1000 ms before the bookmarks bezel is closed and the browser is ready to respond. I realized this by wrapping the code in a setTimeout function.