Browsers and Gstreamer plugins

[Jack Hill]

Hi Guix,

While we have made progress on #52375 [0], the way forward remains 
unclear. In summary, WebKitGTK expects certain GStreamer plugins to be 
available. Depending on which plugins are missing and the web page 
content, the process corresponding to a browser tab may even crash. 
Currently, we expect folks to manually install the necessary plugins into 
their profile/environment.

Complicating matters, it is not clear to me which plugins WebKitGTK needs 
or optionally makes use of. At least some of the needed plugins are from 
gst-plugins-bad, which upstream considers to be of lesser (code) quality 
[1]. gst-plugins-bad is also a large dependency. Adding it would increase 
the closure size of browsers by almost 1GiB!

[0] https://issues.guix.gnu.org/52375
[1] 
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/ca8068c6d793d7aaa6f2e2cc6324fdedfe2f33fa/README#L80

I believe that what I have written above is more or less factual. Now for 
my opinion: I think that we should make browsers work out of the box on 
commonly-encountered web content. To that end, I propose that we wrap 
WebKitGTK-powered browsers so that they can find the necessary plugins. I 
have attached a proof-of-concept patch that does just that for Vimb. I 
used the gst-plugins/selection procedure [2] to to add just one plugin 
from gst-plugins-bad that fixed the crash I was seeing in #52374.

Size comparisons:

Existing Vimb: 1397.5 MiB
Vimb with my patch: 1409.9 MiB
Vimb with all of gst-plugins-bad: 2298.6 MiB

Of course this is just the bare-minimum set of plugins. We may want to 
work with WebKitGTK upstream to determine any additional ones that we 
should be including.

[2] The patch depends on the fix for gst-plugins/selection that I 
submitted in https://issues.guix.gnu.org/52730

A note on the approach of wrapping browsers rather than somehow including 
the plugins in WebKitGTK. It is much more obvious and straight forward (to 
me at least) to wrap the browser executable. Also WebKitGTK could in 
theory be used to render content that comes from a controlled environment, 
not the web, and therefore doesn't need the "web plugins". A downside to 
doing it this way is that each browser would need to be wrapped in the 
same set of plugins. Perhaps we can factor that out so that the plugin 
list only has to be maintained in one place.

Questions and comments? How shall we move forward? Is it ok to wrap 
browsers in this way?

Best,
Jack

0001-gnu-vimb-Wrap-with-required-gstreamer-plugins.patch
Description: Text Data