Mark Finkle (:mfinkle) (use needinfo?) Reporter
	Description • 13 years ago

Bug 613080 added toolkit support for opening Android apps to handle registered URL/Mime types. Brad Lassey has an add-on called Helper Apps that exposes that functionality in an unobtrusive way in the UI.

We should work to upstream the add-on so we get built-in support for launching Android apps when appropriate.

	Christopher Blizzard (:blizzard)
	Comment 3 • 13 years ago

Not tracking for Firefox 9.  It's not part of the 9 update.

	Matt Brubeck (:mbrubeck)
	Comment 4 • 12 years ago

This is still wanted in Native Fennec.

	Jason Smith [:jsmith]
	Comment 7 • 12 years ago

k9o nomination - youtube is now serving a mobile site now, but if you go to view a video right now, you get sent to their desktop site. Fixing this bug would be one way to fix this problem to utilize the native youtube app if a video is played on mobile youtube (this is what the stock browser does right now).

	Tony Chung [:tchung]
	Comment 8 • 12 years ago

(In reply to Jason Smith [:jsmith] from comment #7)
> k9o nomination - youtube is now serving a mobile site now, but if you go to
> view a video right now, you get sent to their desktop site. Fixing this bug
> would be one way to fix this problem to utilize the native youtube app if a
> video is played on mobile youtube (this is what the stock browser does right
> now).

Do you actually get routed to the desktop site when trying to playback the video?  If so, we may be okay as long as the video plays automatically.

But according to my testing tapping the play video on the mobile site just refreshes the page.  I have to physically scroll to the bottom and select the "desktop" site, and then get the video to play.

We can't expect users to do the latter.  I filed bug 766855 with a screencast to show my experience.

	Jason Smith [:jsmith]
	Comment 9 • 12 years ago

(In reply to Tony Chung [:tchung] from comment #8)
> (In reply to Jason Smith [:jsmith] from comment #7)
> > k9o nomination - youtube is now serving a mobile site now, but if you go to
> > view a video right now, you get sent to their desktop site. Fixing this bug
> > would be one way to fix this problem to utilize the native youtube app if a
> > video is played on mobile youtube (this is what the stock browser does right
> > now).
> 
> Do you actually get routed to the desktop site when trying to playback the
> video?  If so, we may be okay as long as the video plays automatically.

Originally earlier today, yeah, but we should be utilizing the mobile site here, not the desktop site. Apparently, that's no longer working though per bug 766855.

> 
> But according to my testing tapping the play video on the mobile site just
> refreshes the page.  I have to physically scroll to the bottom and select
> the "desktop" site, and then get the video to play.

Hmm. I'm getting that now too - wasn't getting that before.

	Ellie Frost
	Comment 10 • 12 years ago

The redirecting behaviour is happening for me now as well. I suspect that the user agent wasn't recognised by Google as a mobile browser until recentl.

	wrbedzinski
	Comment 11 • 12 years ago

>>2012/06/21//14:57//<w.r.bedzinski2gmail.com>//http://www.wrbedzinski.bugzilla..mozilla.org//open-001 001>
>cape>///3::4::7//>addon>evry>dupicate>///a>><sign up>automiticaly>last>>//c/comment 9 ^8///<<w.r.bedzin

	Wesley Johnston (:wesj) Assignee
	Comment 12 • 12 years ago

This is 90% of the way there (I think). Shows a doorhanger on pages that have helper apps that says "The Maps App can open this link", buttons that say "Open in App" and "Cancel" and a checkbox for "Remember for this site".

If there is more than one app registered for this link, it says "You have other apps installed that can open this link." In that case it should show an App list, but we're hitting some sort of problem in nsMimeInfoAndroid and sending the wrong Mime type to java. Still digging...

There are also issues where am app can register for a site (say Youtube), the user uses the app, hits back, and we open another YouTube link (either the same one or a different one) which sends them back into the app and they end up in an endless loop.

There's ALSO no good way to revoke these permissions once given. Ideally you'd just go back to the link and bring up Site Permissions, but (heh) you can't go back to the link because we'll just open the App.

Killing the "Remember for this site" bit would be the easy way to fix both those problems...

	Mark Finkle (:mfinkle) (use needinfo?) Reporter
	Comment 13 • 12 years ago

(In reply to Wesley Johnston (:wesj) from comment #12)

> If there is more than one app registered for this link, it says "You have
> other apps installed that can open this link." In that case it should show
> an App list, but we're hitting some sort of problem in nsMimeInfoAndroid and
> sending the wrong Mime type to java. Still digging...

Sounds like we'll need this fixed for landing


> There are also issues where am app can register for a site (say Youtube),
> the user uses the app, hits back, and we open another YouTube link (either
> the same one or a different one) which sends them back into the app and they
> end up in an endless loop.
> 
> There's ALSO no good way to revoke these permissions once given. Ideally
> you'd just go back to the link and bring up Site Permissions, but (heh) you
> can't go back to the link because we'll just open the App.
> 
> Killing the "Remember for this site" bit would be the easy way to fix both
> those problems...

Do it! Better to land a solid patch than a flakey feature. Followups!

	Mark Finkle (:mfinkle) (use needinfo?) Reporter
	Comment 14 • 12 years ago

Comment on attachment 635541 [details] [diff] [review]
Patch

Let's drop the "remember" permission code so we can get this landed sooner with less issues.

>diff --git a/mobile/android/chrome/content/browser.js b/mobile/android/chrome/content/browser.js

>       // Reset showProgress after state change
>       this.showProgress = true;
>+
>+      if (aStateFlags & Ci.nsIWebProgressListener.STATE_IS_NETWORK && aStateFlags & Ci.nsIWebProgressListener.STATE_START) {

I need to think more about using onStateChange as the hook point for this code. Why not "pageload" or some other event?

>+        let self = this;
>+        setTimeout(function() {

Why is the setTimeout needed?

>diff --git a/mobile/android/locales/en-US/chrome/browser.properties b/mobile/android/locales/en-US/chrome/browser.properties
>+helperapps.openInNamed=The %S App can open this link.

helperapps.openWithApp= ...

	Wesley Johnston (:wesj) Assignee
	Comment 15 • 12 years ago

This removes the checkbox, but I think we'll need it back. If the user gets a bad app installed (NextVid wants all YouTube links), it gets very annoying. Mimetype fix is in a separate patch.

I also had to increase the persist value to 2 (from -1). -1 Makes this show up on unrelated pages if you ignored it. 1 doesn't work for YouTube (which redirects us twice!)

The redirects on YouTube also make this kinda crappy with an App like NextVid installed. Both NextVid and the YouTube app try to open the video url so you get the "You have apps installed taht can open this link" prompt. Then YouTube redirects us to a page that only NextVid is registered to handle. Originally that would just hide the prompt. I modified it here so that it now just shows two prompts, which is confusing.

Gr... NextVid is quickly becoming my nemesis.

	Wesley Johnston (:wesj) Assignee
	Comment 16 • 12 years ago

This fixes the MimeType thing. I don't think blassey likes this. Probably need to dig deeper into why its needed, but it is! even with using the preferredApplicationHandler.

	Mark Finkle (:mfinkle) (use needinfo?) Reporter
	Comment 17 • 12 years ago

Comment on attachment 635853 [details] [diff] [review]
Patch

>diff --git a/mobile/android/chrome/content/browser.js b/mobile/android/chrome/content/browser.js
>+        let message = apps.length == 1 ? Strings.browser.formatStringFromName("helperapps.openInNamed", [apps[0].name], 1) :

>diff --git a/mobile/android/locales/en-US/chrome/browser.properties b/mobile/android/locales/en-US/chrome/browser.properties

>+helperapps.openInNamed=The %S App can open this link.

I still like helperapps.openWithApp better

Yes, we'll need to add back the "remember" checkbox when we back solutions for the new problems it causes.

	Wesley Johnston (:wesj) Assignee
	Comment 18 • 12 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/a3f5b011f665
https://hg.mozilla.org/integration/mozilla-inbound/rev/a38aeae6134f

	Jason Smith [:jsmith]
	Comment 19 • 12 years ago

Would the implementation here remove the need to have the YouTube UA hack?

	Wesley Johnston (:wesj) Assignee
	Comment 20 • 12 years ago

Yeah it does! But I also managed to remove "Request Desktop Site". Sorry. Fixing....

	Jason Smith [:jsmith]
	Comment 21 • 12 years ago

(In reply to Wesley Johnston (:wesj) from comment #20)
> Yeah it does! But I also managed to remove "Request Desktop Site". Sorry.
> Fixing....

Okay. Could we get a bug on file to get rid of the YouTube UA hack after this patch is verified with YouTube?

	Wesley Johnston (:wesj) Assignee
	Comment 22 • 12 years ago

The Youtube hack is already removed here. Fennec should say "Open with YouTube App" when you hit their site. If this fix doesn't build right... I'm very VERY sorry, and I'll back everything out. At a meeting where I can't test easily, but I thought this would be fine to land....

Pushed Fix:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5ab2723fc0e0

	Aaron Train [:aaronmt]
	Comment 23 • 12 years ago

Adding to mobile QA feature tracking spreadsheet.

	Brian Nicholson (:bnicholson)
	Comment 24 • 12 years ago

Backed out: http://hg.mozilla.org/integration/mozilla-inbound/rev/115d48a4ce0c

Looks like you're missing an ending curly brace for the case :)

	Brian Nicholson (:bnicholson)
	Comment 25 • 12 years ago

Backed out: http://hg.mozilla.org/integration/mozilla-inbound/rev/fee840205f5b

And this one has an extra brace!

	Ed Morley [:emorley]
	Comment 26 • 12 years ago

https://hg.mozilla.org/mozilla-central/rev/a38aeae6134f

	Wesley Johnston (:wesj) Assignee
	Comment 27 • 12 years ago

These were backed out (on both inbound and central)

	Ed Morley [:emorley]
	Comment 28 • 12 years ago

For clarity, the merge was:

Ignore mimetype for helperapps if it is the same as our url. r=blassey
https://hg.mozilla.org/mozilla-central/rev/a38aeae6134f

Show a doorhanger allowing users to open a page in helper apps. r=mfinkle
https://hg.mozilla.org/mozilla-central/rev/a3f5b011f665
-> Backed out by: https://hg.mozilla.org/mozilla-central/rev/fee840205f5b

Add back some code that should not have been removed. r=mfinkle
https://hg.mozilla.org/mozilla-central/rev/5ab2723fc0e0
-> Backed out by: https://hg.mozilla.org/mozilla-central/rev/115d48a4ce0c

The first part is still landed.

	Wesley Johnston (:wesj) Assignee
	Comment 29 • 12 years ago

Back in again (tested this time....)

https://hg.mozilla.org/integration/mozilla-inbound/rev/ba54b8464eea

	Ed Morley [:emorley]
	Comment 30 • 12 years ago

https://hg.mozilla.org/mozilla-central/rev/ba54b8464eea

	Adrian Tamas (:AdrianT)
	Comment 31 • 12 years ago

Test cases covering helper app scenarios and opening apps from Firefox Mobile:

https://moztrap.mozilla.org/manage/cases/_detail/5583/
https://moztrap.mozilla.org/manage/cases/_detail/5584/
https://moztrap.mozilla.org/manage/cases/_detail/5579/

	wrbedzinski
	Comment 32 • 12 years ago

>>overup>/k//during//cape(+)//try>very//a

	wrbedzinski
	Comment 33 • 12 years ago

cape::^[x-]>>[x+]///(1)!

	Aaron Train [:aaronmt]
	Comment 34 • 12 years ago

(In reply to wrbedzinski from comment #32)
> >>overup>/k//during//cape(+)//try>very//a

(In reply to wrbedzinski from comment #33)
> cape::^[x-]>>[x+]///(1)!

Please take your spam over to the landfill: http://landfill.bugzilla.org

	yannack
	Comment 35 • 11 years ago

Not sure if I am posting this in the right place, but I think it is.
With the wikipedia app installed:
Do a google search, using Firefox for Android, for: wikipedia animal
and click on any of the wikipedia answers that google. This opens the wikipedia page instead of allowing the wikipedia app to start. Long pressing on the link doesn't show anything relevant to the wikipedia app either.
Same thing with YouTube and a search for: youtube animal
Same thing with IMDB and a search for: IMDB Clooney
etc.
Do not hesitate to redirect me to the right bug report if this isn't the proper one.
Thanks

	Wesley Johnston (:wesj) Assignee
	Comment 36 • 11 years ago

Yes. Part of this bug was fixed, but we need to do a bit more to expose this to users in the UI better. There is a bug for that. But that said:

We don't have integration with webapps yet. Some of that will be helped if we switch to a system where webapps are packaged as apks. But we can also (in Fennec) integrate with the webapp database even if we don't have webapps as apks. We should file a new bug for that.

We should implement WebActivities as well. That will give page authors a way to send links to other apps, but is a bit different than this problem. That is bug 825041.

	yannack
	Comment 37 • 11 years ago

Hi, I am not sure what I am talking about is related to either Web Apps or WebActivities. External apps are launched in Chrome and the Android 2.x standard browser directly (clicking on a wikipedia link will prompt to start the wikipedia app, etc). This seems to me like it is a built-in Android concept. What am I missing ?

	Daniel Velazco
	Comment 38 • 10 years ago

This missed adding the ability to use the intent:// anchor links. Every Android browser supports this, including AOSP-based browsers found in the Samsung Galaxy S phones, as well as Chrome.

More info here: https://developer.chrome.com/multidevice/android/intents

	Wesley Johnston (:wesj) Assignee
	Comment 39 • 10 years ago

(In reply to Daniel Velazco from comment #38)
> This missed adding the ability to use the intent:// anchor links. Every
> Android browser supports this, including AOSP-based browsers found in the
> Samsung Galaxy S phones, as well as Chrome.
> 
> More info here: https://developer.chrome.com/multidevice/android/intents

That's bug 851693. We want to protect intent uri's with a prompt of some sort. OTOH, something more likely to be standardized like WebIntents seems like a better tact to take than platform dependent web api's. AFAIK, WebIntents aren't moving anywhere either though.

	Daniel Velazco
	Comment 40 • 10 years ago

Wes, thanks for linking to that, I couldn't find it. And yes, WebIntents are not getting any traction ATP.

	Steven Willis
	Comment 41 • 9 years ago

(In reply to yannack from comment #37)
> Hi, I am not sure what I am talking about is related to either Web Apps or
> WebActivities. External apps are launched in Chrome and the Android 2.x
> standard browser directly (clicking on a wikipedia link will prompt to start
> the wikipedia app, etc). This seems to me like it is a built-in Android
> concept. What am I missing ?

I'm having the same problems as yannack. Specifically the test case given above:

https://moztrap.mozilla.org/manage/cases/_detail/5583/

does not work correctly for me. It just opens the google play store webpage within firefox, I can't get it to open the Google Play app. I'm on Firefox 42.0.2.