859456 - Pinterest - Not offered choice to handle associated application with intent; unable to launch Google Play to get their native application

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Aaron Train [:aaronmt]]

http://www.pinterest.com; tap the 'Download' button in their Android native app banner

D/Instrumentation(18927): checkStartActivityResult  :Intent { act=android.intent.action.VIEW dat=pinit12://m.pinterest.com/ flg=0x4000000 }
D/Instrumentation(18927): checkStartActivityResult  inent is instance of inent:
I/ApplicationPolicy( 2310): isIntentDisabled start :Intent { act=android.intent.action.VIEW dat=pinit12://m.pinterest.com/ flg=0x4000000 }
I/ApplicationPolicy( 2310): isIntentDisabled resolve info :null
I/ApplicationPolicy( 2310): isIntentDisabled return :false

"Launch Application" dialog yields nothing on tap of OK. Chrome will launch a 'Complete action using' dialog where one can always select Google Play or another handler.

Comment 1

[Aaron Train [:aaronmt]]

This is their deep-linking library: http://passets-ec.pinterest.com/js/deep_linking_eeddde72.js which handles their code.

Comment 2

[Aaron Train [:aaronmt]]

Attachment: Pinterest deeplink.js

Adding it here in-case the URL changes

Comment 3

[Wesley Johnston (:wesj)]

Weird. They load a hidden iframe with the current url and the protocol replaced with pinit12. in onload, they redirect the frame to the app store. i.e.: 

redirectFrame.src = pinit12://m.pinterest.com/;
redirectFrame.onload = function noapp() { window.location=selfRef.android_app_dl_url; };

where android_app_dl_url points to the play store. I guess the pinit12 url should open the native app if its installed and otherwise they want to redirect to the play store, but we throw up at the un-known url (like I'd expect us to) and never call onload. Seems like we're doing things right AFAIK. They're just utilizing a webkit/chrome bug where it calls onload even if pages don't load.

Comment 4

[Aaron Train [:aaronmt]]

I sent them an help request email pointing to this bug.

Comment 5

[Hallvord R. M. Steen [:hallvors]]

Marking sitewait since Aaron already contacted them.

Comment 6

[Lawrence Mandel [:lmandel] (use needinfo)]

Mike - Can you help with this one?

Comment 7

[Mike Taylor [:miketaylr]]

I also just tweeted at a pinterest employee (found from their github org) https://twitter.com/MozWebCompat/status/388676340796256260.

Based on this comment,

//Try to deep link to the mobile app on ios.  Android, send them to
//the app page url.

They know that deep-linking to the app won't work. I wonder if it would be enough to change redirectFrame.src = androidAppURL; to something like redirectFrame.src = "about:blank" so it would work everywhere.

Comment 8

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Lawrence Mandel [:lmandel] from comment #6)
> Mike - Can you help with this one?

Given that there are multiple Mikes on this bug I should have been clearer. Mike Beltzner is the Pinterest product manager and a Mozillian. I'm hoping that he can help push this forward.

Comment 9

[Wesley Johnston (:wesj)]

We need a good solution for this sort of issue on our end too. I've been actively working on web intents which should help (but are pretty mozilla specific). Open to ideas...

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

> Weird. They load a hidden iframe with the current url and the protocol
> replaced with pinit12. in onload, they redirect the frame to the app store.
> i.e.: 

This is a pretty common pattern on iOS, which we likely copied to Android. I'll file an internal task to see this resolved. AIUI, on Android, we should just be able to call the URI pattern and if the app is installed it'll ask us if we want to use Pinterest or a web browser to handle. Is that what you'd expect as well?

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Actually, thinking more on that, if we use the mechanism that I propose, then we'd have to:

 - point the user to something like pinterest.com/getapp
 - if the app is installed, deep linking will handle
 - otherwise it'll load in a browser

But we don't want it to load in a browser (even if there's a redirect) because we actually want the other action to just lead directly to Google Play store.

Any hints as to what you'd recommend, instead?

Comment 12

[Hallvord R. M. Steen [:hallvors]]

Aaron, do we have any good answer to Mike's question?

Comment 13

[Aaron Train [:aaronmt]]

Probably a question for Wes.

Comment 14

[Wesley Johnston (:wesj)]

I think I need to ask bz or someone from the DOM world what's expected here. i.e. given something like:

myIframe.src = "pinit12://m.pinterest.com/";
myIframe.onload = function() { window.location = "market://pinterest.com"; };

should the second onload handler ever fire? Even if it SHOULD, I worry that we'd be leaking private data about installed apps to the web.

Comment 15

[Boris Zbarsky [:bzbarsky]]

> should the second onload handler ever fire?

You mean for the "market://pinterest.com" load?

I'd think not, unless we support the "market" URI scheme and actually load something in the frame.  At least that's what the spec says, last I checked.  See http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigating-across-documents step 10.

Comment 16

[Karl Dubost💡 :karlcow]

Is this still an Evangelism issue or should it be converted or linked to a bug for the platform?

Comment 17

[Hallvord R. M. Steen [:hallvors]]

It seems we have a use case that we only sort-of handle through a hack. We should probably step back and ask ourselves if we want to handle this use case (triggering native apps in a way that lets you know the native app is installed and ran) - and if yes, how.

If we don't have a coding fix for the site, it's not really a tech evang issue IMO.

Comment 18

[Karl Dubost💡 :karlcow]

This is fixed.
We implemented intent: