Closed Bug 599636 Opened 10 years ago Closed 10 years ago

Fennec should offer to open YouTube videos in YouTube helper app

Categories

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

All
Android

Tracking

(fennec2.0+)

RESOLVED WONTFIX
Tracking Status
fennec 2.0+ ---

People

(Reporter: blassey, Assigned: alexp)

References

Details

(Whiteboard: [strings][softblocker])

Attachments

(1 file, 3 obsolete files)

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.
tracking-fennec: --- → ?
Flags: in-testsuite?
Flags: in-litmus?
OS: Linux → Android
Hardware: x86_64 → All
tracking-fennec: ? → 2.0+
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)?
Assignee: nobody → alexp
Status: NEW → ASSIGNED
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?
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.)
(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
(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.
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?
Whiteboard: [strings]
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?
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".
(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?
I would prefer that we keep this out of the site menu.
(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.
(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?
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.
(In reply to comment #13)
> The "Share link" and "Open link in App" commands start to get a bit blurry too.

How?
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?
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"
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
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?
Just an attempt to use existing services from the site menu.
Corrected implementation of the same approach with site menu. Could be used as an example for a more proper fix.
Attachment #490307 - Attachment is obsolete: true
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".
Actually after corresponding changes in the platform code, I do get all the handlers. I will prepare another patch.
Depends on: 613080
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.
Attachment #490706 - Attachment is obsolete: true
Updated to accommodate the service interface changes.
Attachment #491380 - Attachment is obsolete: true
Duplicate of this bug: 497944
how can I get the source, apply a patch, build for Android and install the build?
Whiteboard: [strings] → [strings][softblocker]
Thanks to Brad this feature is now available as an add-on: https://addons.mozilla.org/en-US/mobile/addon/270900/
Severity: normal → major
Priority: -- → P1
Will this extension be transferred into trunk, instead of addon, at some point?
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.
what wes said makes the most sense.  We can ask YouTube to serve up the android content to fennec.

Marking WONTFIX
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
z
You need to log in before you can comment on or make changes to this bug.