Okay, I'm at my wits end - I can't figure this one out. If you go into Facebook in Safari on a desktop/laptop and in the search bar type the name of my app: "Hopple Hop", and then click on the app itself (not the app page), instead of launching the app, it triggers this error message in Safari:
"Safari can't open "fbrpc://nativethirdparty/f?appid="
Followed by hundreds of characters. Basically, it's a big long URL string, in the "fbrpc://" protocol, and it tries to launch directly into the browser as-is.
As you can imagine, this is not the intended functionality of searching for my app. The intended functionality is that they type "Hopple Hop", click on it, and the Facebook canvas game starts. If you go to
https://www.facebook.com/appcenter/hopplehop/
You can see it there. And if you click "Play Now", it launches properly from:
https://apps.facebook.com/hopplehop/
I know it's probably a configuration issue. There is also an iOS app to go with it.
I'm not sure what the end cause was, to be honest. It appears to be a very specific configuration issue with my phone / Facebook account and the way I've authorized the game. It doesn't seem to be an issue for anyone else. I don't unfortunately know the root cause.
But if anyone else sees this error, it's likely only you are seeing it.
Thanks,
Glen
These are the various options that i have tried using table structure for newsletters. My problem is that on the click of the phone number on mobile devices and it redirects to a new page having the callto or tel in its url, whereas in browsers it redirects to a blank page. Help me out on this.
9865551555
9865551555
Be sure to include the country code. The format found in this tutorial worked well for me.
(986) 555-5155
So I am just trying to initiate a call from a webpage, and that part works fine.
But when the call link is called and the note pops up if I want to call. Safari at the same time steps one page back in browsing history!
I am trying with two syntaxs as of now
<a>Click the phone number to initiate call: </a>Call<br>
Phone me
So if anyone knows how to avoid browser going back on press of tel link that would be great.
I have created a simple application using Phonegap in XCode using HTML. My code looks like this:
<dd>Office Number</dd>
<dd>Personal Number</dd>
<dd>Log in to your Mail ID</dd>
The first two links are working fine. I am able to dial a number; but the last line is not working. It seems like disabled. In the mobile, after running, it's showing "Log in to your Mail ID" as a tab but nothing happens when I click it.The web address is not going to the Safari browser.
Please help. how can I integrate this link to Safari browser in iPhone like the first two lines.
Thanks in advance
u have to implement child browser in ur application......https://github.com/purplecabbage/phonegap-plugins/tree/master/iPhone/ChildBrowser
it have a option of opening the link in safari also .....if u have any query plz feel free to ask .....
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.