Created attachment 607786 [details]
Unable to Play Video Fennec Native
1. Go to http://studio1290.com/
2. Select an artist
The video should be able to be played in the browser. This is possible to do on the stock browser.
An error is reported indicating that the video is unsupported in the browser (fennec native).
This is not a user-agent sniffing problem, as changing the user agent does not change the layout of the website, the video playing, etc. According to Kevin, sounds like this is an issue about support for video type that the stock browser supports, but not fennec native.
That error message indicates that there was a problem playing the video at the time, not that it is unsupported.
Visiting one of the artist's music videos (e.g., http://studio1290.com/emphatic-put-down-the-drink-studio1290/) reveals a flash embedded video.
I see the plugin container with the "Tap to Play" canvas, but tapping appears to not initialize the player or draw the player. This sounds more like a plugin-container issue maybe?
I can still reproduce this as of 04/11.
This is basically a saved page from desktop Firefox (with js turned off):
That one is working fine in Fennec Native and Fennec XUL.
The http://studio1290.com/ site doesn't work in Fennec Native and Fennec XUL, though. In Fennec Native, I see only a black box, it seems. In Fennec XUL, I see the unsupported video content.
With using the DOM Inspector used in Fennec XUL on desktop, I noticed that this 'unsupported video content' thing is an iframe pointing to this url:
That was with the Android Nexus One UAgent string with Fennec XUL on Desktop.
With the default, I get an update Flash message.
At this point, I'm not sure what is going on at that site.
Oh wait, I've included the styling now in my unminimized testcase and now I can reproduce the issue in Fennec Native, while it works in desktop Firefox.
So it looks like there is some kind of CSS that is causing Fennec Native to not show the Flash object, while it works in desktop Firefox.
I guess it might be some gfx issue then. I'll try to narrow it down tomorrow.
Created attachment 614412 [details]
I haven't been able to get a minimized testcase, but I think the problem that I describe here is basically the same issue:
- Make sure you have at least 2 tabs open, one with this testcase
- Open the testcase
- Open the tab list popup and tap on the tab with the testcase (so you don't really switch tabs)
- Flash circle stays visible
- Flash circle disappears
Tested on the Samsung Galaxy Nexus.
Created attachment 614413 [details]
In this case, you shouldn't see the Flash circle anymore after 500ms.
Margaret - Can you dig a bit into this issue?
(In reply to Aaron Train [:aaronmt] from comment #1)
> I see the plugin container with the "Tap to Play" canvas, but tapping
> appears to not initialize the player or draw the player. This sounds more
> like a plugin-container issue maybe?
This sounds like bug 745016.
With plugins enabled by default, I am still seeing only blackness where there should be a video (both at http://studio1290.com/emphatic-put-down-the-drink-studio1290/ and at http://people.mozilla.org/~mwargers/tests/unminimized/Studio1290.htm). I agree with Martijn that this sounds like some sort of gfx/flash bug.
What blocking assessment is there for this bug?
(In reply to James Willcox (:snorp) (email@example.com) from comment #10)
That sounds like a person with an opinion about whether this should block (or maybe dup to bug 745016?)
This has nothing to do with bug 745016.
Yeah, it doesn't appear to be related to bug 745016.
Marking this a release blocker, at least until we have a clearer understanding of how widespread the problem is likely to be. WDYT, snorp?
Some notes from recent email threads:
- This is a tier 1 application for web apps (also a tier 1 partner)
- The application is pretty much useless without the video issue being fixed on gecko
- Stock browser behavior as of 4/18 still allows the video to play
- Fennec native behavior as of 4/18 still does not allow the video to play
- We do have a contact from Ron to contact the partner directly about this site if we think there's value to contacting them
- Is there value to contacting the partner about this to get more information about the underlying issue?
(In reply to Johnathan Nightingale [:johnath] from comment #15)
> Marking this a release blocker, at least until we have a clearer
> understanding of how widespread the problem is likely to be. WDYT, snorp?
It looks like the plugin gets initialized, but for some reason never gets painted. Won't know more until I look deeper.
I looked at this some more and the plugin is initialized, but nsPluginInstanceOwner::Paint never gets called for some reason. I think we need a layout or maybe gfx person to take a look.
jet, roc: See above, we need some layout/gfx help on tracking this down
A reduced testcase is probably the best first step here
Robert, can you reproduce the issue in comment 6?
(Sorry, I didn't read your earlier comments carefully enough.)
Actually Flash doesn't seem to work in Nightly on my phone at all.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #22)
> (Sorry, I didn't read your earlier comments carefully enough.)
> Actually Flash doesn't seem to work in Nightly on my phone at all.
What's the symptom? Crashes? Doesn't display? Says it's not installed?
What phone is it? What version of Android?
Turns out it's only because I'm an idiot --- I had assumed Flash was preinstalled, but it wasn't.
Now I see the problem described in comment #6.
I notice this is a windowed plugin. That probably means the problem is to do with the way we configure the plugin's Android surface, not nsPluginInstanceOwner::Paint.
Assigning to self to get more info re: the plugin's Android surface.
marking as blocking k9o for tier 1 app compat.
Not blocking the release because studio1290.com is the only site we've heard of with this issue. If more sites crop up during the beta cycle, please re-nom.
I suspect this is also the cause of bug 745152.
Also seeing this on http://www.telegraaf.nl/binnenland/12040352/__Juwelierkillers_gevlucht_naar_Belgi__.html
Appears to be videos served by the Brightcove CDN. Their playback code handles the Flash/HTML5 video switching. I'll need to poke around this some more to see if we're actually getting a Flash SWF here, or are choking on H.264 <video>
Also reaching out to contacts at BrightCove. This is a very popular CDN and raises the priority on this bug.
I posted a reduced test case:
Additional info from BrightCove:
We can't technically support this browser, but if you are getting errors, if you can show them to me I might be able to give you a clue what's going on. The videos are playing for me on my Android in Dolphin.
I have also found issues with some videos on some devices due to codecs. The noted video has two possible renditions, may want to confirm if both play on the device outside our player.
We should fix the simple Flash testcase in comment #6 and hope it fixes this.
Fwiw, I tried getting a minimized testcase out of the site.
WIP here: http://people.mozilla.org/~mwargers/tests/unminimized/Studio1290.htm
But the site had a lot of cruft (which seems to become the norm nowadays), and while trying to minimized, the bug started occuring intermittently.
testcases found on comment 31 and 33
Renomming to up the priority to release blocker.
*** Bug 751705 has been marked as a duplicate of this bug. ***
Jet, what are the next steps here?
We've got multiple bugs here with different symptoms on ICS vs. older Android versions. I'm currently debugging the non-ICS cases.
(In reply to Jet Villegas (:jet) from comment #38)
> We've got multiple bugs here with different symptoms on ICS vs. older
> Android versions. I'm currently debugging the non-ICS cases.
Hi jet, any progress on this issue yet?
This works in the current nightly, inexplicably.
QA, I think some non-mobile change fixed this. We need to figure out if it is still busted in 14 and 15, and if possible find the change that fixed it.
renom'ing. We knocked this off the list because we had no way forward for a fix, which doesn't appear to be true anymore
We don't think this should come back to blocking. We should look into the current situation.
(In reply to James Willcox (:snorp) (firstname.lastname@example.org) from comment #41)
> QA, I think some non-mobile change fixed this. We need to figure out if it
> is still busted in 14 and 15, and if possible find the change that fixed it.
Confirmed this is fixed on the current nightly.
This seems to have been fixed between 2012-06-05 and 2012-06-06:
Maybe fixed by bug 758361?
I tested this with the unminimized testcase http://people.mozilla.org/~mwargers/tests/unminimized/Studio1290.htm , btw.
Bug 758361 is also on Aurora (Fx15). Is this bug fixed on Aurora too?
Confirming that Aurora builds currently have the mysterious fix too. Can we narrow it down more?
Seems to be fixed on Aurora too. I suspect this is bug 758361, but it might just mask this issue.
Testcase2 is still a problem in current trunk build, so I filed bug 763901 for it.
It seems odd to me that bug 758361 would fix (or mask) this issue. Could you confirm by using the inbound builds?
This one is from 43c1e66ef550 and has bug 758361: http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android/1338827223/
This one is from 8a1829c4f00a and does not have bug 758361: http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android/1338826802/
Ok, the bug doesn't seem to be there on http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android/1338827223/ , so I guess something else fixed this bug, somehow.
Hrm, 8a1829c4f00a does show this bug. Are you sure that 8a1829c4f00a does not have bug 758361 and the bug does show in 43c1e66ef550? Isn't it perhaps the other way around? That the fix is in 8a1829c4f00a and that the bug does show in 43c1e66ef550?
Sorry, I guess I explained myself poorly. By "has bug 758361" I really meant that it has the _patch_ for bug 758361, which in fact means it doesn't have bug 758361. Anyway, if you can reproduce the problem on 8a1829c4f00a but not on 43c1e66ef550, then yes, bug 758361 is what fixed it.
Comment on attachment 614413 [details]
Making obsolete since this testcase has now its own bug, bug 763901.
I can still reproduce this issue on http://www.huffingtonpost.com/2012/06/14/gretchen-carlson-walks-of_n_1597206.html
So I guess the issue on http://studio1290.com/ is just masked now by the fix for bug 758361.
Note however, you can also reproduce this on http://studio1290.com/ by following the str in comment 6.
Apparantly Jelly bean works for this site, need to test with ics, gingerbread, froyo.
This seems to work fine on my Galaxy Nexus (Android 4.1). I haven't tested 1290 in a few weeks, just re-tested and the videos are working with tap-to-play working. I initially see a white frame, and then the video loads and is playing.
But this it work with the url and str in comment 55 and comment 6?
Flash isn't supported on B2G.
What is the status of the evangelism efforts here?
Based on comment 1, I wasn't aware that there was any evang effort in this bug.
This is basically a dup of bug 794100. The site uses browser sniffing to white-list a limited number of browsers that get a HTML5 <video>+H.264 experience, all others get Flash (or an error about Flash playing not being available/updated). See follow-up in 794100.
*** This bug has been marked as a duplicate of bug 794100 ***
Many of the videos on the site are now served by YouTube and these work fine. Some are still served through Brightcove, and these do not work on Firefox Android nor Firefox OS smartphones, because of limitations in the old Brightcove "Smartplayer". We should suggest that the site updates their Brightcove scripts. See https://bugzilla.mozilla.org/show_bug.cgi?id=794100#c30 for details.
Currently, one example of a video failing to play can be found by scrolling down a bit on the front page to videos by "Wolf Gang". Of course content can be expected to change over time..
(The URL of that video actually is http://studio1290.com.vip2.535e.blackmesh.com/wolf-gang-back-to-back-studio1290/ )
That video WFM on a Nexus 6 in FF49. Hallvord can you confirm?
Yep, Also WFM.