This is blocked by a mitmproxy error when replaying video content on Chrome/Firefox
From the looks of it it's the same issue that is blocking netflix (Bug 1511341)

Using raptor studio this appears to be mostly working for me. :bebe could you try running this using the following recording? https://drive.google.com/open?id=1c57pwAU-D8CmRiPDGbMZkq7keCMVkoN_

There appear to be some issues playing back the video, but perhaps we can revisit that later if mitmproxy 4.0.4 doesn't resolve it.

Setting to P2 as blocked by Bug 1520448

This website uses websokets and video streaming

Because of this a simple mitmproxy 4.0.4 recording won't fix the test

What is the purpose of this test? tp6 refers to page load, but recently the dependency for bug 1539111 was added.

I assume this should just be a page load test and not anything video streaming related?

When we started working on the page load tests, we didn't have plans for video streaming tests. I believe the issue here is that the video starts streaming once the page has loaded. It may make sense for Twitch to be a media streaming test in the future, and to use a different URL for the page load.

Twitch media streaming is definitely something we should look at in the future, we have numerous bugs on file related to cpu, memory, fans spinning up, sluggishness, etc., during playback and streaming (live chat seems to be bad as well).

For this purpose, it would be loading everything up to but not including the video starting, similar to youtube tp6. I think we'd want to have autoplay off and just let all the JS, images, etc. load as well as the player itself and chat.

(In reply to Stuart Philp :sphilp from comment #7)

For this purpose, it would be loading everything up to but not including the video starting, similar to youtube tp6. I think we'd want to have autoplay off and just let all the JS, images, etc. load as well as the player itself and chat.

Right, that is what I also got. So lets remove the dependency for bug 1539111 now, and get a different bug filed for video streaming. Thanks.

As we are planning a massive re record. let's include these tests in that process

Tried to re record again Twitch.
As it heavily relies on WebSockets in it's implementation it can't be replayed with MitmProxy

Tested with WPR and it works out of the box.

This test is still blocked by: Bug 1530684 Update mitmproxy alternate server script to support WebSocket packages

:davehunt can we record this with web-sockets disabled? the site looks the same and we avoid all the WebSockets errors.

How are you disabling web-sockets?

We can disable Web-sockets support in mitm using the special option.

Coming back with some more information on this.

From my research:

1. WPR does not support WebSockets. Tested using record/playback on http://websocket.org/echo.html
2. MitmProxy partially supports WebSockets:
   1. Out of the box when we use a recording containing websockets mitm crashes: https://github.com/mitmproxy/mitmproxy/issues/3564
   2. We can implement a plugin for websockets similar with alternate-server-replay but we might hit some other issues: https://github.com/mitmproxy/mitmproxy/issues/3396

Until we fix the websockets in mitm or find some other solution my recomandation would be to disable them using the special flag.

:Tarek any thoughts on disabling websokets for the moment?

If we want to load the chat as per https://bugzilla.mozilla.org/show_bug.cgi?id=1517799#c7, we do need to have the websocket protocol working, so I would not disable it. I will look at having mitmproxy 4.0.4 working with websockets.

I am adding a bug specifically for this.

Record this with WebSockets dissabled

recording will be tracked on bug 1559955