Bug 476836

Summary: Preview area of linked audio file behaves unexpected in Mastodon frontend
Product: [Applications] Falkon Reporter: Jens <senf>
Component: generalAssignee: David Rosca <nowrep>
Status: CONFIRMED ---    
Severity: normal CC: jurajoravec, senf
Priority: NOR    
Version: 24.01.75   
Target Milestone: ---   
Platform: Debian stable   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: 1: Falkon - before clicking the play button
2: Falkoon - Having clicked the play button, turns red, ready to play
3: Falkon - Having clicked the red play button
1 LibreWolf - Before clicking the play button
2: LibreWolf - Having clicked the play button, turns red, ready to play
3: LibreWolf - Having clicked the red play button

Description Jens 2023-11-11 13:03:56 UTC
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
Comment 1 Jens 2023-11-11 13:05:44 UTC
Created attachment 163043 [details]
2: Falkoon - Having clicked the play button, turns red, ready to play
Comment 2 Jens 2023-11-11 13:06:27 UTC
Created attachment 163044 [details]
3: Falkon - Having clicked the red play button
Comment 3 Jens 2023-11-11 13:07:04 UTC
Created attachment 163045 [details]
1 LibreWolf - Before clicking the play button
Comment 4 Jens 2023-11-11 13:07:40 UTC
Created attachment 163046 [details]
2: LibreWolf - Having clicked the play button, turns red, ready to play
Comment 5 Jens 2023-11-11 13:08:16 UTC
Created attachment 163047 [details]
3: LibreWolf - Having clicked the red play button
Comment 6 Jens 2023-11-14 04:12:53 UTC
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.
Comment 7 Jens 2023-11-14 05:34:09 UTC
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.
Comment 8 Juraj 2023-11-14 06:05:29 UTC
> - 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)
Comment 9 Jens 2023-11-15 07:19:12 UTC
(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?
Comment 10 Juraj 2023-11-15 07:55:41 UTC
(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.