1566572 - m.facebook.com - Error message displayed after forward seeking the video

Status: RESOLVED WORKSFORME

(Core :: Audio/Video, defect, P3)

Description

[Adam Stevenson [:adamopenweb]]

Attachment: Screenshot

Originally reported: https://github.com/webcompat/web-bugs/issues/33809

URL: https://m.facebook.com/

Browser / Version: Firefox Mobile 68.0
Operating System: Android
Tested Another Browser: Yes

Problem type: Video or audio doesn't play
Description: When I skip the video it shows video playback aborted due to network error
Steps to Reproduce:
When I play any of the video when length of the video is greater than 3 or 4 mins in Facebook.

Steps to reproduce:
-Open facebook
-Play any video that is greater than 3 or 4 mins
-Seek the video to the some extent like to 3 min immediately once the video play is started.
-it will show video playback aborted due to network error.

I think the when we seek the video to unbuffered area it is throwing the error.

Device used: one plus 3

Comment 1

[Nils Ohlmeier [:drno]]

I'm assuming we broke something here recently and regressed.

Comment 2

[Adam Stevenson [:adamopenweb]]

Forgot to add that this reproduces in Fennec and Fenix.

Comment 3

[Alastor Wu [:alwu]]

This issue is not 100% reproduceable for me, but when I reproduced this issue, I saw a following error message,

D/MediaDecoder ChannelMediaDecoder[0x7c0872f000] ChannnelMediaDecoder prohibited cross origin redirect blocked.

That message is from [1], but interesting thing is that, we didn't set this pref media.block-midflight-redirects in our code, not in all.js, mobile.js or staticPrefs. So it's a mystery for me how we ended up to show this error message.

It seems like when we access the media source from CDN, sometime it would redirecrt us to other different servers which violate CORS policy, but Chrome [2] didn't block this behavior, so we should also allow it by default.

In addition, when I succeeded to reproduce this issue, I can see it on both 68 (Fennec and Fenix) to 71 (Fenix).

[1] https://searchfox.org/mozilla-central/rev/053579099d936e26393ac10b809b14fb5841c0f0/dom/media/ChannelMediaDecoder.cpp#141-148
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=532569

Comment 4

[Alastor Wu [:alwu]]

Attachment: Bug 1566572 - use static pref for 'media.block-midflight-redirects'.

It's interesting that we didn't set this pref in any place in our code, don't know if anyone unexpectedly remove this pref or not.

As Chrome won't block CROS redirect for media playback during playing, so we should also not block this behavior.

Therefore, the default value of this pref would be false.

Comment 5

[Alastor Wu [:alwu]]

After investigating this issue further, I'm going to update what I found here.

---

First, this issue was a regression, which is caused by bug1443942, in which we blocked mid-flight redirect since Fx61. However, sometimes FB does that during video playback on its mobile version website.

According to the comment [1],

Most media CDNs do dynamic load balancing by spewing users across many servers. This traffic spewing is usually intelligent, but almost always non-deterministic; the necessary state to map users consistently to the same node in a way that was also traffic-fair is too big.

I don't know how many media CDNs in the wild are working on this way, but I indeed found out that the mobile version FB sometime rediects us to different origin to access media resource when seeking occurs. From [2], we can see that server response 302 status code with new location refering to video.xx.fbcdn.net to our request to old location video-sea1-1.xx.fbcdn.net. And then requesting new data [3] from the new location.

However, we have blocked all types of mid-flight redirect in bug1443942, and the initial reason, which drove us to do that, is to prevent content length leaking from WAV file in bug1441153.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=532569
[2] https://drive.google.com/file/d/1SUtk7XJ20Ah2iSCrsEelVge51MC4uiVm/view?usp=sharing
[3] https://drive.google.com/file/d/1QEvsYlX8tOoByQ_T5e0T2LtSYF_5w9ma/view?usp=sharing

---

Second, let's see if this whole process follows the current spec, is it proper to block the mid-flight redirect based on the spec perspective?

First, every time when we fetch media data, we would check media element's crossorigin attribute to decide what kinds of request we should send, [4] and the request mode would be no-cors by default [5]. Therefore, from the spec's perspective, it seems that the spec doesn't prohibit us to load media resource from different origins. However, the spec mentions about possible security issues, in which it's danger to expose some sensitive data like metadata, duration.. e.t.c [6].

