Google Maps and Here Maps should handle custom intent:// URLs

The URL of the link provided by google is the following:

    intent://maps.google.es/maps?ie=utf-8&gl=es&hq=asai&hnear=0x89e377dcc8eb2895:0x3a2554d859a4317f,Belmont,+Massachusetts,+EE.+UU.&daddr=30+Leonard+Street,+Belmont,+MA+02478,+Estados+Unidos+@42.397019,-71.175960&panel=1&f=d&fb=1&geocode=FVvthgId6PDB-yklxDEUxHfjiTEHpHR0v0IBKQ&cid=2954716220591744007&entry=s#Intent;scheme=http;package=com.google.android.apps.maps;end

It is rather android-specific (because google search mistakenly assumes that the browser is running on android).
We might be able to register an application to handle this kind of link though.

See also bug #1384361.

Marked invalid for webbrowser-app as this should be handled by individual apps (they need to expose custom URL scheme handlers).

Note that I’m unsure whether we already have a mechanism in place to allow webapps that use the webapp-container to expose their custom scheme handlers (and whether intent:// links can be handled separately by different apps depending on the android package they are targetted at).

The documentation for android intent URLs (https://developer.chrome.com/multidevice/android/intents#syntax) specifies that the target app (package) is encoded in the URL fragment identifier. The host is optional, and the path is used to pass extras.

Unfortunately, URL dispatcher (https://wiki.ubuntu.com/URLDispatcher) only allows to filter on domain suffix, not fine-grained regexp matching on the entire URL. This means that as it is today, there is no way to have an app register as a handler for intent URLs that target a specific android package.

An idea that could be explored is to special-case intent:// URLs in URL dispatcher so that they are rewritten with the android package as the host. Given that the host is optional, this would in theory ensure that no important data is lost.

  intent://maps.google.es/[PATH]#Intent;scheme=http;package=com.google.android.apps.maps;end

 would be rewritten:

  intent://com.google.android.apps.maps/[PATH]#Intent;scheme=http;package=com.google.android.apps.maps;end

 thus allowing a maps application to register for such URLs with the following hook:

  [
    {
      "protocol": "intent",
      "domain-suffix": "com.google.android.apps.maps"
    }
  ]

Note that with the above in place (assuming my suggestion is reasonable enough and it gets implemented), there would still be some additional work on a webapp’s side to parse the intent URL and build a suitable http URL from it. The webapp-container executable doesn’t expose such a functionality, it would need to be added. Re-opening the webbrowser-app task to reflect that.

I tested Ted’s branch that implements my suggestion for url-dispatcher on a device, and it works up to the point that clicking on an intent:// link in the browser launches the google maps webapp.

However at this point the app just displays a blank surface because the webview is trying to load an intent:// URL, which it doesn’t know how to handle, so it delegates it to the system (URL dispatcher), which dispatches it to the app again, and so on indefinitely (thus using up CPU, making the app unresponsive and eventually crashing unity8).

So we really need a mechanism in the webapp-container to allow individual webapps to specify a way to rewrite URLs they are invoked with. The google maps webapp would then rewrite the intent:// URL to a https://maps.google.com/* URL.

ok to land but not a prioirty

This bug was fixed in the package url-dispatcher - 0.1+15.04.20150123-0ubuntu1

---------------
url-dispatcher (0.1+15.04.20150123-0ubuntu1) vivid; urgency=low

  [ Ted Gould ]
  * Special handling for intent URLs (LP: #1407709)
 -- Ubuntu daily release <email address hidden> Fri, 23 Jan 2015 15:19:33 +0000

Support for intent URIs in the container is about to land in vivid.

WARNING: apps shouldn’t be updated until the support for intent URIs in the container lands in RTM too!

This bug was fixed in the package webbrowser-app - 0.23+15.04.20150202-0ubuntu1

---------------
webbrowser-app (0.23+15.04.20150202-0ubuntu1) vivid; urgency=medium

  [ CI Train Bot ]
  * Resync trunk

  [ Alexandre Abreu ]
  * Add support for intent:// schemes in the container. (LP: #1407709)

  [ Ubuntu daily release ]
  * New rebuild forced
 -- Ubuntu daily release <email address hidden> Mon, 02 Feb 2015 14:12:39 +0000

All packages landed, including the click app which has been uploaded.
Now the url dispatcher changes can land in RTM, as the last piece of the puzzle.

This bug was fixed in the package url-dispatcher - 0.1+15.04.20150210~rtm-0ubuntu1

---------------
url-dispatcher (0.1+15.04.20150210~rtm-0ubuntu1) 14.09; urgency=medium

  [ Ted Gould ]
  * Special handling for intent URLs (LP: #1407709)

  [ Ubuntu daily release ]
  * New rebuild forced
 -- Ubuntu daily release <email address hidden> Tue, 10 Feb 2015 15:02:55 +0000

This bug was fixed in the package webbrowser-app - 0.23+15.04.20150210~rtm-0ubuntu1

---------------
webbrowser-app (0.23+15.04.20150210~rtm-0ubuntu1) 14.09; urgency=medium

  [ Ubuntu daily release ]
  * New rebuild forced

  [ Alexandre Abreu ]
  * Backport for the intent:// support. (LP: #1407709)
 -- Ubuntu daily release <email address hidden> Tue, 10 Feb 2015 15:01:14 +0000