Closed Bug 777633 Opened 12 years ago Closed 12 years ago

Cannot view a video on mobile youtube on Firefox OS - vnd.youtube is not a registered protocol

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-basecamp:+)

Status:
RESOLVED FIXED
Project Flags:
blocking-basecamp +

People

(Reporter: jsmith, Assigned: fabrice)

References

Details

(Keywords: dogfood, feature, Whiteboard: [LOE:S])

Attachments

(1 file)

patch
5.39 KB, patch
dougt
: review+
Details | Diff | Splinter Review 
Steps:

1. Go to youtube.com on the Firefox OS browser
2. Find a video and play it

Expected:

The video should start playing in html5.

Actual:

An error is thrown indicating that vnd.youtube is not a registered protocol. This is likely since vnd.youtube is the android intent for the youtube app on Android, which does not exist on Firefox OS. We need to come up with a strategy of what we should do on our end and evangelize anything else to youtube that needs to be changed in order to play videos on youtube.
In this special case, I'm actually noming this as a basecamp blocker, even though this is kinda of a evangelism bug, kinda not (as some of this problem is our own side). This problem derives itself heavily from the fact that we are putting "Android" in our user agent, which is likely why were getting vnd.youtube sent to us when viewing a video on Firefox OS. We don't support android activities on Firefox OS, so we can't get this style of content.
blocking-basecamp: --- → ?
Component: Evangelism → General
Product: Firefox for Android → Boot2Gecko
Version: Trunk → unspecified
Actually, in reality, this more likely not an evangelism bug, but instead, a user agent bug.
Depends on: 777710
See related unfortunate hack in place until YouTube sends mobile:

http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#1963

