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

Bug #1407709 reported by Bill Filler on 2015-01-05
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical System Image
Medium
David Barth
The Webapps-core project
High
David Barth
webbrowser-app
Fix Released
High
Alexandre Abreu
url-dispatcher (Ubuntu)
Undecided
Ted Gould
url-dispatcher (Ubuntu RTM)
Undecided
Ted Gould
webbrowser-app (Ubuntu)
High
Unassigned
webbrowser-app (Ubuntu RTM)
High
Unassigned

Bug Description

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

Related branches

Bill Filler (bfiller) on 2015-01-05
Changed in webbrowser-app:
assignee: nobody → Alexandre Abreu (abreu-alexandre)
Changed in webbrowser-app (Ubuntu):
importance: Undecided → High
Changed in webbrowser-app:
importance: Undecided → High
Changed in webbrowser-app (Ubuntu RTM):
importance: Undecided → High
tags: added: ww03
Olivier Tilloy (osomon) wrote :

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) wrote :

See also bug #1384361.

Changed in webbrowser-app:
status: New → Invalid
Changed in webbrowser-app (Ubuntu):
status: New → Invalid
Changed in webbrowser-app (Ubuntu RTM):
status: New → Invalid
Olivier Tilloy (osomon) wrote :

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

summary: - Google Maps and Here Maps should respond to map urls
+ Google Maps and Here Maps should handle custom intent:// URLs
Olivier Tilloy (osomon) wrote :

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) wrote :

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.

Changed in webbrowser-app:
status: Invalid → Confirmed
status: Confirmed → New
Ted Gould (ted) on 2015-01-09
Changed in url-dispatcher (Ubuntu):
status: New → In Progress
Changed in url-dispatcher (Ubuntu RTM):
status: New → In Progress
Changed in url-dispatcher (Ubuntu):
assignee: nobody → Ted Gould (ted)
Changed in url-dispatcher (Ubuntu RTM):
assignee: nobody → Ted Gould (ted)
Olivier Tilloy (osomon) wrote :

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.

no longer affects: url-dispatcher
Changed in webbrowser-app:
status: New → Confirmed
Changed in webbrowser-app (Ubuntu):
status: Invalid → Confirmed
Changed in webbrowser-app (Ubuntu RTM):
status: Invalid → Confirmed
Changed in webbrowser-app:
status: Confirmed → In Progress
Changed in webapps-core:
assignee: nobody → Olivier Tilloy (osomon)
status: New → In Progress
importance: Undecided → High
Bill Filler (bfiller) on 2015-01-17
tags: added: ww05
removed: ww03
Pat McGowan (pat-mcgowan) wrote :

ok to land but not a prioirty

Changed in canonical-devices-system-image:
importance: Undecided → Medium
milestone: none → ww05-2015
status: New → Confirmed
Launchpad Janitor (janitor) wrote :

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

Changed in url-dispatcher (Ubuntu):
status: In Progress → Fix Released
Changed in canonical-devices-system-image:
status: Confirmed → In Progress
Bill Filler (bfiller) on 2015-01-27
tags: added: ww07
removed: ww05
Changed in canonical-devices-system-image:
milestone: ww05-2015 → ww07-2015
Olivier Tilloy (osomon) on 2015-02-02
Changed in webbrowser-app (Ubuntu):
status: Confirmed → In Progress
Olivier Tilloy (osomon) wrote :

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) wrote :

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

Changed in webbrowser-app (Ubuntu):
status: In Progress → Fix Released
Olivier Tilloy (osomon) on 2015-02-03
Changed in webbrowser-app:
status: In Progress → Fix Released
Changed in webbrowser-app (Ubuntu RTM):
status: Confirmed → In Progress
David Barth (dbarth) on 2015-02-05
Changed in webapps-core:
status: In Progress → Fix Released
assignee: Olivier Tilloy (osomon) → David Barth (dbarth)
David Barth (dbarth) wrote :

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.

Changed in canonical-devices-system-image:
assignee: nobody → David Barth (dbarth)
milestone: ww07-2015 → ww09-2015
Launchpad Janitor (janitor) wrote :

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

Changed in url-dispatcher (Ubuntu RTM):
status: In Progress → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in webbrowser-app (Ubuntu RTM):
status: In Progress → Fix Released
Changed in canonical-devices-system-image:
milestone: ww09-2015 → ww13-ota
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers