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
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
Works here in Ephy 3.33.91-12-g0782ce4ef Powered by WebKitGTK 2.25.4
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.
Works here in Ephy 3.36.0-24-g11cc94492 / WKGTK 2.28.
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
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?
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.
(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. ;)
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. ;)
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...
(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.