[4] https://html.spec.whatwg.org/multipage/media.html#loading-the-media-resource:create-a-potential-cors-request
[5] https://html.spec.whatwg.org/multipage/urls-and-fetching.html#create-a-potential-cors-request
[6] https://html.spec.whatwg.org/multipage/media.html#security-and-privacy-considerations

---

Back to our current issue, since I don't know how many media CDNs in the wild would perform the mid-flight redirect during playback, so I think it's less pratical to ask all those websites adding crossorigin on their video element in order to prevent this issue.

We can also notice that, even if we send no-cors mode request to the remote server, it actually response to us with cors mode [7], where the response contains access-control-origin and access-control-expose-header. Even the response mode, which we actually expect for our request, is opaque though. [8]

So here I have two proposals for solving this issue.

(1) stop blocking mid-flight redirect, but we restrict showing sentive media information, such as media type, duration, in this situation.

(2) if the response is cors mode, then check if we can pass CORS policy or not, even if the media element doesn't set crossorigin, to decide whether we should block this cross-origin access. It seems a way which Chrome implemented before [9], but I couldn't find their current implementation for this case, those codes has been removed from their codebase.

[7] https://drive.google.com/file/d/1QEvsYlX8tOoByQ_T5e0T2LtSYF_5w9ma/view?usp=sharing
[8] https://fetch.spec.whatwg.org/#ref-for-concept-filtered-response-opaque
[9] https://bugs.chromium.org/p/chromium/issues/detail?id=532569

---

Hi, jya, baku,
May I have your opinion on this issue?
Thank you.

Comment 6

[Jean-Yves Avenard [:jya]]

(In reply to Alastor Wu [:alwu] from comment #4)

Created attachment 9092808 [details]
Bug 1566572 - use static pref for 'media.block-midflight-redirects'.

It's interesting that we didn't set this pref in any place in our code, don't know if anyone unexpectedly remove this pref or not.

As Chrome won't block CROS redirect for media playback during playing, so we should also not block this behavior.

Therefore, the default value of this pref would be false.

As far as I know; Chrome only allows cross-site redirects to CORS same-origins.

The behaviour should be the same as what we do. Should be facebook to fix it at first glance.

Comment 7

[Alastor Wu [:alwu]]

(In reply to Jean-Yves Avenard [:jya] from comment #6)

As far as I know; Chrome only allows cross-site redirects to CORS same-origins.

Could you point me where you saw this information? Because the only one I could find is [1], in which they didn't force that the redirected url should be in same origin, just required it must pass CORS check. Once the redirected url is in the list of access-control-origin from the response's CORS header, then they would allow this kind of redirect.

[1] https://codereview.chromium.org/1356353003

The behaviour should be the same as what we do. Should be facebook to fix it at first glance.

Even if they added crossorigin in their video, but how possible is that we would see a similar issue on other site using media CDN like this?

Comment 8

[Chris Peterson [:cpeterson]]

Related Fenix issue: https://github.com/mozilla-mobile/fenix/issues/2159

Comment 9

[Paul Adenot (:padenot)]

I don't know if I'm doing something wrong, but I can't repro with fennec nor with firefox preview nightly. Alastor, can you still repro? I'm using https://www.facebook.com/trynottolaughpets/videos/418428262272505/ (from the fenix issue in Comment 8).

Comment 10

[Alastor Wu [:alwu]]

That is not 100% reproducible, because it depends on what CDN facebook is using for the current video, which is changing all the time.
The issue happens only when the new position of video after seeking is from the different origin, which is distributed by CDN, than the original one.

Comment 11

[Alastor Wu [:alwu]]

This issue can only be reproduced on mobile facebook and with really low percentage, because it depends what CDN facebook is using.

And I think that's still not clear to me how should we do for this kinds of cross-origin resource access during playback. In comment6, jya suggested facebook should add crossorigin on their media element, bug I think that can't solve the problem totally because the real problem is that that can happen everywhere because CDN in the wild still can fetch resource from different origins.

Therefore, I'm going to change this as P3, because we would probably not to fix this in this release cycle.

Comment 12

[Emily Toop (:fluffyemily)]

Fenix would like this issue addressed as part of it's Media Enhancement work in Q2

Comment 13

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Resolving as we're no longer able to reproduce. Please reopen and need info if this crops up again.