Closed Bug 881072 Opened 11 years ago Closed 11 years ago

Flash Video (VideoJS Player) doesn't play on vine.co

Categories

(Web Compatibility :: Site Reports, defect)

defect
Not set
normal

Tracking

(firefox23 affected, firefox24- affected, firefox25 affected, firefox26 affected, firefox27 affected, fennec-)

RESOLVED FIXED
Tracking Status
firefox23 --- affected
firefox24 - affected
firefox25 --- affected
firefox26 --- affected
firefox27 --- affected
fennec - ---

People

(Reporter: tech4pwd, Unassigned)

References

()

Details

(Whiteboard: [clientsniff][lib-videojs][sitewait])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20130608 Firefox/24.0 (Nightly/Aurora)
Build ID: 20130608031212

Steps to reproduce:

Vines don't play in the browser.

HTC One X, CyanogenMod 10.1 RC4 (4.2.2), Adobe Flash Player 11.1.115.47, Firefox Nightly (2013-06-06)


Actual results:

Nothing


Expected results:

It should play
OS: Windows 7 → Android
Hardware: x86 → ARM
Reproducible in Chrome and Firefox on Desktop by altering the user-agent to: Mozilla/5.0 (Android; Mobile; rv:23.0) Gecko/23.0 Firefox/23.0

VideoJS Flash Component BrightCove v.3.0.2

Errors: Failed to load resource: the server responded with a status of 403 (Forbidden) 

BrightCove is not detecting our user-agent properly.
See Also: → brightcove
Component: General → Mobile
Product: Firefox for Android → Tech Evangelism
Summary: Video doesn't play on vine.co → Flash Video (VideoJS BrightCove Player) doesn't play on Vine.co
Summary: Flash Video (VideoJS BrightCove Player) doesn't play on Vine.co → Flash Video (VideoJS BrightCove Player) doesn't play on vine.co
Vine.co just gives me a "splash screen" linking to downloadable apps (apple store/google play) on device
Test Case: https://vine.co/v/hKInHPKu59W
Probably best to note that Vine videos aren't working on desktop either.
So vine.co gives us two options: MP4 or Flash video. MP4 is main, Flash is fallback when MP4 isn't supported.

		try{
			return!!u.ma.canPlayType(a.type)
		}
		catch(c){
			return""
		}