My guess is that B2G would have to do the same.
(In reply to Aaron Train [:aaronmt] from comment #3)
> See related unfortunate hack in place until YouTube sends mobile:
> 
> http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/
> browser.js#1963
> 
> My guess is that B2G would have to do the same.

We shouldn't do hacks here in a permanent sense, unless we are so close to shipping that we need to put something in quickly. We should figure out what we need to evangelize to youtube right now for FF Android & Firefox OS, see the update in place, and move towards backing out that hack.
Before we add hacks, we should check whether fixing bug 777710 fixes this.

Gerv
Lawrence, is this an evangelism bug? The best fix here seems to be to have Youtube fix their site to handle this UA correctly.
It looks like the Firefox OS UA may alleviate this problem since it doesn't include the word "Android":

http://lawrencemandel.com/2012/07/27/mobile-web-compatibility-july-27-2012/
I think YouTube is high enough profile that this bug should block basecamp. Resolution of this issue may be that we work with YouTube to get a fix on their side or that we add a fix/hack on our side. The end result needs to be that users can play YouTube content on Firefox OS.
(In reply to Dietrich Ayala (:dietrich) from comment #6)
> Lawrence, is this an evangelism bug? The best fix here seems to be to have
> Youtube fix their site to handle this UA correctly.

Let me first re-test this after the UA change lands. I'm curious to see what happens to many top sites in general with this new UA.
Keywords: qawanted
QA Contact: jsmith
Fixed by changing the user agent. We're getting a desktop site now for youtube with the new UA. That isn't the best thing in the world to get, but let's take care of that in a separate bug.
Status: NEW → RESOLVED
blocking-basecamp: ? → ---
Closed: 12 years ago
Keywords: qawanted
Resolution: --- → FIXED
Short-term, B2G's UA has "Android" in it (again).

Whatever the UA (suppose the site mis-sniffed us), we should not throw an error at the user about unsupported protocols if we know better. At this point, we know better.

So I suggest fixing this bug without relying on any UA change not to include "Android".

/be
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
blocking-basecamp: --- → ?
This is a pretty obvious P1 blocking-dogfood+ problem.

But not sure about blocking-basecamp.
Keywords: dogfood
Whiteboard: [blocked on input clee]
(In reply to Chris Jones [:cjones] [:warhammer] from comment #12)
> This is a pretty obvious P1 blocking-dogfood+ problem.
> 
> But not sure about blocking-basecamp.

blocking-basecamp determination is simple in this case. Is it a P1 requirement that YouTube work on Firefox OS for our initial launch? If yes, I would assert that this bug blocks until we have an alternate solution.
(In reply to Lawrence Mandel [:lmandel] from comment #13)
> (In reply to Chris Jones [:cjones] [:warhammer] from comment #12)
> > This is a pretty obvious P1 blocking-dogfood+ problem.
> > 
> > But not sure about blocking-basecamp.
> 
> blocking-basecamp determination is simple in this case. Is it a P1
> requirement that YouTube work on Firefox OS for our initial launch? If yes,
> I would assert that this bug blocks until we have an alternate solution.

I agree. For context, we blocked FF Android 1.0 when we couldn't play videos in YouTube. Also, if we're saying blocking dogfooding already, doesn't that automatically make this a blocker anyways?

Chris - Thoughts?
(In reply to Brendan Eich [:brendan] from comment #11)
> Short-term, B2G's UA has "Android" in it (again).
> 
> Whatever the UA (suppose the site mis-sniffed us), we should not throw an
> error at the user about unsupported protocols if we know better. At this
> point, we know better.
> 
> So I suggest fixing this bug without relying on any UA change not to include
> "Android".
> 
> /be

Missed replying to this earlier. Does someone have a reference for the bug where "Android" was added to the B2G UA?

How short term are we talking about? Is this change for testing only? Will we release B2G v1 with the "Android" token in the UA?
(In reply to Lawrence Mandel [:lmandel] from comment #15)
> Missed replying to this earlier. Does someone have a reference for the bug
> where "Android" was added to the B2G UA?

Bug 785647.

> How short term are we talking about? Is this change for testing only? Will
> we release B2G v1 with the "Android" token in the UA?

Magic 8 Ball says: "reply hazy; ask again later". :-|

Gerv
Whiteboard: [blocked on input clee] → [blocked on input Chris Lee]
This is a P1 blocker for Firefox OS.  We need YouTube to work in our browser.  

What are our options today to find a fix here?
blocking-basecamp: ? → +
Whiteboard: [blocked on input Chris Lee]
Our best option is evangelism.  Who can get in touch with the youtube folks?

If we can't move anything on that side, we need to start some pretty tricky hackery on the platform side.
Lawrence, can you be our evangelism contact?
Jet already has a relationship having worked with YouTube for the Fennec release and I hope can help out again here.

We had previously asked them to serve us their mobile site with the Firefox for Android UA. This resulted in videos being unplayable on Firefox for Android as YouTube was serving H.264 content. In response, we put a hack in the browser to serve YouTube the older Firefox for Android UA, which receives the vnd.youtube content. The plan was to go back to YouTube with a suitable request after the release. I don't know that we did. 

We need to have a clear request for YouTube if we are to get a fix from them. Our request should include what we require for YouTube to work on both Firefox for Android and Firefox OS.

mfinkle - Can you please comment on what content we want YouTube to serve for Firefox for Android?

cjones - Am I correct that we want YouTube to serve Firefox OS H.264 content?
(In reply to Lawrence Mandel [:lmandel] from comment #20)
> Jet already has a relationship having worked with YouTube for the Fennec
> release and I hope can help out again here.
> 
> cjones - Am I correct that we want YouTube to serve Firefox OS H.264 content?

We *want* them to serve vp8, but we can handle h.264 in b2g.
(In reply to Lawrence Mandel [:lmandel] from comment #20)

> mfinkle - Can you please comment on what content we want YouTube to serve
> for Firefox for Android?

Until we have h.264 in all supported Android versions Fennec supports, we need to keep the vnd.youtube content. That causes Fennec to spawn out to the youtube player on the device.
The concern with comment 22 is that given we are using the same UA as Fennec today, vnd.youtube content is broken on Firefox OS.  

What options do we have to work around this?
fabrice has a patch that lets us send spoofed UAs per-site.  So b2g can send a completely different UA string to youtube than it does for every other site.  I think that patch uses the same mechanism that fennec uses to get the special content from youtube.

(Yeah, that's horrible and sucky, but so are UA strings.)
That may be our best option until B2G and Fennec can handle the same content. Again, we need a clear request for YouTube. I do not think it is appropriate for us to continue to ask YouTube to change the content that they serve to Firefox as we sort our our mobile story.
Well, the ideal request to youtube would be
 - use media queries in their stylesheets to detect low-resolution screens and enable "mobile" (small screen) optimized content
 - serve vp8 since everyone supports that (except an oddball browser from Cupertino; special-case that one)

Have we tried that ask?
If YouTube can serve all/most of the content in vp8 today than that seems like a reasonable request. If this request requires YouTube to reencode a large chunk of their content I think it is a larger request.
Oh, so we might not have the leverage to get Google to re-encode petabytes of existing content and change their code delivery model to do The Right Thing, which would work today in both android-fennec and b2g.

So I guess the first question that comes to mind is, since comment 20 and comment 22 suggest that youtube changed their configuration to serve the new android-fennec UA basically exactly the content that b2g wants (small-screen optimized, including h.264), but android-fennec had to send a different older UA as a workaround to get the youtube activity, why is b2g still getting the youtube activity?  Is b2g accidentally sending the old android-fennec UA?  When h.264 is well-supported in android-fennec (hard problem!), would sending the unadulterated UA Just Work too?
(In reply to Chris Jones [:cjones] [:warhammer] from comment #28)
> So I guess the first question that comes to mind is, since comment 20 and
> comment 22 suggest that youtube changed their configuration to serve the new
> android-fennec UA basically exactly the content that b2g wants (small-screen
> optimized, including h.264), but android-fennec had to send a different
> older UA as a workaround to get the youtube activity, why is b2g still
> getting the youtube activity?  Is b2g accidentally sending the old
> android-fennec UA?  When h.264 is well-supported in android-fennec (hard
> problem!), would sending the unadulterated UA Just Work too?

I confirmed with blassey that we asked YouTube to send the vnd content to our standard Fennec UA. 

If we are already considering sending a different (let's say custom) UA to YouTube using a white list, I suggest that we send the Android stock UA temporarily to get the content that B2G requires.
That's unfortunate.

Sending the android stock UA is an option, but we need to be careful that it doesn't include unsupported webkit-isms or also just deliver the youtube app activity.

Have we tried seeing if it's possible for the youtube code to respect video.canPlayType(), and redirect to the vnd URI if not?  That's a path to forwards compatibility with h.264-enabled android-fennec, too.
That sounds like a clear request to me. I like that it should work moving forward as well. Are we looking too far ahead to consider how our request will impact Firefox on other mobile platforms like Windows?
(In reply to Chris Jones [:cjones] [:warhammer] from comment #30)
> That's unfortunate.
> 
> Sending the android stock UA is an option, but we need to be careful that it
> doesn't include unsupported webkit-isms or also just deliver the youtube app
> activity.
> 
> Have we tried seeing if it's possible for the youtube code to respect
> video.canPlayType(), and redirect to the vnd URI if not?  That's a path to
> forwards compatibility with h.264-enabled android-fennec, too.

Agree with lmandel - this is probably the best route to go. Suggest YouTube to use h264 if available, fallback to the Android intent if it's unavailable. That would solve the problem of allowing YouTube to work on Firefox OS and FF Android.
We could (alternatively) fix up helper apps to work better here.
Oh wait, dang it. That will work for Firefox on Android. Not Firefox OS.
Another alternative is to create a YouTube web app that handles vnd.youtube. This is basically what we did for the Kindle Fire, which has no YouTube app by default.

https://mxr.mozilla.org/mozilla-central/source/embedding/android/VideoPlayer.java
(In reply to Brad Lassey [:blassey] from comment #35)
> Another alternative is to create a YouTube web app that handles vnd.youtube.
> This is basically what we did for the Kindle Fire, which has no YouTube app
> by default.
> 
> https://mxr.mozilla.org/mozilla-central/source/embedding/android/VideoPlayer.
> java

Hmm, that's an interesting idea. Could we do something like this with the Gaia video app?
I am working on both the bug to have the gaia browser fire activities for unrecognised urls and on the gaia video app, so I will take a look at if I can get youtube links working in the Video app
Fabrice says he has a patch.
Assignee: nobody → fabrice
Keywords: feature
Attached patch patch — — Splinter Review 
This patch adds a protocol handler for vnd.youtube: urls and redirect them to a "view" activity.

Tested with this gaia PR: https://github.com/mozilla-b2g/gaia/pull/4656

Enjoy!
Whiteboard: [LOE:S]
Who could review this patch?
Attachment #660562 - Flags: review?(doug.turner)
Comment on attachment 660562 [details] [diff] [review]
patch

Review of attachment 660562 [details] [diff] [review]:
-----------------------------------------------------------------

with comments and questions addressed.

::: b2g/components/YoutubeProtocolHandler.js
@@ +46,5 @@
> +    let uri = Cc["@mozilla.org/network/standard-url;1"]
> +              .createInstance(Ci.nsIStandardURL);
> +    let id = aSpec.substring(this.scheme.length + 1);
> +    id = id.substring(0, id.indexOf('?'));
> +    uri.init(Ci.nsIStandardURL.URLTYPE_STANDARD, -1, this.scheme + "://dummy_host/" + id, aOriginCharset,

why dummy_host?

@@ +54,5 @@
> +
> +  newChannel: function yt_phNewChannel(aURI) {
> +    // Get a list of streams for this video id.
> +    let infoURI = "http://www.youtube.com/get_video_info?&video_id=" +
> +                  aURI.path.substring(1);

substring(1) skips over the '/' char?

@@ +60,5 @@
> +    let xhr = Cc["@mozilla.org/xmlextras/xmlhttprequest;1"]
> +                .createInstance(Ci.nsIXMLHttpRequest);
> +    xhr.open("GET", infoURI, true);
> +    xhr.addEventListener("load", function() {
> +      let key = "url_encoded_fmt_stream_map=";

Might be a good idea to comment about the format of the response.  I am guessing here what it should look like based on your code.

@@ +72,5 @@
> +      let mimeType;
> +
> +      // Recognized mime types, ordered from the less usable to the most usable.
> +      let recognizedTypes = ["video/webm"];
> +#ifdef MOZ_WIDGET_GONK

Isn't there a better #define yet?

@@ +76,5 @@
> +#ifdef MOZ_WIDGET_GONK
> +      recognizedTypes.push("video/mp4");
> +#endif
> +
> +      let bestType = -1;

Why do you need bestType?  Just make recognizedTypes have a priory sort to it.

@@ +100,5 @@
> +      }
> +    });
> +    xhr.send(null);
> +
> +    throw Components.results.NS_ERROR_NOT_IMPLEMENTED;

I am sure you want a different error code, or a comment explain that you are abusing NS_ERROR_NOT_IMPLEMENTED. :)
Attachment #660562 - Flags: review?(doug.turner) → review+
(In reply to Doug Turner (:dougt) from comment #41)

> ::: b2g/components/YoutubeProtocolHandler.js
> @@ +46,5 @@
> > +    let uri = Cc["@mozilla.org/network/standard-url;1"]
> > +              .createInstance(Ci.nsIStandardURL);
> > +    let id = aSpec.substring(this.scheme.length + 1);
> > +    id = id.substring(0, id.indexOf('?'));
> > +    uri.init(Ci.nsIStandardURL.URLTYPE_STANDARD, -1, this.scheme + "://dummy_host/" + id, aOriginCharset,
> 
> why dummy_host?

Because if I keep a vnd.youtube:ID format, the uri parsing code thinks that ID is the host name and normalize it to lowercase, and then the call to /get_video_info fails.

> @@ +54,5 @@
> > +
> > +  newChannel: function yt_phNewChannel(aURI) {
> > +    // Get a list of streams for this video id.
> > +    let infoURI = "http://www.youtube.com/get_video_info?&video_id=" +
> > +                  aURI.path.substring(1);
> 
> substring(1) skips over the '/' char?

yes

> @@ +60,5 @@
> > +    let xhr = Cc["@mozilla.org/xmlextras/xmlhttprequest;1"]
> > +                .createInstance(Ci.nsIXMLHttpRequest);
> > +    xhr.open("GET", infoURI, true);
> > +    xhr.addEventListener("load", function() {
> > +      let key = "url_encoded_fmt_stream_map=";
> 
> Might be a good idea to comment about the format of the response.  I am
> guessing here what it should look like based on your code.

Will do. But be warned, it's kind of ugly.
 
> @@ +72,5 @@
> > +      let mimeType;
> > +
> > +      // Recognized mime types, ordered from the less usable to the most usable.
> > +      let recognizedTypes = ["video/webm"];
> > +#ifdef MOZ_WIDGET_GONK
> 
> Isn't there a better #define yet?

I don't think so, unfortunately.

> @@ +76,5 @@
> > +#ifdef MOZ_WIDGET_GONK
> > +      recognizedTypes.push("video/mp4");
> > +#endif
> > +
> > +      let bestType = -1;
> 
> Why do you need bestType?  Just make recognizedTypes have a priory sort to
> it.
> 

I'm not sure what you mean there. I need to keep track of current best type we encounter while iterating over the list of streams we have.

> > +
> > +    throw Components.results.NS_ERROR_NOT_IMPLEMENTED;
> 
> I am sure you want a different error code, or a comment explain that you are
> abusing NS_ERROR_NOT_IMPLEMENTED. :)

Sure, which error code should I use instead?
Keywords: verifyme
https://hg.mozilla.org/mozilla-central/rev/27b51b9e9e83
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Tried this with two different youtube videos on m.youtube.com - no luck. What video were you successful in testing it with?
Keywords: verifyme
Whiteboard: [LOE:S] → [LOE:S], [qa verification failed]
It requires a custom UA sent to m.youtube.com

add user_pref("general.useragent.override","Mozilla/5.0 (Android; Mobile; rv:17.0) Gecko/17.0 Firefox/17.0");

in custom-prefs.js
Keywords: verifyme
Whiteboard: [LOE:S], [qa verification failed] → [LOE:S],
(In reply to dale@arandomurl.com from comment #46)
> It requires a custom UA sent to m.youtube.com
> 
> add user_pref("general.useragent.override","Mozilla/5.0 (Android; Mobile;
> rv:17.0) Gecko/17.0 Firefox/17.0");
> 
> in custom-prefs.js

Why would you need to overwrite the user agent? The user agent on FF OS right now has Android in the user agent, so we shouldn't have to override it.

We're sending the right user agent here, as I'm getting the right Android site served and seeing the vnd.youtube is not registered protocol error being generated.
Keywords: verifyme
Whiteboard: [LOE:S], → [LOE:S], [qa verification failed]
Dale, did you push the gaia support?
(In reply to Fabrice Desré [:fabrice] from comment #48)
> Dale, did you push the gaia support?

Oh wait, duh. https://github.com/mozilla-b2g/gaia/pull/4671 is still open, so it hasn't landed on Gaia. My mistake.
Whiteboard: [LOE:S], [qa verification failed] → [LOE:S], [qa verification blocked]
Sorry that was my bad, will push first thing in the morning, I wanted to get last of the video issues in at the same time.
Whiteboard: [LOE:S], [qa verification blocked] → [LOE:S]
On Firefox OS Simulator, this is triggering the "This link needs to be opened" open dialog, while it should give the HTML5 video, like on the device. No idea why that is happening. See bug 877594.
Fabrice, I'm confused. Your patch seems to have the intent on opening an external video player (or dialog with choices of video players), when tapping on the video on the Youtube site in the browser app. Is that right?
That is not happening currently.
Instead, the video is played in the browser.

I also tried to use vnd.youtube: protocol to activate this "view" activity:
http://people.mozilla.org/~mwargers/tests/dom/protocol/protocol_in_frame.html
Flags: needinfo?(fabrice)
Youtube used to send us vnd.youtube links but it's not the case anymore, so I don't think we need to worry about that at all. If anything, we should now remove our custom protocol handler.
Flags: needinfo?(fabrice)
(In reply to Fabrice Desré [:fabrice] from comment #53)
> Youtube used to send us vnd.youtube links but it's not the case anymore, so
> I don't think we need to worry about that at all. If anything, we should now
> remove our custom protocol handler.

I filed bug 1085270 about removing the custom protocol handler.
Youtube is still sending vnd.youtube links, afaik. On b2g desktop, and application launch dialog gets opened (no idea why it is an external launch dialog or how it gets invoked).
I haven't been able to invoke any dialogs on b2g desktop or device at all with http://people.mozilla.org/~mwargers/tests/dom/protocol/protocol_in_frame.html , while on Android this opens the Youtube site just fine.
Depends on: 1085270
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: