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

RESOLVED FIXED in Firefox 16

Status

()

P3
enhancement
RESOLVED FIXED
8 years ago
2 years ago

People

(Reporter: mfinkle, Assigned: wesj)

Tracking

(Depends on: 2 bugs, Blocks: 1 bug)

Trunk
Firefox 16
All
Android
Points:
---
Dependency tree / graph
Bug Flags:
in-moztrap +

Firefox Tracking Flags

(blocking-kilimanjaro:-, firefox9-)

Details

(Whiteboard: [qa+] [helperapps], URL)

Attachments

(2 attachments, 1 obsolete attachment)

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.
Severity: normal → enhancement
OS: Linux → Android
Hardware: x86 → All
Priority: -- → P3
Duplicate of this bug: 654621

Updated

7 years ago
Duplicate of this bug: 670658

Updated

7 years ago
tracking-firefox9: --- → ?
Not tracking for Firefox 9.  It's not part of the 9 update.
tracking-firefox9: ? → -
This is still wanted in Native Fennec.
Component: General → General
Product: Fennec → Fennec Native
Duplicate of this bug: 764349

Updated

6 years ago
tracking-fennec: --- → ?

Updated

6 years ago
Duplicate of this bug: 765541
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).
blocking-kilimanjaro: --- → ?

Comment 8

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

Updated

6 years ago
blocking-kilimanjaro: ? → ---
(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

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

Comment 11

6 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
(Assignee)

Updated

6 years ago
Assignee: nobody → wjohnston
(Assignee)

Comment 12

6 years ago
Created attachment 635541 [details] [diff] [review]
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...
Attachment #635541 - Flags: feedback?(mark.finkle)
(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 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= ...
Attachment #635541 - Flags: feedback?(mark.finkle) → feedback+
(Assignee)

Comment 15

6 years ago
Created attachment 635853 [details] [diff] [review]
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.
Attachment #635541 - Attachment is obsolete: true
Attachment #635853 - Flags: review?(mark.finkle)
(Assignee)

Comment 16

6 years ago
Created attachment 635855 [details] [diff] [review]
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.
Attachment #635855 - Flags: review?(blassey.bugs)
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.
Attachment #635853 - Flags: review?(mark.finkle) → review+
Attachment #635855 - Flags: review?(blassey.bugs) → review+
Would the implementation here remove the need to have the YouTube UA hack?
(Assignee)

Comment 20

6 years ago
Yeah it does! But I also managed to remove "Request Desktop Site". Sorry. Fixing....
(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?

Updated

6 years ago
blocking-kilimanjaro: --- → ?
(Assignee)

Comment 22

6 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

Updated

6 years ago
Whiteboard: [qa+]
Adding to mobile QA feature tracking spreadsheet.
Flags: in-moztrap?(fennec)
Backed out: http://hg.mozilla.org/integration/mozilla-inbound/rev/115d48a4ce0c

Looks like you're missing an ending curly brace for the case :)
https://hg.mozilla.org/mozilla-central/rev/a38aeae6134f
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 16
(Assignee)

Comment 27

6 years ago
These were backed out (on both inbound and central)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
(Assignee)

Comment 29

6 years ago
Back in again (tested this time....)

https://hg.mozilla.org/integration/mozilla-inbound/rev/ba54b8464eea
blocking-kilimanjaro: ? → -
https://hg.mozilla.org/mozilla-central/rev/ba54b8464eea
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED

Updated

6 years ago
Depends on: 769247
Depends on: 769454
Depends on: 769322

Updated

6 years ago
Depends on: 772486
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/
Flags: in-moztrap?(fennec) → in-moztrap+

Comment 32

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

Updated

6 years ago
Whiteboard: [qa+] → [qa+] [helperapps]

Comment 33

6 years ago
cape::^[x-]>>[x+]///(1)!
(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
Depends on: 768972
Blocks: 806385

Comment 35

6 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
(Assignee)

Comment 36

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

Comment 37

6 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 ?
tracking-fennec: ? → ---

Comment 38

4 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
(Assignee)

Comment 39

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

Comment 40

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

Comment 41

3 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.
You need to log in before you can comment on or make changes to this bug.