1477649 - video playback aborted due to a network error

Status: RESOLVED INVALID

(Core :: Audio/Video: Playback, defect, P2)

Description

[Djfe]

Attachment: Firefox on Android

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180721100146

Steps to reproduce:

I shared and opened the following link and tried to play the video in Firefox
https://m.facebook.com/story.php?story_fbid=10160509869970702&id=411915920701


Actual results:

The second half of the video is pretty much unplayable. (after 2:35 roughly)

"Video playback aborted due to a network error."
"Abspielen des Videos wegen eines Netzwerkfehlers abgebrochen." in German


Expected results:

I tested this on Firefox on Android (7.0) and Windows 64bit (both current Nightly).
Since the error is happening in both, my guess is that it's in Firefox Core.

I might be wrong though.

The downloaded file plays fine on Firefox for desktop (can't test Android, because it's not possible to use Firefox to play local videos, I think)
Since the download works fine though and ffmpeg doesn't report any issues while remuxing and transcoding, my guess is that the video file is errorfree.

The error is maybe in the network code or in the seeking code related to network.

It happens, when you let it play from start to 2:35 and when seeking directly to the second half of the video.

On Android: When you let it play from start to 2:35 then it keeps on playing till 2:54 with the error message overlaying the playing video.
On Desktop: it plays the file fine till the end then.

Seeking in the first half of the video is problem-free.

This doesn't happen on not-mobile Facebook for the same video

I noticed, that this might be related to buffering, if Firefox Desktop hasn't buffered the second half, then you get the network error, else you don't and can seek fine in the whole video.
Seems like on desktop you have to click directly into the second half of the video to get the bug, else it buffers enough already.
On Android it's more apparent.

Part of this bug:
The error message isn't translated on Android, yet.
The string in Firefox for Desktop:
https://pontoon.mozilla.org/de/firefox/toolkit/chrome/global/videocontrols.dtd/?search=playback+aborted&string=81676
Firefox for Android doesn't have the string, yet. (unlike on desktop it shows up in english in the german apk)

Regards
Djfe

Comment 1

[Djfe]

Attachment: Firefox on Desktop

Comment 2

[Djfe]

I had another try on Firefox for Android (release, where I discovered it first)
This time in fullscreen
I started playing the video and (again) didn't pause or seek ahead.
this time the error showed up, but I think maybe 10 seconds later.
The interesting thing: it didn't stop at 2:54 and kept playing the video fine till the end (4:37), but it showed the error on top of the video the whole time (when it shouldn't have).

That could have been due to a local cache from before, but Firefox kept on buffering during playback according to the timeline below the video, so maybe not?

Comment 3

[Alex Chronopoulos [:achronop]]

Do you have an example that does not require facebook login?

Comment 4

[Djfe]

oh sry, I didn't know that

you don't need to login though to view it.

this is the direct link that works without login. it expires after some time though,so you need to get yourself the new one.
https://video-frt3-1.xx.fbcdn.net/v/t42.9040-2/10000000_574142289648931_227195295987924992_n.mp4?_nc_cat=0&efg=eyJybHIiOjYzMCwicmxhIjoxODIwLCJ2ZW5jb2RlX3RhZyI6InN2ZV9zZCJ9&oh=4d66dec4293ea67327b24551e91ba01c&oe=5B59529F&source=misc&id=10160509869970702&refid=52&__tn__=FH-R

it is generated before you login.

if you open the page, then the preview image/play button is a link.
copy the link's address it should look like this one:
https://m.facebook.com/video_redirect/?src=https%3A%2F%2Fvideo-frt3-1.xx.fbcdn.net%2Fv%2Ft42.9040-2%2F10000000_574142289648931_227195295987924992_n.mp4%3F_nc_cat%3D0%26efg%3DeyJybHIiOjYzMCwicmxhIjoxODIwLCJ2ZW5jb2RlX3RhZyI6InN2ZV9zZCJ9%26oh%3D1a4fb4cac07bd06639eedde71de846c1%26oe%3D5B5960AF&source=misc&id=10160509869970702&refid=52&__tn__=FH-R

