[Android] Enable WebAPK to have multiple intent filters

chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkInfo.java

Index: chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkInfo.java
diff --git a/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkInfo.java b/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkInfo.java
index 70892c7c158d756086b6b4cbd4d965f8a015d4ef..ed20ee3d43cedd7bd8860e0a5161fd89cf293cca 100644
--- a/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkInfo.java
+++ b/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkInfo.java
@@ -10,6 +10,7 @@ import android.content.pm.PackageManager;
 import android.content.res.Resources;
 import android.graphics.Bitmap;
 import android.graphics.BitmapFactory;
+import android.net.Uri;
 import android.os.Bundle;
 import android.text.TextUtils;
 
@@ -186,6 +187,17 @@ public class WebApkInfo extends WebappInfo {
             scope = ShortcutHelper.getScopeFromUrl(manifestStartUrl);
         }
 
+        // The WebAPK may have been launched as a result of an intent filter for a different scheme
+        // or top level domain. Rewrite the scheme and host name to the scope's scheme and host
+        // name.

[palmer, 2017/06/28 21:24:40]

This is where the rubber hits the road, right? How do we know at this point in
the code that it's acceptable (to Chrome, to the site(s) in question) to do
these mappings?

[pkotwicz, 2017/06/28 22:26:21]

I think that Yaron was asking whether doing the URL rewriting using
android.net.Uri was equivalent to doing the URL rewriting using
GURL::ReplaceComponents()

The site in question would specify that they want this mapping in the Web
Manifest that their site links to (https://www.w3.org/TR/appmanifest/) The way
that this is specified in the Web Manifest is not spec'ed yet. We won't do any
URL rewriting unless the site explicitly requests it.

It is currently impossible for WebAPKs installed via "Add-to-homescreen" in the
app menu (or any other manner) to have an intent filter different than the
WebAPK scope. We have no plans of changing this.

As an experiment, we want to allow a few first party Google apps to have
associated WebAPKs for which the URL host is rewritten. We will package these
WebAPKs by hand (and are doing the URL rewriting at the explicit request of
those first party apps). More details are at
https://docs.google.com/a/google.com/document/d/1il9QhxNeHEQG-vsgCnWV_f-_8Bmr...

[Yaron, 2017/06/29 02:15:07]

Yes, that was one part. It sounds like it's safe.
The other was whether it should be in the MainActivity of WebApk vs here which I
asked elsewhere.

[Yaron, 2017/07/10 23:39:35]

So playing this out - what happens if you're in a webapk, click a link that's
out of the primary scope but would hit the intent filters? The link click would
run ExternalNavigationHandler, the url would match a secondary intent filter, we
see we're already in the webapk and we wouldn't rewrite it. So urls which would
launch a webapk get rewritten but within it but off the main origin don't. I
don't think it would break but it's a little strange? What do you think?

[pkotwicz, 2017/07/11 14:31:38]

The goal of the URL rewriting is to enable a web app to run within a single top
level domain. This requires cooperation on the part of the web app author.

An option (that I prefer) involves not rewriting top level domains and giving
the web app the responsibility to register a service worker for each likely top
level domain. My understanding is that for a given user there are only two
likely top level domains .country and .com The web app would register a service
worker for likely top level domains via a pagelet. The web app can do this only
the first time that it is launched. One complication is if the webapp wants to
have different behavior when running in a Chrome tab and when running as a
WebAPK. For instance, the webapp may not want to register a service worker when
running in a Chrome tab (each JavaScript byte that the user has to download
makes the page load slower)

[Yaron, 2017/07/12 16:54:01]

Not sure that's really desirable.
So thinking more about this, I'm still wondering it makes more sense to move it
to the webapk. That way it's an impl detail of the WebApk and chrome is
oblivious to it which means you don't have to rationalize it in the context of
chrome. Specifically from chrome's pov, the app lives on a single origin and the
webapk is just rewriting some requests to be included. The previous
justification of scope not being used in the webapk isn't very concerning to me
- we're talking about at most a few hundred bytes and reading a member variable.

+        Uri parsedUrl = Uri.parse(url);
+        Uri parsedScope = Uri.parse(scope);
+        url = parsedUrl.buildUpon()
+                      .scheme(parsedScope.getScheme())
+                      .authority(parsedScope.getAuthority())
+                      .build()
+                      .toString();
+
         return new WebApkInfo(id, url, forceNavigation, scope, primaryIcon, badgeIcon, name,
                 shortName, displayMode, orientation, source, themeColor, backgroundColor,
                 webApkPackageName, shellApkVersion, manifestUrl, manifestStartUrl,