Created attachment 163042 [details] 1: Falkon - before clicking the play button On the Mastodon instance where my Mastodon account is located, within a certain Mastodon post ("toot") the preview area of a remote audio file behaves unexpected in my timeline in the Falkon browser. In that post the remote audio file is specified by an URL pointing to a remote server. I guess this behavior does not only affect this single Mastodon post, but all Mastodon posts containing links to audio files on remote servers, at least to https://www.deutschlandfunk.de/. The behavior can be described as follows: The preview area in the above-mentioned Mastodon post contains a play button in the middle of the preview area. The preview area is correctly displayed before clicking the play button. If you click the play button, the play button turns into another color (red), something which must be intended by the Mastodon software, but at the same time the size of the preview window gets drastically reduced in vertical perspective, and the play button nearly disappears at the upper edge of the preview area. If you then click the red play button, the audio file gets played (and you can hear its content), but the vertical size of the preview area is still drastically reduced. In the LibreWolf browser (version 119.0.1-1) instead, the preview area in this Mastodon post does change in its vertical size when you click the play button for the first time (then the play button turns red, but audio is not played yet), and when you then click the red audio button, the size of the preview area does not get altered, and the audio file is played. See the attached six screenshots. This is the URL of the Mastodon post where I noticed the behavior as described above in the Falkon browser: https://sueden.social/@wikinaut@berlin.social/111391448082255253 The Mastodon version on the Mastodon instance where my Mastodon account is located is 4.2.1. I found this information in the web site source text of my Mastodon instance: "https://github.com/mastodon/mastodon","version":"4.2.1" The following MPRIS-related Debian 12 packages are installed on my machine: libmpris-qt5-1/stable,now 1.0.6-2 amd64 [Installiert,automatisch] libmpris-qt5-dev/stable,now 1.0.6-2 amd64 [installiert] mopidy-mpris/stable,now 3.0.3-1 all [installiert] mpv-mpris/stable,now 0.7.1-1 amd64 [installiert] qml-module-org-nemomobile-mpris/stable,now 1.0.6-2 amd64 [installiert] SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian 12.2 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8
Created attachment 163043 [details] 2: Falkoon - Having clicked the play button, turns red, ready to play
Created attachment 163044 [details] 3: Falkon - Having clicked the red play button
Created attachment 163045 [details] 1 LibreWolf - Before clicking the play button
Created attachment 163046 [details] 2: LibreWolf - Having clicked the play button, turns red, ready to play
Created attachment 163047 [details] 3: LibreWolf - Having clicked the red play button
Update: - Installed QtWebEngine/QtWebKit version: 5.15.13 - this is the QtWebkit version provided by Debian 12 packages - Falkon source code configured again using cmake, this time with the "-D BUILD_PYTHON_SUPPORT=ON" option. I then re-compiled and re-installed the compiled binaries. I will now check if the behavior still occurs, as described in this bug report - I am not able to compile the latest available source code of Qtwebkit (via a git clone) because cmake configuration requires Python 2 for this source code, but Debian 12 does not provide Python 2 packages anymore.
Yes, the behavior as described in this bug report issue occurs, too, if the source code of Falkon has been configured using cmake with the configuration option "-D BUILD_PYTHON_SUPPORT=ON" + has been compiled and re-installed again.
> - I am not able to compile the latest available source code of Qtwebkit (via a git clone) > because cmake configuration requires Python 2 for this source code, > but Debian 12 does not provide Python 2 packages anymore. Falkon uses QtWebEngine and not QtWebkit. Yes, I can confirm that this happens with Qt5 based Falkon. Will be fixed in Qt6 variant. This is due to using older Chromium version as a base and the website expects the "latest" version (the web developers do not care about backwards compatibility)
(In reply to Juraj from comment #8) > Falkon uses QtWebEngine and not QtWebkit. Thank you for this clarification. Until now I mixed up these two browser rendering engines / I did not know that there is another renedering web engine called QTWebEngine. > Yes, I can confirm that this happens with Qt5 based Falkon. > Will be fixed in Qt6 variant. OK. So this bug report here cannot be closed yet, because when QT6 will have been released one day in a first final version, this future version of QT needs to be checked against this bug report, right? > This is due to using older Chromium version as a base and the website > expects the "latest" version (the web developers do not care about backwards > compatibility) I guess, here you are referring to a future QTWebEngine that will have been built against a final version of QT6, right?
(In reply to Jens from comment #9) > OK. So this bug report here cannot be closed yet, because when QT6 will have > been released one day in a first final version, this future version of QT > needs to be checked against this bug report, right? > > I guess, here you are referring to a future QTWebEngine that will have been > built against a final version of QT6, right? Qt6 is already released, QtWebEngine is a part of Qt. What needs to be ported to Qt6 is Falkon. I checked the site with the development version which is already partialy ported to Qt6 and it works fine. In other words, It should be fixed with Falkon 24.02. But the distribution you use will need to provide Qt6, otherwise it will be impossible to update.