89195 2012-06-15 03:35:24 -0700 [GStreamer][OGG] Unreliable seek to unbuffered regions when using Jamendo 2021-04-14 08:40:07 -0700 1 1 1 Unclassified WebKit WebKitGTK 528+ (Nightly build) PC Linux RESOLVED WORKSFORME P2 Normal --- 0 v_2e webkit-unassigned bugs-noreply calvaris mcatanzaro pnormand webkit-bugzilla oldest_to_newest 650063 0 v_2e 2012-06-15 03:35:24 -0700 Hello! They recently created a new JavaScript player on Jamendo.com and now it does not work in Midori web browser (which is built upon Webkit-GTK). Webkit-GTK version installed on my system is 1.8.1. I hope there is a way to fix this issue. Regards, Vladimir 1535527 1 webkit-bugzilla 2019-05-12 21:52:01 -0700 While I don't doubt they've changed quite a bit from when this issue was made, this issue is still present on : Epiphany version : 3.33.1-2b3776d2 Webkit version : WebKitGTK 2.24.1 1564431 2 pnormand 2019-08-23 04:07:12 -0700 Works here in Ephy 3.33.91-12-g0782ce4ef Powered by WebKitGTK 2.25.4 1632565 3 webkit-bugzilla 2020-03-21 19:19:02 -0700 This is still present here in Epiphany 3.36.0-27-g2a31b3fdc powered by WebKitGTK 2.28.0. Steps to reproduce would be : 1. Go to for example : https://www.jamendo.com/artist/355621/emerald-cave 2. Clicking play will work and will also change track if you let it do so 3. Trying to move in the seekbar After trying to move in the seekbar, the song will song playing and the whole page will freeze and not let you scroll. 1632617 4 pnormand 2020-03-22 03:06:48 -0700 Works here in Ephy 3.36.0-24-g11cc94492 / WKGTK 2.28. 1632648 5 mcatanzaro 2020-03-22 09:57:15 -0700 Works for me too, with 3.36.0-26. So we all have effectively the same browser version (as none of the changes there could possibly be related). So the most likely cause for different behavior would be different runtime version, I guess. I have: $ flatpak info org.gnome.Platform//master GNOME Application Platform version master - Shared libraries used by GNOME applications ID: org.gnome.Platform Ref: runtime/org.gnome.Platform/x86_64/master Arch: x86_64 Branch: master License: GPL-2.0+ Origin: gnome-nightly Collection: org.gnome.Nightly Installation: user Installed: 939.5 MB Active commit: 70de0d981e4d158e3d377ee7fcd8334d7998706734202952b693a685aa49f8d6 Latest commit: 3b9eb74b56793abb8f3a51090465c4c238c6194648cb5b4e711405da0d080207 Parent: f748811f8e3fdd6f55d7257115b1f6e8e7d902c7e1fe1fd74eb9c4dc231e5c4a Subject: Export org.gnome.Platform Date: 2020-03-19 14:43:18 +0000 1632676 6 webkit-bugzilla 2020-03-22 12:59:08 -0700 Here I have : $ flatpak info org.gnome.Platform//master GNOME Application Platform version master - Shared libraries used by GNOME applications ID: org.gnome.Platform Ref: runtime/org.gnome.Platform/x86_64/master Arch: x86_64 Branch: master License: GPL-2.0+ Origin: gnome-nightly Collection: org.gnome.Nightly Installation: system Installed: 939.5 MB Commit: 3b9eb74b56793abb8f3a51090465c4c238c6194648cb5b4e711405da0d080207 Parent: 93b9df3afc0c0933f4264f99f57a56f09b997ca8ab3c7ccfe7aec5fe1b643674 Subject: Export org.gnome.Platform Date: 2020-03-21 14:12:05 +0000 I will make a video to showcase the issue since perhaps this is simply a misunderstanding in how the issue manifests and how to reproduce it (as I've started doing more recently with two other issues). Does that sound good? 1632697 7 webkit-bugzilla 2020-03-22 15:40:30 -0700 Well, I did a video anyways. Here it is with the timestamp : https://youtu.be/0UqJGq0zcBk?t=35 It seems to be related with the fact that I change the position on the seekbar rapidly. 1632701 8 mcatanzaro 2020-03-22 16:13:43 -0700 (In reply to azeikui6ziwjypjgu5w2tixgcxdaapxx from comment #7) > It seems to be related with the fact that I change the position on the > seekbar rapidly. Yup, should have said that at first! Now I can reproduce the bug. I think the web process is probably hung. BTW, there are a LOT more WebKit bugs with that YouTube link: * Video never starts playing * Spinner continues spinning even if I pause the video * Seeking the video generally does nothing * If I seek near to the start of the video, only then does it start playing * Video occasionally flashes and briefly displays an old frame (I'm guessing this is a decoding problem and not an issue with your video itself?) * If I switch to theater mode, the video turns completely black That's not even counting the other video playback issues you demonstrated at the start of the video. It's enough to wonder if your faith may be misplaced. ;) 1632704 9 webkit-bugzilla 2020-03-22 16:28:30 -0700 Huh.. I had not tested the timestamped link... The video totally works without the timestamp so that's a good way to reproduce. Should I open an issue? > That's not even counting the other video playback issues you demonstrated at the start of the video. It's enough to wonder if your faith may be misplaced. ;) Honestly, the tab switching being so snappy, the window resizing performance, the search bar results feeling so smooth, the back/forward gestures feeling magical. These things alone make sure I can never look away. ;) 1632782 10 pnormand 2020-03-23 03:36:33 -0700 The issue happens when seeking to an unbuffered position it seems. As this is OGG, sadly I'm not sure we can do much, that format is known to have seek issues... 1632783 11 pnormand 2020-03-23 03:42:46 -0700 (In reply to Lionir from comment #9) > Huh.. I had not tested the timestamped link... > > The video totally works without the timestamp so that's a good way to > reproduce. Should I open an issue? > Seek in MSE videos is currently unreliable. No need to open a new issue about this. 1750125 12 calvaris 2021-04-14 08:40:07 -0700 It is working now on ToT