[Bug] Open in app opens the Chrome browser

[vesta0]

Steps to reproduce

-Open pocket top articles from top sites
-In the browser menu, tap on "open in app"

Expected behavior

Either not seeing an "open in app" option OR opening the Pocket app.

Actual behavior

-Opens the same page in Chrome

Device information

• Android device: Pixel 4
• Fenix version: Nightly 200602 06:01 (Build #21540609)
• Default browser: Fenix nightly

I was able to reproduce this after clearing cache for all 3 apps (Fenix, Chrome, pocket) as well.

UNITO-UNDERSCORE!20200602-115153!
UNITO-UNDERSCORE!20200602-115206!

┆Issue is synchronized with this Jira Task

[rocketsroger]

Nightly with A-C version 45.0.20200604130052 or higher should have this fixed. Please verify.

[abodea]

@rocketsroger I'm still able to reproduce this issue on the latest Nightly from 6/9 with Google Pixel 4 XL (10).
Note that pocket was opened in Chrome.
Build info:
Nightly 200609 06:00 (Build #21610607)
45.0.20200608190110, 8ec16f840
GV: 79.0a1-20200608094842
AS: 60.0.0
Also, if pocket is not installed, the Open in app button is not present (I guess this will be for GPlay redirection).
Removing the QA Needed until further notice.

[rocketsroger]

@abodea Thanks for confirming. One question, what's the STR? I can't reproduce with my device.

[rocketsroger]

@abodea Thanks for confirming. One question, what's the STR? I can't reproduce with my device.

Nevermind. I think I've found a way to reproduce it. Thanks,

[rocketsroger]

Looks like the Pocket app is behaving a little different than other apps. Everything is behaving the same but the resolver comes back for com.ideashower.readitlater.pro/com.pocket.app.PocketUrlHandlerActivity. Launch this activity fails and the first browser picks it up. (in this case Chrome).

[rocketsroger]

Looks like a second start activity was started after pocket.app started

06-11 11:41:28.563 1495 3205 I ActivityTaskManager: START u0 {act=android.intent.action.VIEW cat=[android.intent.category.DEFAULT,android.intent.category.BROWSABLE] dat=https://getpocket.com/... flg=0x10000000 cmp=com.ideashower.readitlater.pro/com.pocket.app.PocketUrlHandlerActivity} from uid 10277
(...unrelated logs removed...)
06-11 11:41:28.592 1495 1570 I ActivityManager: Start proc 22541:com.ideashower.readitlater.pro/u0a249 for activity {com.ideashower.readitlater.pro/com.pocket.app.PocketUrlHandlerActivity}
06-11 11:41:28.594 22541 22541 E readitlater.pr: Not starting debugger since process cannot load the jdwp agent.
06-11 11:41:28.648 22541 22541 I MultiDex: VM with version 2.1.0 has multidex support
06-11 11:41:28.648 22541 22541 I MultiDex: Installing application
06-11 11:41:28.648 22541 22541 I MultiDex: VM has multidex support, MultiDex support library is disabled.
06-11 11:41:28.656 22541 22541 D FirebaseApp: com.google.firebase.auth.FirebaseAuth is not linked. Skipping initialization.
06-11 11:41:28.659 22541 22541 D FirebaseApp: com.google.firebase.crash.FirebaseCrash is not linked. Skipping initialization.
06-11 11:41:28.659 22541 22541 D FirebaseApp: com.google.android.gms.measurement.AppMeasurement is not linked. Skipping initialization.
06-11 11:41:28.659 22541 22541 I FirebaseInitProvider: FirebaseApp initialization successful
06-11 11:41:28.680 22541 22541 W Java7Support: Unable to load JDK7 types (annotations, java.nio.file.Path): no Java7 support added
(...unrelated logs removed...)
06-11 11:41:28.716 22541 22541 D NetworkSecurityConfig: Using Network Security Config from resource network_security_config debugBuild: false
06-11 11:41:28.759 22541 22571 I com.google.b.a.j.z: Provider GmsCore_OpenSSL not available
06-11 11:41:28.809 1495 2957 I ActivityTaskManager: START u0 {act=android.intent.action.VIEW dat=https://getpocket.com/... cmp=org.mozilla.fenix/.IntentReceiverActivity} from uid 10249

[rocketsroger]

During investigation, found a better way to open apps that have a different package name in the target activity. I will open a A-C issue to update it. Won't fix this issue though.

[rocketsroger]

When the latest change is merged. I'll be asking pocket team for help debugging the second part of the issue.

[herbig]

Hey @rocketsroger

We don't currently support opening that url (http://getpocket.com/explore) because the base "explore" feed doesn't appear in the app (only Discover), so the Pocket app forwards the url to the default browser instead.

Explore topics are an example of urls that will work with the Fenix "Open in app" button:

http://getpocket.com/explore/self-improvement

http://getpocket.com/explore/politics

Topics appear in the app as bubbles at the top of the Discover tab, but use the explore feed.

[rocketsroger]

We don't currently support opening that url (http://getpocket.com/explore) because the base "explore" feed doesn't appear in the app (only Discover), so the Pocket app forwards the url to the default browser instead.

@herbig thanks for the confirmation. Looks like the best solution is for Fenix / A-C to add a url blacklist so "Open in app" will not be available for the http://getpocket.com/explore?

[herbig]

@rocketsroger That makes sense. Thank you!

[kbrosnan]

Maybe blacklisting common browsers makes sense? Is there any value in open in app for the browser -> browser use case? Share would be the way for users to open a page with another browser.

[rocketsroger]

Maybe blacklisting common browsers makes sense? Is there any value in open in app for the browser -> browser use case? Share would be the way for users to open a page with another browser.

We already do. A-C detects all browsers and filter them out when sending explicit intents.
https://github.com/mozilla-mobile/android-components/blob/88694edfb7f97e2d5db9c22db5edd5a4eb621621/components/feature/app-links/src/main/java/mozilla/components/feature/app/links/AppLinksUseCases.kt#L70

In this case the intent was opened in a browser because getpocket app rejected the intent causing it to be opened by a browser.

[rocketsroger]

@herbig tested a prototype and found other issues. URL such as https://getpocket.com/explore/item/there-s-a-wire-above-manhattan-that-you-ve-probably-never-noticed should be blacklisted as well.

This means I'll have to add wildcard matching on a code path that is very performance critical. This path is executed every page load and redirect.

[rocketsroger]

Waiting on pocket team investigation result. I'll move this to backlog.

[herbig]

Hey @rocketsroger ! I have a PR opened to address this. The plan is to open the app to Discover, or to the Pocket syndicated article in the Reader. I'll keep you posted when it will go out!

[rocketsroger]

Hey @rocketsroger ! I have a PR opened to address this. The plan is to open the app to Discover, or to the Pocket syndicated article in the Reader. I'll keep you posted when it will go out!

That's great. Thanks for your help!

[rocketsroger]

Confirmed with latest pocket app version 7.31.0.0 this is now fixed. Please confirm, thanks.

[herbig]

Confirmed with latest pocket app version 7.31.0.0 this is now fixed. Please confirm, thanks.

Yep, our fix was released as part of the 7.31.0.0 release!

[abodea]

@rocketsroger if Pocket is not installed please note that the Open In-App button is not present in order to be redirected to the PlayStore for installing it.
This #12746 is one example when the redirection is done to PS even when the app is not installed, it shouldn't be the same for Pocket?
I can verify this issue and open a new one for what I mentioned above.

[rocketsroger]

This #12746 is one example when the redirection is done to PS even when the app is not installed, it shouldn't be the same for Pocket?
I can verify this issue and open a new one for what I mentioned above.

I agree. However, this is a design decision of the site. If the site wants to redirect to an app or to the PlayStore when the app is not installed, they will have to either:

1. Trigger an intent with a targeted package name.
2. Trigger an intent with a market URL fallback.
3. Have a mechanism (similar to Twitter or Reddit) that asks the user to install the app.

However, in pocket's case, it was just a normal redirect to another URL. We'll have to put in a very specific mapping from URL to app in order to figure out which app could be installed with which URL. Unfortunately, this mapping will have to be checked each time any URL is loaded.

I definitely agree that maybe something like 3. can be implemented to move users to the pocket app.

[abodea]

Verified as fixed on the latest Nightly 8/20 with Google Pixel 4 (11) and 7.31.0.0 Pocket version.
I think there is one regression and I added this #13982.

[rocketsroger]

Verified as fixed on the latest Nightly 8/20 with Google Pixel 4 (11) and 7.31.0.0 Pocket version.
I think there is one regression and I added this #13982.

Thanks! I'll take a look at the other one.