I have protocol (like http) with scheme managed with 3rd party App registered in Mac OS X. I.e, x-someapp://someaction or something like that.
How can I open this URL with Google Chrome? By default, Chrome starts searching in Google engine instead launching App and passing URL handling to it...
Safari launches some registered App. And it is right thing.
Firefox and Opera asks what to do... and I can launch App also.
But Chrome... Doesn't ask.
I even tried to write some HTML page with JavaScript inside to send XHttpRequest:
function _httpExecuteCallback() { if (httpRequestCallbackFunction != null) { if (httpRequest.readyState == 4) { if (httpRequest.status == 200) { httpRequestCallbackFunction(); httpRequestCallbackFunction = null; } } } } function _httpGet(url, callbackFunction) { httpRequest = false; httpRequestCallbackFunction = callbackFunction; httpRequest = new XMLHttpRequest(); httpRequest.onreadystatechange = _httpExecuteCallback; httpRequest.open('GET', url, true); httpRequest.send(null); } _httpGet('x-someapp://test',function(){})
No results also...
Custom URL schemes provide a way to reference resources inside your app. Users tapping a custom URL in an email, for example, launch your app in a specified context. Other apps can also trigger your app to launch with specific context data; for example, a photo library app might display a specified image.
In Android 1.0, the Android URI scheme deep linking mechanism was created. It allows the developer to register their app for a URI (uniform resource identifier) in the operating system for a specific device once the app is installed.
The current accepted solution has a problem with Chrome for SSL https. Watching the console log, Chrome blocks the request because it thinks the custom url protocol is not secure:
[blocked] The page at reports blah blah ran insecure content from customproto//blah blah
Here is a solution (this took me a few days to research):
<input type='button' value='Test Custom Url' onclick='exec()'> <script> function submitRequest(buttonId) { var d = (window.parent)?window.parent.document:window.document if (d.getElementById(buttonId) == null || d.getElementById(buttonId) == undefined) return; if (d.getElementById(buttonId).dispatchEvent) { var e = d.createEvent("MouseEvents"); e.initEvent("click", true, true); d.getElementById(buttonId).dispatchEvent(e); } else { d.getElementById(buttonId).click(); } } function exec(){ var d = (window.parent)?window.parent.document:window.document var f = d.getElementById('customUrlLink') if (f ) {f.parentNode.removeChild(f);} var a = d.createElement('a'); a.href = 'mycustomproto://arg1'; a.innerHTML = "Link" a.setAttribute('id', 'customUrlLink'); a.setAttribute("style", "display:none; "); d.body.appendChild(a); submitRequest("customUrlLink"); } </script>
This code will not work for IE. I've found using this technique IE limits the argument of the custom protocol to less than 1000 where as using the iFrame technique IE will allow 2083 chars.
The only way to overcome the url limit in javascript is chuck the data and call multiple times. If anyone wants to take a stab at that, please let me know how it goes. I would like to use it.
To handle long urls in the executing app, pass a token into the app and have it go get the data from a url GET.
So for right now I am using one function for Chrome/FF and another function for IE.
These links helped me develop this solution:
https://superuser.com/questions/655405/custom-protocol-handler-not-working-in-chrome-on-ssl-page
Simulating a click in jQuery/JavaScript on a link
(wish I had known this a few days ago....hope this helps someone)
==================================================
Jake posted a great solution for chrome: https://superuser.com/questions/655405/custom-protocol-handler-not-working-in-chrome-on-ssl-page
This works in chrome only:
window.location.assign("customprotocol://");
It will fail in an iframe so this is working:
var w = (window.parent)?window.parent:window w.location.assign(service + '://' + data)
==================================================
All of the examples of opening the custom protocol, including my own, have a "://" in the url. And this is what is causing the SSL warnings.
Turns out the solution is to change "://" to ":"
so do this:
src="x-myproto:query" .....
and the SSL warnings will go away.
==================================================
This has been working well for chorme. Detect the browser and if chrome do this:
var w = (window.parent)?window.parent:window w.location.assign('myproto://xyzabcdefetc')
For IE and other browsers I do something slightly different.
Note that browsers do impose a limit on how much data you can put in custom url protocol. As long as your string is under 800 chars this seems to be the magic number for which works in all browsers.
It looks like it's Google's locationbar parsing which is getting in the way.
The browser, however, does seem to handle custom URL schemes properly. Try this in your locationbar:
javascript:document.location = 'myscheme://whatever'
Any link on your page that uses the custom scheme should also do the right thing.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With