delete everything at the beginning till "?src="
only use everything after that, copy it, do an url-encoding decode and open the resulting link.
you can use any online tool for that (this one works: https://www.url-encode-decode.com/ )

I don't know if there are videos that are playable without login (usually) on Facebook.
but this little workaround allows you to test the video that I discovered this issue with.
(after login, Facebook opens the video in a new tab (direct link) anyways -> no html/js involved)

Comment 5

[Andreas Pehrson [:pehrsons]]

I can confirm that seeking into the unbuffered range in the 2nd half often results in a network error while there doesn't seem to be any issues downloading the file.

I'll ni? myself to dig further.

Comment 6

[Andreas Pehrson [:pehrsons]]

I caught this in rr on an opt-build.

The js error comes from ChannelMediaDecoder::NotifyPrincipalChanged(), [1].
mSameOriginMedia is false, and comes from HTMLMediaElement::IsCORSSameOrigin(), set at [2].
It becomes false because ChannelMediaResource::UpdatePrincipal is called with the system principal.
This system principal comes from nsContentUtils::CombineResourcePrincipals(nsCOMPtr<nsIPrincipal>*, nsIPrincipal*) where the principal for origin "https://video.xx.fbcdn.net" gets combined into the old principal for origin "https://video-arn2-1.xx.fbcdn.net".

For me, "https://video.xx.fbcdn.net" and "https://video-arn2-1.xx.fbcdn.net" resolve to the same ipv4 and ipv6 addresses.

GetCurrentSrc() for this media element returns "https://m.facebook.com/video_redirect/?src=https%3A%2F%2Fvideo-arn2-1.xx.fbcdn.net%2Fv%2Ft4(...)"

I assume some redirects are causing this, but don't really know where to continue digging. jya, can you help on progressing this?



[1] https://searchfox.org/mozilla-central/rev/3fa761ade83ed0b8ab463acb057c2cf0b104689e/dom/media/ChannelMediaDecoder.cpp#175
[2] https://searchfox.org/mozilla-central/rev/3fa761ade83ed0b8ab463acb057c2cf0b104689e/dom/html/HTMLMediaElement.cpp#6593

Comment 7

[Jean-Yves Avenard [:jya]]

I'm really not familiar with this part of the code...

Comment 8

[Jean-Yves Avenard [:jya]]

Can you share the rr recording?

Comment 9

[Jean-Yves Avenard [:jya]]

:cpearce that change was introduced with bug 1441153.
Shouldn't we consider URL as same origin when they resolve to the same IP address?

Comment 10

[Jean-Yves Avenard [:jya]]

never mind, can easily reproduce

Comment 11

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Jean-Yves Avenard [:jya] from comment #9)
> :cpearce that change was introduced with bug 1441153.
> Shouldn't we consider URL as same origin when they resolve to the same IP
> address?

IP addresses are often shared between multiple domain names/virtual hosts on the same web server. There's nothing to enforce that the same customer controls all virtual hosts/domain names served at a given IP. So it's a bad idea to consider hosts that resolve to the same IP address as same origin. If you need more convincing, feel free to ask security people. :)

Comment 12

[Jean-Yves Avenard [:jya]]

well Here, not only are the ip matching, but so are the sub-domains. So surely we can assume it’s okay to let one pull the other...

Or maybe there’s something else at play with the redirect...

Comment 13

[Jean-Yves Avenard [:jya]]

We check the CORS headers on the redirect itself. I believe we shouldn't. Only the CORS on the request after the redirection should be checked...

Comment 14

[Jean-Yves Avenard [:jya]]

I can reproduce the problem with chrome.

The redirect doesn't set CORS headers, and they cancel that 2nd request.

So this is an site issue.
Going to raise the issue with facebook so that they add the crossOrigin attribute to their element