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

[Bill Filler]

ubuntu-rtm image 184

The maps apps in the system should register and respond to appropriate urls from the browser (not sure of the format, map:// or directions:// - need to check)

Steps to reproduce:
1) open browser
2) type "Asai Belmont MA" in the url bar and press enter
3) this will do a google search for the resturant
4) click on the "Directions" button

Expected result:
- One of the maps apps should open displaying directions for the resturant

Actual results:
- no app is launched

[Olivier Tilloy (osomon)]

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.

[Olivier Tilloy (osomon)]

See also bug #1384361.

[Olivier Tilloy (osomon)]

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).

[Olivier Tilloy (osomon)]

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"
    }
  ]

[Olivier Tilloy (osomon)]

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.

[Olivier Tilloy (osomon)]

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.

[Pat McGowan (pat-mcgowan)]

ok to land but not a prioirty

[Launchpad Janitor (janitor)]

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

[Olivier Tilloy (osomon)]

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!

[Launchpad Janitor (janitor)]

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

[David Barth (dbarth)]

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.

[Launchpad Janitor (janitor)]

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

[Launchpad Janitor (janitor)]

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