Epiphany 3.36.0-29-g6569bad51 WebKitGTK 2.28.0 Here is a video showcasing the issue with the appropriate timestamp : https://youtu.be/0UqJGq0zcBk?t=6 The TL;DW is clicking the player controls on https://blogs.gnome.org/mcatanzaro/2019/03/27/epiphany-3-32-and-webkitgtk-2-24/ turns them purple and that trying to seek the file infinitely buffers.
The purple issue doesn't happen in ToT. However the webm seek problem does. Yet another issue with webkitwebsrc, it seems.
Looks like the source element doesn't provide enough data fast enough: 0:00:08.695903246 51 0x1a2a0f0 LOG webkitmediaplayer MediaPlayerPrivateGStreamer.cpp:2066:handleMessage:<media-player-1> Message error received from element matroskademux1 0:00:08.695936024 51 0x1a2a0f0 ERROR webkitmediaplayer MediaPlayerPrivateGStreamer.cpp:2072:handleMessage: Error 9: Could not demultiplex stream. (url=https://blogs.gnome.org/mcatanzaro/files/2019/03/font-variations.webm?_=2) 0:00:08.724308828 51 0x7f3ac40310a0 WARN videodecoder gstvideodecoder.c:4136:_gst_video_decoder_error:<vp9dec1> error: Failed to decode frame 0:00:08.725645437 51 0x7f3ac40310a0 WARN videodecoder gstvideodecoder.c:4138:_gst_video_decoder_error:<vp9dec1> error: corrupt frame
This is a server problem: Look at this request: 0:00:05.341560710 235213 0x11e2360 DEBUG webkitwebsrc WebKitWebSourceGStreamer.cpp:1004:responseReceived:<source> R2: Received response: 200 0:00:05.341659511 235213 0x11e2360 DEBUG webkitwebsrc WebKitWebSourceGStreamer.cpp:1029:responseReceived:<source> R2: Request headers going downstream: request-headers, Referer=(string)https://blogs.gnome.org/mcatanzaro/2019/03/27/epiphany-3-32-and-webkitgtk-2-24/, Range=(string)"bytes\=196264-", Connection=(string)close, Icy-Metadata=(string)1; 0:00:05.341717935 235213 0x11e2360 DEBUG webkitwebsrc WebKitWebSourceGStreamer.cpp:1042:responseReceived:<source> R2: Response headers going downstream: response-headers, Date=(string)"Thu\,\ 14\ May\ 2020\ 08:21:52\ GMT", Content-Length=(guint64)4849870, Last-Modified=(string)"Tue\,\ 26\ Mar\ 2019\ 18:30:47\ GMT", ETag=(string)"\"c861923144653bacd7020e0ffed21f16\"", Expires=(string)"Sat\,\ 15\ Jul\ 2023\ 18:08:32\ GMT", Connection=(string)close, Content-Type=(string)video/webm, Server=(string)"Apache/2.4.27\ \(Red\ Hat\)\ OpenSSL/1.0.2k-fips\ PHP/7.1.30", X-Powered-By=(string)PHP/7.1.30; 0:00:05.341755870 235213 0x11e2360 WARN webkitwebsrc WebKitWebSourceGStreamer.cpp:1060:responseReceived:<source> error: R2: Received unexpected 200 HTTP status code for range request Note how the second request is a range request, but the server replies with HTTP 200 (no support for range requests). Range requests are generally needed for media playback. Safari won't even bother if they are not supported. WebKitGTK and WPE are a bit more lenient, and allow also cases where they are not supported to support use cases like shoutcast, or as a fallback that is viable for small videos. Whether a source URL is seekable is inferred throught the following rules, applied to the first response: 1) If there is no Content-Size, the source is not seekable. 2) If there is an Accept-Ranges header and its value is "none", the source is not seekable. 3) Otherwise, the source is assumed to be seekable. These rules are derived from the fact that most static file servers will emit Content-Size and support seeks, whereas often server scripts and shoutcast streams will not. CONSOLE MEDIA LOG "HTMLMediaElement::mediaEngineWasUpdated(FFA43C223A4A34CF) " 0:00:04.100774772 235213 0x11e2360 DEBUG webkitwebsrc WebKitWebSourceGStreamer.cpp:1004:responseReceived:<source> R1: Received response: 200 0:00:04.100895667 235213 0x11e2360 DEBUG webkitwebsrc WebKitWebSourceGStreamer.cpp:1029:responseReceived:<source> R1: Request headers going downstream: request-headers, Referer=(string)https://blogs.gnome.org/mcatanzaro/2019/03/27/epiphany-3-32-and-webkitgtk-2-24/, Connection=(string)close, Icy-Metadata=(string)1; 0:00:04.100965100 235213 0x11e2360 DEBUG webkitwebsrc WebKitWebSourceGStreamer.cpp:1042:responseReceived:<source> R1: Response headers going downstream: response-headers, Date=(string)"Thu\,\ 14\ May\ 2020\ 08:21:51\ GMT", Content-Length=(guint64)4849870, Last-Modified=(string)"Tue\,\ 26\ Mar\ 2019\ 18:30:47\ GMT", ETag=(string)"\"c861923144653bacd7020e0ffed21f16\"", Expires=(string)"Sat\,\ 15\ Jul\ 2023\ 18:08:31\ GMT", Connection=(string)close, Content-Type=(string)video/webm, Server=(string)"Apache/2.4.27\ \(Red\ Hat\)\ OpenSSL/1.0.2k-fips\ PHP/7.1.30", X-Powered-By=(string)PHP/7.1.30; 0:00:04.101006103 235213 0x11e2360 DEBUG webkitwebsrc WebKitWebSourceGStreamer.cpp:1071:responseReceived:<source> R1: Size: 4849870, isSeekable: true You need to either support range requests in your server (preferable for better cross browser support, and since otherwise the whole video will have to be downloaded every time), or advertise that you *don't* support them by emitting Accept-Ranges: none.