653833 - Upstream Helper Apps add-on for spawning to Android helper apps from Fennec

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, enhancement, P3)

Description

[Mark Finkle (:mfinkle) (use needinfo?)]

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.

Comment 3

[Christopher Blizzard (:blizzard)]

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

Comment 4

[Matt Brubeck (:mbrubeck)]

This is still wanted in Native Fennec.

Comment 7

[Jason Smith [:jsmith]]

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

Comment 8

[Tony Chung [:tchung]]

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

Comment 9

[Jason Smith [:jsmith]]

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

Comment 10

[Ellie Frost]

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.

Comment 11

[wrbedzinski]

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

Comment 12

[Wesley Johnston (:wesj)]

Attachment: Patch

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

Comment 13

[Mark Finkle (:mfinkle) (use needinfo?)]

(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!

Comment 14

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 15

[Wesley Johnston (:wesj)]

Attachment: Patch

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.

Comment 16

[Wesley Johnston (:wesj)]

Attachment: MimeTypeFix

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.

Comment 17

[Mark Finkle (:mfinkle) (use needinfo?)]

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.

Comment 18

[Wesley Johnston (:wesj)]

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

Comment 19

[Jason Smith [:jsmith]]

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

Comment 20

[Wesley Johnston (:wesj)]

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

Comment 21

[Jason Smith [:jsmith]]

(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?

Comment 22

[Wesley Johnston (:wesj)]

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

Comment 23

[Aaron Train [:aaronmt]]

Adding to mobile QA feature tracking spreadsheet.

Comment 24

[Brian Nicholson (:bnicholson)]

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

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

Comment 25

[Brian Nicholson (:bnicholson)]

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

And this one has an extra brace!

Comment 26

[Ed Morley [:emorley]]

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

Comment 27

[Wesley Johnston (:wesj)]

These were backed out (on both inbound and central)

Comment 28

[Ed Morley [:emorley]]

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.

Comment 29

[Wesley Johnston (:wesj)]

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

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

Comment 30

[Ed Morley [:emorley]]

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

Comment 31

[Adrian Tamas (:AdrianT)]

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/

Comment 32

[wrbedzinski]

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

Comment 33

[wrbedzinski]

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

Comment 34

[Aaron Train [:aaronmt]]

(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

Comment 35

[yannack]

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

Comment 36

[Wesley Johnston (:wesj)]

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.

Comment 37

[yannack]

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 ?

Comment 38

[Daniel Velazco]

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

Comment 39

[Wesley Johnston (:wesj)]

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

Comment 40

[Daniel Velazco]

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

Comment 41

[Steven Willis]

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