on the positive side, it seems like this brightcove version might be doing a little less sniffing than the script running on support.brightcove.com..
Vine.co uses a Brightcove script, but it's slightly different from the script discussed in bug 794100.
https://github.com/videojs/video.js
(It does however basically end up with the same "either-flash-or-H.264" logic)
Don't we support H.264 on all platforms already? I'm unsure about B2G, but essentially it vine.co videos should work on android and especially desktop where both are available.
I could not get Firefox on my FxOS phone to play an MP4 file, although canPlayType says "probably" :-#
AFAIK, B2G relies on the OEM, so it'll depend on the device manufacturer having a license. I know that's the approach taken for Android.
(isn't there some way to detect the real state so that canPlayType() could be more truthful than, say, Mr. Clapper?)
(In reply to Paul [sabret00the] from comment #8)
> Don't we support H.264 on all platforms already? I'm unsure about B2G, but
> essentially it vine.co videos should work on android and especially desktop
> where both are available.

No. AFAIK, h.264 is not supported across all desktop platforms. It is also not completely supported on older versions of Android.

(In reply to Hallvord R. M. Steen from comment #9)
> I could not get Firefox on my FxOS phone to play an MP4 file, although
> canPlayType says "probably" :-#

Last I saw I think that you're on v1.0.1. In v.1.0.1, h.264 content cannot be played in the browser by regular web content. This has been fixed in v1.1.
(In reply to Lawrence Mandel [:lmandel] from comment #12)
> (In reply to Paul [sabret00the] from comment #8)
> > Don't we support H.264 on all platforms already? I'm unsure about B2G, but
> > essentially it vine.co videos should work on android and especially desktop
> > where both are available.
> 
> No. AFAIK, h.264 is not supported across all desktop platforms. It is also
> not completely supported on older versions of Android.

Also worth noting that we also do a number of device and vendor specific blocking due to crashes https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers#On_Android_2
As noted in comments above, this is not an Android-specific issue and this is a regression in Desktop Firefox.

I filed a bug report against vine, using https://support.twitter.com/forms/vine:

> I chose "Android" as the answer to the "What type of device
> are you using to access Vine?" question, but actually
> vine.co is broken on desktop Firefox too.
>
> See https://bugzilla.mozilla.org/show_bug.cgi?id=892976.
> 
> Test case: https://vine.co/v/h5UduuJb0lw
>
> It works in Chrome but not Firefox.
>
> I work at Mozilla. Let me know if you need any help
> (or, better, comment in our bug above). Say hi to
> sayrer (my old boss) for me.
OS: Android → All
Hardware: ARM → All
Video player markup in FxOS 1.1:

<video id="post_html5_api" class="vjs-tech" loop="" preload="auto" autobuffer="" poster="https://v.cdn.vine.co/r/thumbs/2537C4B1-6A5F-4E06-AA79-48200537EAF4-938-000000FA81B9BE1D_1febec90276.0.3.mp4.jpg?versionId=ByCGik3m2M4H0LHf3bKicMJsk.0l.hhb"></video>

and if the script is hacked to believe it runs in Safari/iPhone:

<video src="https://mtc.cdn.vine.co/r/videos/2537C4B1-6A5F-4E06-AA79-48200537EAF4-938-000000FA81B9BE1D_1ed4cb042b2.0.3.mp4?versionId=8KvPOlNZYsUDoRWKSTH_bjx1zzCfYPnK" id="post_html5_api" class="vjs-tech" loop="" preload="auto" autobuffer="" poster="https://v.cdn.vine.co/r/thumbs/2537C4B1-6A5F-4E06-AA79-48200537EAF4-938-000000FA81B9BE1D_1febec90276.0.3.mp4.jpg?versionId=ByCGik3m2M4H0LHf3bKicMJsk.0l.hhb"></video>

Obviously, a VIDEO element with neither src=.. attribute nor <source> element won't play very much.

(The latter markup is the result of hard-coding this to true: u.Cc=/iPhone/i.test(u.G);)

The reason for this seems to be that the code path for if this.features['movingMediaElementInDOM'] is 'true' is untested. Deducing back from obfuscated to original source, it's at this point:
https://github.com/videojs/video.js/blob/92d16d64099b0be5f2c2a3274bb32be0081142c5/src/js/media/html5.js#L75
If we enter the first block, the generated VIDEO element will have a src attribute, if we go to the else part it won't.

(Now, if we get the markup right - and the code running on videojs.com seems to get it right, so it may be an issue with the version Vine is using, loaded from http://vjs.zencdn.net/4.1/video.js) - the video still doesn't actually play. It keeps loading, but never starts. That looks like another bug, on our side this time).
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Brian Smith (:briansmith, was :bsmith@mozilla.com) from comment #14)
> As noted in comments above, this is not an Android-specific issue and this
> is a regression in Desktop Firefox.

(Just to have that clarified: you're saying the site regressed/is broken, not that Firefox regressed/is broken - right?)

> I filed a bug report against vine, using
> https://support.twitter.com/forms/vine:

Thanks :) - tagging [sitewait] in whiteboard - although perhaps we should contact them again about *this* bug? I'll go fill in that form again..

> > I chose "Android" as the answer to the "What type of device
> > are you using to access Vine?" question, but actually
> > vine.co is broken on desktop Firefox too.

It happens to work for me in a desktop Firefox (Fx24) - I've been using the http: URL for testing, but the https: one also works. Bug 892976 seems like a slightly different issue, and per its status should be fixed anyway?

Sent Vine this:

Hi,
I work for Mozilla on web compatibility issues and would like to reach someone on your side to discuss a problem we're seeing.

There is an issue with either video.js or Vine's usage of it that prevents the video from playing under certain conditions. The cause is that the generated VIDEO element has neither src attribute nor SOURCE child element:

<video id="post_html5_api" class="vjs-tech" loop="" preload="auto" autobuffer="" poster="https://v.cdn.vine.co/r/thumbs/609D7B186A986405570452086784_15537d68b5b.3.1.mp4_X.91SFys2EMj8yD_3ptps1LxA3vbQi_OVnvFRhQaiZz0xXo0jprpyo_3RTIyZPJJ.jpg?versionId=gUkKWivxzAwaTGYp61VZJBhtyy1ieEG4"></video>

To reproduce this error in a desktop test environment, you can simply disable Flash in Firefox on desktop and try loading any Vine video like https://vine.co/v/h5UduuJb0lw . If you inspect the generated DOM you'll see the VIDEO element has no content to play. The attempted analysis on https://bugzilla.mozilla.org/show_bug.cgi?id=881072#c15 may help you figure out the problem.

Thank you in advance for any fix or insight your developers can come up with.
Hallvord R. M. Steen
Firefox QA, Site compatibility tester
Summary: Flash Video (VideoJS BrightCove Player) doesn't play on vine.co → Flash Video (VideoJS Player) doesn't play on vine.co
Whiteboard: [clientsniff][lib-videojs][sitewait]
Apparently there's a support article that's being successfully used by users - https://support.mozilla.org/en-US/questions/961627

"You can try to set the media.windows-media-foundation.enabled pref to false on the about:config page to disable the built-in mp4 media player. "
(In reply to Alex Keybl [:akeybl] from comment #17)
> Apparently there's a support article that's being successfully used by users
> - https://support.mozilla.org/en-US/questions/961627
> 
> "You can try to set the media.windows-media-foundation.enabled pref to false
> on the about:config page to disable the built-in mp4 media player. "

I'm actually unsure if this is related - but if it is a different issue it'll likely get conflated with this bug (so worth calling out).
The above URL and recommended workaround is unrelated to Android.
fwiw: On Desktop, I cannot reproduce this on Mac with 24b8 or Nightly.  I can reproduce on Windows8 and XP with 24b8, Nightly, and 22.0.
(In reply to Tracy Walker [:tracy] from comment #20)
> fwiw: On Desktop, I cannot reproduce this on Mac with 24b8 or Nightly.  I
> can reproduce on Windows8 and XP with 24b8, Nightly, and 22.0.

On Firefox 22, did comment 18 fix your issue?
Flags: needinfo?(twalker)
(In reply to Aaron Train [:aaronmt] from comment #19)
> The above URL and recommended workaround is unrelated to Android.

Comment 14 changed affected OSs from Android to All
(In reply to Alex Keybl [:akeybl] from comment #21)
> 
> On Firefox 22, did comment 18 fix your issue?

Setting media.windows-media-foundation.enabled pref to false solves the issue on Fx22 on Win 8. However, it does not solve it on Win XP.
Flags: needinfo?(twalker)
(In reply to Hallvord R. M. Steen from comment #16)
> (In reply to Brian Smith (:briansmith, was :bsmith@mozilla.com) from comment
> #14)
> > As noted in comments above, this is not an Android-specific issue and this
> > is a regression in Desktop Firefox.
> 
> (Just to have that clarified: you're saying the site regressed/is broken,
> not that Firefox regressed/is broken - right?)
> 

?
(In reply to Tracy Walker [:tracy] from comment #25)
> (In reply to Hallvord R. M. Steen from comment #16)
> > (In reply to Brian Smith (:briansmith, was :bsmith@mozilla.com) from comment
> > #14)
> > > As noted in comments above, this is not an Android-specific issue and this
> > > is a regression in Desktop Firefox.
> > 
> > (Just to have that clarified: you're saying the site regressed/is broken,
> > not that Firefox regressed/is broken - right?)
> > 
> 
> ?

I don't know which thing regressed.
Why did this get tracking-'d? This breaks Twitter in a very visible way.
Flags: needinfo?(lsblakk)
Gotcha:

(c=c.source)&&this.b.currentSrc==c.src?a.k("loadstart"):c&&(this.b.src=c.src);

this.b is a <video> element that used to have a <source> child (and preload="auto"). However, for some reason video.js wants to modify the element in various ways, including removing the <source> child and setting a .src attribute on the video element instead. The above line will set the element's .src attribute - but it *won't* do so if element.currentSrc indicates that very video is already playing.

Firefox doesn't reset element.currentSrc to '' if the <source> child whose URL is being used for preloading is removed. Therefore the above approach fails, and .src is never set on the video. (The sniffing issue is a red herring - on some i* products it will not run the above code, hence things will work).
Component: Mobile → DOM
Product: Tech Evangelism → Core
Brian - FF24 was already built and is shipping tomorrow, with nothing in this bug that is actionable yet, there's nothing to track for FF24 - leaving the ? up for 25/26 (and will add 27) as we continue to investigate.
Flags: needinfo?(lsblakk)
What can QA do to address qawanted here?
I guess I've handled the required qa work (not used to using qawanted yet, so I didn't notice or remove it)
Keywords: qawanted
Hallvord, no worries. It's actually my fault for not catching that the keyword was added.  It was verbally brought to my attention. However, once I came in to take a look there was no explanation what was needed for the qawanted request.   That's what I was asking for in comment #32.

lsblakk, has qawanted been addressed per the adding of a reduced testcase or is there more to do?
Needinfo on Chris Double to see whether this issue needs to be fixed by the media team.
tracking-fennec: --- → ?
status-b2g-v1.2: --- → ?
tracking-b2g18: --- → ?
Flags: needinfo?(chris.double)
Needinfo JST to see about a fix from the DOM team.
Flags: needinfo?(jst)
I think the testcase in attachment 803768 [details] has issues per the media element spec. The media resource selection algorithm (what happens when you change source elements) is asynchronous in parts. So making a change then immediately checking 'currentSrc' won't work per spec AFAIK. See:

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#loading-the-media-resource

In particular the 'resource selection algorithm' portion, step 4, that states:

"Asynchronously await a stable state, allowing the task that invoked this algorithm to continue."

While awaiting the stable state the spec notes:

"A synchronous section never mutates the DOM, runs any script, or has any side-effects detectable from another synchronous section, and thus synchronous sections can be run in any order, and cannot spin the event loop."

To actually run the media resource selection algorithm when adding/removing 'source' elements you need to call the 'load()' method. This will then result in the change of 'currentSrc' (asynchronously).

It's possible Vine are also falling into this trap.

With regards to whether desktop can play H.264 it depends on OS and Firefox version. For Android devices it depends on what particular device. I attempt to explain what is support where here:

http://bluishcoder.co.nz/2013/08/21/html-media-support-in-firefox.html
per comment 37, moving back to tech evangelism.

minusing because we don't track evangelism bugs. if it bounces back, please renom
tracking-fennec: ? → -
Component: DOM → Mobile
Product: Core → Tech Evangelism
Are we faithfully implementing the spec while others aren't? Is this issue reproducible in Chrome for Android and Safari for iOS?
Flags: needinfo?(hsteen)
(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #38)
> per comment 37, moving back to tech evangelism.
> 
> minusing because we don't track evangelism bugs. if it bounces back, please
> renom

As noted above several times, desktop Firefox also has issues with vine.co so this shouldn't be in the "Mobile" product. Should we split this bug into two--mobile and desktop?

Also note that this is tracking firefox-25, firefox-26, firefox-27.
Flags: needinfo?(blassey.bugs)
Agree that this isn't mobile specific. However, what's important is that we understand the next step and have an owner. If this is evangelism we will speak with Twitter. I would like confirmation that this is broken in other browsers and that we're not holding fast to a spec that simply isn't implemented in the same way across browsers.
(In reply to Lawrence Mandel [:lmandel] from comment #41)
> Agree that this isn't mobile specific. However, what's important is that we
> understand the next step and have an owner. If this is evangelism we will
> speak with Twitter. I would like confirmation that this is broken in other
> browsers and that we're not holding fast to a spec that simply isn't
> implemented in the same way across browsers.

The page in the URL field of this bug (https://vine.co/v/b3Enwh79mdj) does not work in Firefox Nightly but does work in Chrome and Chrome Canary. I tested it in MSIE 10 and it didn't work in MSIE 10 either. This is all on Windows 7 64-bit.
(In reply to Lawrence Mandel [:lmandel] from comment #41)
> Agree that this isn't mobile specific. However, what's important is that we
> understand the next step and have an owner. If this is evangelism we will
> speak with Twitter. I would like confirmation that this is broken in other
> browsers and that we're not holding fast to a spec that simply isn't
> implemented in the same way across browsers.

The opinion of the media team is that we are compliant to the spec and some browsers may interpret it differently. Our implementation also fits with our stance that we avoid having APIs that introduce race conditions - that is DOM members don't change value during the running of a script due to the effect of other asynchronous algorithms running.
Flags: needinfo?(chris.double)
> I think the testcase in attachment 803768 [details] has issues per the media element spec.

Hm.. I see Gecko isn't in fact consistent with itself - when loading the test case into various (mobile) Firefox versions I get both "pass" and "fail"s, sometimes changing between re-loads in the same instance. (This issue was time-consuming to debug partly because vine.co itself was a bit erratic and sometimes worked for no apparent reason - in other words behaved much like the TC). Even if one of those behaviours is spec-compliant, we do seem to have a bug.

In the test case, we have a <video> element with a <source> child, a <script> element, and a DOMContentLoaded handler. The DOMContentLoaded handler removes the <source> and checks that <video>'s currentSource is empty.

Now, on to the spec analysis. First of all: I find the spec very hard to follow here, I think it intends this:

1) Parser sees VIDEO and SOURCE. Runs "resource selection algorithm"
2) The algorithm pauses mid-way and "awaits a stable state" while control returnes to parser
3) Either the "stable state" happens (when?? Parsing done?) and the algorithm resumes its "synchronous section", or the DOMContentLoaded happens. I'm not entirely sure when the "stable state" occurs relative to the event.

* If DOMContentLoaded runs before the "stable state" and the resource selection algorithm, .currentSrc will be empty and the JS will work. 
* If the resource selection completes before DOMContentLoaded, .currentSrc will not be empty and the JS will fail. 

A bit further tweaking of the TC and testing in the Android stock browser seems to confirm that it does not run the resource selection algorithm until after DOMContentLoaded, evading the problem of whether to unset .currentSrc when a <source> child is removed.

I'm also somewhat confused by the fact that the spec claims synchronous sections never mutate the DOM or do things "observable" from other sync scripts. The synchronous section in the resource selection algorithm sets both networkState and currentSrc, so why (or to what scripts) are those changes not apparent?

I think that the HTML5 spec on these points isn't sufficiently detailed go guarantee an interoperable implementation, as details that script can and will rely on are left dependant on timing and/or the various event loop implementations. If so, this problem should possibly be fixed in the spec.. I suggest a small spec modification saying that currentSrc must be set to the empty string if a corresponding <source> child gets removed?
Flags: needinfo?(hsteen)
(In reply to Brian Smith (:briansmith, was :bsmith@mozilla.com) from comment #42)
> The page in the URL field of this bug (https://vine.co/v/b3Enwh79mdj) does
> not work in Firefox Nightly but does work in Chrome and Chrome Canary. I
> tested it in MSIE 10 and it didn't work in MSIE 10 either. This is all on
> Windows 7 64-bit.

Demonstrating that this issue is present in other browsers like IE makes it much easier to request a fix from Twitter. We should probably confirm that any recommendation that we make to fix this issue works in IE, Chrome, and Safari. (No, this burden should not really be on us but it will make the case for a stronger case for our recommended fix.)
(In reply to Brian Smith (:briansmith, was :bsmith@mozilla.com) from comment #40)
> (In reply to Brad Lassey [:blassey] (use needinfo?) from comment #38)
> > per comment 37, moving back to tech evangelism.
> > 
> > minusing because we don't track evangelism bugs. if it bounces back, please
> > renom
> 
> As noted above several times, desktop Firefox also has issues with vine.co
> so this shouldn't be in the "Mobile" product. Should we split this bug into
> two--mobile and desktop?
> 
> Also note that this is tracking firefox-25, firefox-26, firefox-27.

Brian, agreed, but we don't have an actively managed "Desktop" evangelism component. Nor an "Everything". I suspect we'll get it fixed fastest by keeping it in the mobile component.
Flags: needinfo?(blassey.bugs)
> 1) Parser sees VIDEO and SOURCE. Runs "resource selection algorithm"
> 2) The algorithm pauses mid-way and "awaits a stable state" while control
> returnes to parser
> 3) Either the "stable state" happens (when?? Parsing done?)

Stable states happen between every task in the event loop.


> and the
> algorithm resumes its "synchronous section", or the DOMContentLoaded
> happens. I'm not entirely sure when the "stable state" occurs relative to
> the event.

Since DOMContentLoaded happens in its own task, it cannot ever happen before the stable state, regardless of how fast the parser runs (i.e. even if the parser only uses one task to do the entire parse).


> * If the resource selection completes before DOMContentLoaded, .currentSrc
> will not be empty and the JS will fail. 

Essentially the whole point of the event loop and stable states and so on is to ensure this.


> A bit further tweaking of the TC and testing in the Android stock browser
> seems to confirm that it does not run the resource selection algorithm until
> after DOMContentLoaded, evading the problem of whether to unset .currentSrc
> when a <source> child is removed.

That's a bug.


> I'm also somewhat confused by the fact that the spec claims synchronous
> sections never mutate the DOM or do things "observable" from other sync
> scripts. The synchronous section in the resource selection algorithm sets
> both networkState and currentSrc, so why (or to what scripts) are those
> changes not apparent?

It doesn't say that they don't "do things "observable" from other sync scripts". It says that they don't have "any side-effects detectable from another synchronous section". The setting of those attributes has no effect on other synchronous sections. No scripts ever run during a stable state. The point is that stable state tasks can run in any order or in parallel. (In contrast to microtasks, which have to run in a defined order and can't be run in parallel.)
This is where video.js gets confused:
https://github.com/videojs/video.js-component/blob/a0a900e4c8700a796b5bbfa902233984bc95e77c/video.dev.js#L4511

> you need to call the 'load()' method. This will then result in the change of 'currentSrc' (asynchronously)

So, *even* after calling load() you won't know for the remainder of that thread whether the element has a valid source or not?

Personally I think it's an ugly gotcha of the API to have a state where the video element has a currentSrc but really lacks source data and thus is not actually going to play the content in currentSrc. (At least that's what happens in Gecko - the resource selection algorithm must be triggered again at some point to notice that the element at that point has neither .src nor <source> data, though I'm not sure when it's run again..)
http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#scriptEndTag

Stable state is required to happen when the </script> end tag is parsed, before the script is executed.
At the risk of adding noise to this bug, videos on vine.co are also broken on Windows Vista and up since WMF-based native video playback was enabled in Firefox 21.0. Things may also be broken with the new GStreamer backend for the same reason, but I don't have a system available to test that. Regardless, this affects a large audience.
Following up the discussion on Github I just found what I believe (and hope) is the last missing piece to this mystery puzzle: Vine.co does call .load() on the video, so it's likely the timing of this call relative to the other stuff going on (video.js removing SOURCE children while failing to set .src, resource selection algorithm) that ultimately makes the video fail:

player = videojs('post', { 'children': { 'loadingSpinner': false, 'controlBar': false }}).ready(function () {
		player = this;
		resize();
		this.load();

This might mean we should go back to nag Vine.co and let video.js off the hook - however, it's quite a gotcha, so if video.js could work around it (for example by not removing SOURCE children) I think that would be a good idea..
Video.js issue has a fix on Github now \o/ Hope it will pass testing and get rolled out soon.
Flags: needinfo?(jst)
Video.js 4.2.2 is now available and should fix this issue. I have no way of contacting Vine however, and they're using their own hosted version, so they'll still need to update.

-heff (video.js dev)
This seems to be fixed on vine.co's end now - loading the URL linked in the bug report shows an animation.
\o/
I could play back videos on both Firefox for Android and Firefox OS. Resolving as fixed.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
(In reply to Hallvord R. M. Steen from comment #56)
> \o/
> I could play back videos on both Firefox for Android and Firefox OS.
> Resolving as fixed.

I also verified that this WFM in today's Nightly.
Depends on: 946467
Product: Tech Evangelism → Web Compatibility
Component: Mobile → Site Reports
You need to log in before you can comment on or make changes to this bug.