599636 - Fennec should offer to open YouTube videos in YouTube helper app

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect, P1)

Description

[Brad Lassey [:blassey] (use needinfo?)]

We don't currently support the flash player so can't play YouTube videos in Fennec. Even if we do support flash eventually or YouTube starts serving us HTML5 video we can handle I think we still want to give the user the option of using the YouTube helper app.

Comment 1

[Alex Pakhotin (:alexp)]

How would it look from the UI point of view?
I guess we should do the same as the stock browser: show an image of the video, and just open the player on click. And the option for this should be in the prefs.

What about implementation approach? Should it be a new component, or could we enable nsPhoneSupport for Android and add there a method like this: playYouTubeVideo(in AString url)?

Comment 2

[Brad Lassey [:blassey] (use needinfo?)]

I'm thinking of a more generic solution. Perhaps there should be a button in the site menu for "open this page in another app" and we'll feed the url to the android intent system.

Madhava, what do you think?

Comment 3

[Matt Brubeck (:mbrubeck)]

The Android browser passes *every* URL through the Android intent system.  This means that if you don't have a default browser set, it will prompt you to choose a browser every time you click a link or enter a URL in the search bar.  If the intent matches a filter from another app (like YouTube), that will also cause a prompt.

(This is just for reference; I'm not saying we need to do the same thing.)

Comment 4

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to comment #3)
> The Android browser passes *every* URL through the Android intent system.  This
> means that if you don't have a default browser set, it will prompt you to
> choose a browser every time you click a link or enter a URL in the search bar. 
> If the intent matches a filter from another app (like YouTube), that will also
> cause a prompt.
> 
> (This is just for reference; I'm not saying we need to do the same thing.)

no, we shouldn't. this is the most annoying thing about using the stock android browser imo

Comment 5

[Alex Pakhotin (:alexp)]

(In reply to comment #3)
> The Android browser passes *every* URL through the Android intent system.  This
> means that if you don't have a default browser set, it will prompt you to
> choose a browser every time you click a link or enter a URL in the search bar. 
> If the intent matches a filter from another app (like YouTube), that will also
> cause a prompt.

It's interesting that clicking on a YouTube link in Android browser does not cause a usual prompt, it just opens the player.
On the other hand, if we try top open a YouTube link just through a VIEW intent, it will show a prompt with all the browsers in addition to the YouTube player.
It is possible to open the YouTube player directly, it just requires more specialized handling. We could still have a generic "Open this link in another app" context menu item, but handle YouTube links a special way inside the Java layer.

Comment 6

[Madhava Enros [:madhava]]

I agree we don't want to pass every URL through the "pick your app" system.  Can we add something to the longtap menu for certain types of objects, and then bring up that menu?

Comment 7

[Alex Pakhotin (:alexp)]

As discussed with Brad, until we'll figure out a better solution, the current approach would be to add an item to the site menu, which says "Open Page In Another Application". This will allow the users to open a YouTube page in the YouTube Player, and potentially solve other similar cases.

Madhava, Mark, do you have any comments on this? What should be the exact wording for that menu item?

Comment 8

[Madhava Enros [:madhava]]

Some further discussion in IRC:

blassey: last time we talked about this, we talked about making a generic request for http handlers
blassey: and using that as a baseline
blassey: and only displaying the site menu item if the number of handlers for that site is greater than the generic case
...
blassey: being even more smart about it we could save the names of the handlers and only display it when its different

This seems very reasonable.  We should do this on links, too, so that, for example, you can long-tap on a link to a youtube video and choose "open with YouTube app".

Comment 9

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

(In reply to comment #8)
> Some further discussion in IRC:
> 
> blassey: last time we talked about this, we talked about making a generic
> request for http handlers
> blassey: and using that as a baseline
> blassey: and only displaying the site menu item if the number of handlers for
> that site is greater than the generic case
> ...
> blassey: being even more smart about it we could save the names of the handlers
> and only display it when its different
> 
> This seems very reasonable.  We should do this on links, too, so that, for
> example, you can long-tap on a link to a youtube video and choose "open with
> YouTube app".

Just so I understand. We would ask Android for apps that can handle some generic web page during startup. This would establish the baseline list of external apps that can handle typical URLs.

Then, each time we try to load a URL, we would ask Android for the list of external apps for that specific URL. If the list is different, we would display a popup menu allowing the user to hand off to one of the _different_ external apps.

Sound right?

Comment 10

[Stuart Parmenter]

I would prefer that we keep this out of the site menu.

Comment 11

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

(In reply to comment #10)
> I would prefer that we keep this out of the site menu.

Exactly. My summary assumes we would not use the site menu, or even a context menu, for this feature.

Comment 12

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to comment #9)
> (In reply to comment #8)
> > Some further discussion in IRC:
> > 
> > blassey: last time we talked about this, we talked about making a generic
> > request for http handlers
> > blassey: and using that as a baseline
> > blassey: and only displaying the site menu item if the number of handlers for
> > that site is greater than the generic case
> > ...
> > blassey: being even more smart about it we could save the names of the handlers
> > and only display it when its different
> > 
> > This seems very reasonable.  We should do this on links, too, so that, for
> > example, you can long-tap on a link to a youtube video and choose "open with
> > YouTube app".
> 
> Just so I understand. We would ask Android for apps that can handle some
> generic web page during startup. This would establish the baseline list of
> external apps that can handle typical URLs.
> 
> Then, each time we try to load a URL, we would ask Android for the list of
> external apps for that specific URL. If the list is different, we would display
> a popup menu allowing the user to hand off to one of the _different_ external
> apps.
> 
> Sound right?

No, that's not what has been discussed. I don't think we should be displaying a popup when we load the page. That experience sucks.

So, barring that, where would you put this besides the site menu or context menu?

Comment 13

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

I think the context menu and site menu are problems for discoverability and complexity.

I like the popup approach if we can limit it to a small portion of the web (twitter, gmail, facebook - apps on my phone). The popup approach also allows us to pick the app as the default handler, something I think is important. We can easily add a simple about:handler-apps page to manage the association.

If I think the youtube app is best for viewing a few videos, I'll likely want it set by default. Same with gmail links and facebook links.

The "Share link" and "Open link in App" commands start to get a bit blurry too.

Comment 14

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to comment #13)
> The "Share link" and "Open link in App" commands start to get a bit blurry too.

How?

Comment 15

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

After a longer discussion we decided to implement the baseline approach for determining if an external app can handle a given URL. We also decided to expose this feature using the long-tap context menu.

In order for the front-end code to add the menu item, we'll need a platform API with these methods:
1. for a given URL return a list of app handlers
2. return a list of baseline handlers (these handlers are typically web browsers that can handle typical URLs)
** we might be able to create this list in the front-end by passing a reference HTML URL to #1
3. open a URL in a specific handler app (by name?) 
4. show the OS list of handlers in cases where more than one handler exists and the user must choose
** we could try making this UI ourselves and use #3

thoughts?

Comment 16

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

The front-end needs to add strings to support two modes: single app handler, and multiple app handler:

1. "Open in %S"   where %S would be "YouTube" or "Facebook" or whatever is returned by #1 in the platform API
2. "Open in another app"

Comment 17

[Madhava Enros [:madhava]]

To expand on comments 15 and 16, here's what I'd like to see us do, for now, from the user's perspective.

On any embedded object (i.e. flash video) or link for which there are other apps on the device that could handle it, we should offer, through the long-tap menu, an option to use that other purpose-specific app.  When there is just one other app that can handle the object or link, we should offer access to the app by name.  When there is more than one, so as not to overload the context menu, we can offer to let the user pick from a standard Android app chooser.

In practice, this would look like:

- user finds a link to a youtube video on a webpage, and would like to watch it in the YouTube app
- user long-taps on link
- if the only app installed that can handle the link is the YouTube app, the user sees the option "Open in YouTube app"
- if there are multiple apps that can handle the link, the user sees "Open in another app" -- if the user taps it, he/she gets the android app picker

another scenario:
- user is on a youtube page and wants to open the video in the youtube app instead
- user long-taps on the video
- from here, as in the previous scenario listing

Comment 18

[Madhava Enros [:madhava]]

So, to point this out even more, that first string in comment 16 should be

"Open in %S app", NOT just "Open in $S"


where %S would be "YouTube" or "Facebook" or whatever is returned by #1 in the platform API


(the reason is that, if you're on YouTube (the website), and you see "Open in YouTube" -- what does that even mean?

Comment 19

[Alex Pakhotin (:alexp)]

Attachment: [WIP] "Open Page In Another App" item in the site menu

Just an attempt to use existing services from the site menu.

Comment 20

[Alex Pakhotin (:alexp)]

Attachment: [WIP] "Open Page In Another App" item in the site menu (fixed)

Corrected implementation of the same approach with site menu. Could be used as an example for a more proper fix.

Comment 21

[Alex Pakhotin (:alexp)]

Here is a couple of findings from my investigation of this issue.

1. The platform already supports what was mentioned in the comment 15.
The code in the WIP patch gets, enumerates, and dumps the existing handlers.

2. In my tests on Nexus One there always is just one handler "Android chooser", regardless of the default application selection in the system. The only difference is that if the default is set, the selected app opens the URL right away, if not set, Android displays a list of available applications.
So it seems like if we want to use this approach, we need just a generic string "Open in another app".

Comment 22

[Alex Pakhotin (:alexp)]

Actually after corresponding changes in the platform code, I do get all the handlers. I will prepare another patch.

Comment 23

[Alex Pakhotin (:alexp)]

Attachment: [WIP] "Open Page In Another App" item in the site menu - v3

Updated implementation using the new External URL Handler Service implemented in the bug 613080.
Displays the menu item only if there are other applications added to the list in addition to http protocol handlers.

Comment 24

[Alex Pakhotin (:alexp)]

Attachment: [WIP] "Open Page In Another App" item in the site menu - v4

Updated to accommodate the service interface changes.

Comment 26

[Matt Sturgeon]

how can I get the source, apply a patch, build for Android and install the build?

Comment 27

[Alex Pakhotin (:alexp)]

Thanks to Brad this feature is now available as an add-on: https://addons.mozilla.org/en-US/mobile/addon/270900/

Comment 28

[Matt Sturgeon]

Will this extension be transferred into trunk, instead of addon, at some point?

Comment 29

[Wesley Johnston (:wesj)]

Touch enabled YouTube pages already open the YouTube app for me (well... clicking on the video link does at least). You have use Phony to enable the currently.

Comment 30

[Doug Turner (:dougt)]

what wes said makes the most sense.  We can ask YouTube to serve up the android content to fennec.

Marking WONTFIX

Comment 31

[benicepi]

z