GNOME Bugzilla – Bug 781404
Disable inline audio play in message preview
Last modified: 2017-04-19 17:09:38 UTC
Open an email that has an MP3 file attached. See that black thingy to play the attachment inside of evolution-3.22.6-2.fc25.x86_64. Click the Play button. Nothing ever happens (and I can play that MP3 file with e.g. Totem).
Created attachment 349944 [details] screenshot
Ouch, such a long file in a message, shame on you :) That "black thingy" is provided by WebKit itself, evolution doesn't have much influence on this, except of telling WebKit to do something with it with: <audio controls> <source src="data:xxx;base64,xxxxx"/> </audio> thus even epiphany should behave the same with an HTML page like this: <html><body><audio controls> <source src="file:///home/andre/Music/file.mp3"/> </audio></body></html> Could you try with it, please? It should be as simple as saving the above HTML content as, say, /tmp/test.html and then run: $ epiphany /tmp/test.html Change the file path in the HTML content, of course. It can be either WebKit is wrong, or data passed to it this way do not work (a non-existent file reference behaves similarly as you described).
"$ epiphany /home/acko/Desktop/bug781404.html" works without a problem and plays the file in epiphany-3.22.7-1.fc25.x86_64 and webkitgtk4-2.16.1-2.fc25.x86_64
Ah, I see, the same here. Issue in evolution then. Confirming.
After some testing, that audio control requires javascript, which is a no-go for evolution (due to security reasons). I'll disable that inline audio formatter to not confuse users.
I forgot to mention that I have it also confirmed from WebKitGTK+ developers. I'm disabling the code at the moment, not removing it, thus it can be eventually re-enabled when WebKitGTK+ player will start working differently, maybe without javascript. Created commit 377e82f in evo master (3.25.1+) Created commit 0de6eff in evo gnome-3-24 (3.24.2+)