906869 - In-browser YouTube shows black blank screen on playback when the YouTube application is not installed or disabled on the device

Status: RESOLVED DUPLICATE of bug 936851

(Firefox for Android Graveyard :: General, defect)

Description

[Karen Rudnitski [:kar]]

STR on my Nexus 4
- disable the youtube app
- go to the youtube site (and served the mobile version)
- click on a youtube video / tap on the video (whatever is popular that day)
- the whole screen goes black

You can exit out of there with the back button.

I thought that we supported in-app youtube playback?

Occurs on GA as well as Nightly.

Comment 1

[Aaron Train [:aaronmt]]

When YouTube is disabled, the application/vnd.youtube content-type is still what we get and it's not handled properly.

I/ActivityManager(  517): START u0 {act=org.mozilla.gecko.PLAY_VIDEO dat=vnd.youtube:Z1s-6-yKzB4?vndapp=youtube_mobile&vndclient=mv-google&vndel=watch&vnddnc=1 flg=0x4000000 cmp=org.mozilla.fennec/org.mozilla.gecko.VideoPlayer} from pid 7154
E/VideoPlayer( 7154): exception
E/VideoPlayer( 7154): android.os.NetworkOnMainThreadException
E/VideoPlayer( 7154): 	at android.os.StrictMode$AndroidBlockGuardPolicy.onNetwork(StrictMode.java:1133)
E/VideoPlayer( 7154): 	at java.net.InetAddress.lookupHostByName(InetAddress.java:385)
E/VideoPlayer( 7154): 	at java.net.InetAddress.getAllByNameImpl(InetAddress.java:236)
E/VideoPlayer( 7154): 	at java.net.InetAddress.getAllByName(InetAddress.java:214)
E/VideoPlayer( 7154): 	at libcore.net.http.HttpConnection.<init>(HttpConnection.java:70)
E/VideoPlayer( 7154): 	at libcore.net.http.HttpConnection.<init>(HttpConnection.java:50)
E/VideoPlayer( 7154): 	at libcore.net.http.HttpConnection$Address.connect(HttpConnection.java:340)
E/VideoPlayer( 7154): 	at libcore.net.http.HttpConnectionPool.get(HttpConnectionPool.java:87)
E/VideoPlayer( 7154): 	at libcore.net.http.HttpConnection.connect(HttpConnection.java:128)
E/VideoPlayer( 7154): 	at libcore.net.http.HttpEngine.openSocketConnection(HttpEngine.java:316)
E/VideoPlayer( 7154): 	at libcore.net.http.HttpEngine.connect(HttpEngine.java:311)
E/VideoPlayer( 7154): 	at libcore.net.http.HttpEngine.sendSocketRequest(HttpEngine.java:290)
E/VideoPlayer( 7154): 	at libcore.net.http.HttpEngine.sendRequest(HttpEngine.java:240)
E/VideoPlayer( 7154): 	at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:282)
E/VideoPlayer( 7154): 	at libcore.net.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:177)
E/VideoPlayer( 7154): 	at org.mozilla.gecko.VideoPlayer.getSpecFromYouTubeVideoID(VideoPlayer.java:58)
E/VideoPlayer( 7154): 	at org.mozilla.gecko.VideoPlayer.onCreate(VideoPlayer.java:42)

Comment 2

[Aaron Train [:aaronmt]]

Chris ported over VideoPlayer from XUL with https://hg.mozilla.org/mozilla-central/rev/8f93de36b3bc but perhaps something changed over time

Comment 3

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

We never really intended to support that VideoPlayer, hence why it is minus. Still should be a good mentor bug and a nice-to-have.

Comment 4

[Sanchit Garg]

HI Brad.
I am a newbiee to it and interested to solve this bug. Please guide me.

Comment 5

[Wesley Johnston (:wesj)]

Brad is on vacation, but I know he said that YouTube had changed their spec recently. I think you could start by adding some debugging code around here: http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/VideoPlayer.java#39

i.e. Import the android.util.Log class and add a line like Log.i("GeckoVideoPlayer", "onCreate: " + data);

See what URL we are passing to the VideoPlayer, and add a bunch of logging in the getSpecFromYouTubeVideoID function as well. Hopefully you can track down where things are moving off track.

Comment 6

[Sanchit Garg]

Thanks.
I will look into it

Comment 7

[Sanchit Garg]

Hey Wesley,
when can I catch up with you on irc? :)

Comment 8

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

(In reply to Sanchit Garg from comment #7)
> Hey Wesley,
> when can I catch up with you on irc? :)

West coast working hours tend to be best

Comment 9

[u490382]

Is this bug still up for grabs? I'm looking for a first bug to work on, and I'd like to take it :)

Comment 12

[Markus Unterwaditzer]

From #947598: You can work around this bug by changing to default Android browser's UA string (by using the Phony extension for example). This makes in-browser playback work.

Comment 13

[usr1000]

(In reply to Markus Unterwaditzer from comment #12)
> From #947598: You can work around this bug by changing to default Android
> browser's UA string (by using the Phony extension for example). This makes
> in-browser playback work.

I have tried this. It does make the video play (with certains UA strings only) but there are still important layout problems. It will not go fullscreen and about a quarter of the video is off-screen. Also, after a few tries only the sound works.

Comment 15

[guigs [:guigs] PST (please needinfo me!)]

Can you elaborate on "hanging to default Android browser's UA string"

Comment 16

[Markus Unterwaditzer]

(In reply to rmcguigan from comment #15)
> Can you elaborate on "hanging to default Android browser's UA string"

Not sure hoe i could elaborate. There are addons out there which allow you to change the user agent of Firefox, and using them to change the user agent to the one the stock browser uses allows you to play the video.

Comment 17

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

Hi Josh, are you still looking into this?

Comment 18

[Icewolf1]

I also have the same problem on a GS4 with CM 10.2.0. In the desktop version of Youtube the playback works. Using other browsers (Opera, the built in one) also works. Tested with the current release and beta version (14.05.2014). The Youtube app is not installed.

Comment 21

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

Bug 936851 has some direction for moving forward.

Comment 22

[Markus Unterwaditzer]

This issue does NOT only occur on the Kindle Fire HDX.

Comment 23

[Aaron Train [:aaronmt]]

(In reply to Markus Unterwaditzer from comment #22)
> This issue does NOT only occur on the Kindle Fire HDX.

Yes, I understand the confusion. We're applying a general fix over in the other bug that's all.