From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:203:b4db::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 8EvWKVpByWHfDQEAgWs5BA (envelope-from ) for ; Mon, 27 Dec 2021 05:30:18 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 2CdCJ1pByWEk+AAA9RJhRA (envelope-from ) for ; Mon, 27 Dec 2021 05:30:18 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 0534E6E3A for ; Mon, 27 Dec 2021 05:30:18 +0100 (CET) Received: from localhost ([::1]:45878 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n1heL-0002X7-3s for larch@yhetil.org; Sun, 26 Dec 2021 23:30:17 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35634) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n1he2-0002Wc-KI for guix-devel@gnu.org; Sun, 26 Dec 2021 23:29:58 -0500 Received: from [2607:f8b0:4864:20::f35] (port=35754 helo=mail-qv1-xf35.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n1he0-0005gE-Qz for guix-devel@gnu.org; Sun, 26 Dec 2021 23:29:58 -0500 Received: by mail-qv1-xf35.google.com with SMTP id kj16so12966002qvb.2 for ; Sun, 26 Dec 2021 20:29:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=KvGqQWDG9dbDzl0d9CL3U6xo+4EjFqSDM3WvzJZYN9c=; b=Ne4IpQ7A4q+rT8IWx/tabYXDHamc9WDg2Qu9lfyPEjET83eHvDGpfCWihksedCG5oV T0awnA2fYRa9omGrPxCMZAvxN/Xv7NaYdvU1SYYqx7/HXR4XVkoPeJP1fIdVau0xFKkS yO6r/t4VtzNpKelR5J3DWzTHVAGkrHW0sC2Oy4vJQH86jF9PrkZx25fpwKPW3M9Bhi32 NPRSKuGO//iY82CodyWhxVVc6ZtvmetuwN9a7OC3dJ216LYh56UMy4H3i3YIcrrA4jv+ qKRYp1qnosvVFkPIJjiLg7+stBa7vA4PJmHQg2AlAT4jBiQTqKb2OF6uJFadBTgyXz0u ydtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=KvGqQWDG9dbDzl0d9CL3U6xo+4EjFqSDM3WvzJZYN9c=; b=j2tiEm+rBvYWHl4sr953EAcZn4S8v6Q4mxnEi4/zH0h5KiJX0Jad6Fx/jZlz9GS0Mo Hz2AYU6k9QyBIeM/as9nzXb1G4o6FoSdhC0mrS7OQemvAE3mdNckhhOBCbzDu0bjlpGO jTtTyfrWBrXaaeemSRf9gfQA+rnwGukNKKqxu+IzykJNvGLO6+NpY/UX4p+w00WTn1KI RAKGPr3GOv90qDeXrHL4rRLWyaeDSAt29I9BpJ14MOUHMCgEi8mo2UaHaiZ9mXFze1+M BaETxWCgR/Hy5H+Wc/7ReYWT9W0lPIGan6/sjn72QkJU0LuhzHzvFyrodhn1Rr0R+b7J uKXQ== X-Gm-Message-State: AOAM5323jFuE2n39D2x+oyHh4J+uT1GI4SKubncj3tcCIy7FFQp4wthr vGE/7C/MyHvy3+5sk4zgpUAIafygSLE= X-Google-Smtp-Source: ABdhPJzI6BXRaTsM4aGFGzVFrGGsS3eKEnJI7oSVOL6HEMk6oVON2RMGMIxl5JnxMA3XX4t/3L8Ykg== X-Received: by 2002:ad4:5b82:: with SMTP id 2mr13909440qvp.90.1640579395729; Sun, 26 Dec 2021 20:29:55 -0800 (PST) Received: from hurd (dsl-10-128-55.b2b2c.ca. [72.10.128.55]) by smtp.gmail.com with ESMTPSA id w9sm12701878qko.71.2021.12.26.20.29.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Dec 2021 20:29:55 -0800 (PST) From: Maxim Cournoyer To: Jack Hill Subject: Re: Browsers and Gstreamer plugins References: Date: Sun, 26 Dec 2021 23:29:54 -0500 In-Reply-To: (Jack Hill's message of "Wed, 22 Dec 2021 11:54:11 -0500 (EST)") Message-ID: <87tueuwtz1.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::f35 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::f35; envelope-from=maxim.cournoyer@gmail.com; helo=mail-qv1-xf35.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1640579418; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=KvGqQWDG9dbDzl0d9CL3U6xo+4EjFqSDM3WvzJZYN9c=; b=inQDzzuNjIaP/C0RZB8Cqb8/Cuoq+fF+JIs4Ir4BMuIPhsaODwDjzx4o0/tP92dwp6fvxZ O2tJBqLcVNvgv6eDK8Yks3XeqA4dNjoX6qRYxvy7S9wqinVElVMlQzxOb+/I5cZYFm/Pfo ffu/j6s5KXX4BQ7tK+D7qJIi4vyeTHi/La4aKNOiHAyf5l6KP3Ah8HEBKJOaMhE7BDwFNe R9rH2ptstymAl1oN1clOSP1NqVwLyLbc7mX5M4hQ1RvJmmoMDbqeeF8d6/oiV0L01mGQzP sjmUHpVz6iRrZOGUWZxuwzXsDabxZH1JYrfzIwalWXxCPJuukzRWWZVtonX3Lw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1640579418; a=rsa-sha256; cv=none; b=RviR169MEskw2s77yCxWOA4ekkKPEK9VPZEe07P/Dy2zwfL8bd5XBGekyyBo0rl66q2OvC 1tmpqow/3/fVfb5ojZgmCZ+8Mbet5hyqz27LE6m/qY4Qg55BVSHi1wY2UNYAcQYhG9OCh9 oi66Q4lY8Rw+iRD6MkuX5FD1LgJPrpYIpXAgdP0b3UwgP6lP9Fu+5Y3GUP2SIGCHc49BJv rTDdiTQX7yveWgxuSdepMxxVPFPNr9eQ7ucLvrHqjEgFVJ/oSfAVT2Wgqi20C7eOLNqTk4 FoqrF9YCLNl8IkE7ZYcN+3UnI4LEZYCCKJAeMKWuA44wmvUMnzgqgc+pjntYxQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Ne4IpQ7A; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -4.27 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Ne4IpQ7A; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 0534E6E3A X-Spam-Score: -4.27 X-Migadu-Scanner: scn1.migadu.com X-TUID: yl0nvoTLkMdL Hello Jack, Thank you for posting this well written piece here. Jack Hill writes: > 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. That sucks; but it really is webkitgtk/browsers' fault; they should have better reporting so that users know what is missing instead of obtusely crashing a tab. > 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 1 GiB for code deemed of even worst quality than even the 'ugly' plugins (they're literally at the bottom of the chart, quality-wise) doesn't sound too appealing :-) [0]. [0] https://raw.githubusercontent.com/GStreamer/gstreamer/master/README > 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. How would you define "commonly-encountered" web content? How will we handle bug reports of "tab crashed on site X" because a plugin we thought obscure is used by someone? It's a bit of a slippery slope where we may end up wrapping all/too many plugins, because of the issue I raised in my preceding paragraph (bad reporting from webkitgtk itself). Plugins exist for the very reason to allow end users to extend functionalities the way they see fit, so it seems a bit backward to me to "wrap plugins in", which makes them non-optional onto users. On other systems, they are typically "recommended" but not wrapped in a way that makes it difficult for users to opt out of them. > 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 This looks reasonable, space wise. > 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? I sympathize with the goal of improving our users experience (by shipping browsers that don't crash mysteriously left and right), but I'm not satisfied with the solution of wrapping plugins. Could we instead try to fast-forward work that has happened in webkitgtk to produce better diagnostics about missing plugins? Such as [1], which has a patch (with comments on). It's not a panacea, but having errors about missing plugins/functionality appear on stderr would be an improvement. We should also create tickets upstream in webkitgtk-based browsers requesting that they report missing plugins gracefully in their user interfaces. [1] https://bugs.webkit.org/show_bug.cgi?id=233949 If all this is done and documented and in the waiting queue, then we could proceed with wrap browsers with a minimal set of plugins as a stopgap/temporary measure until the upstream issues get resolved. What do you think? Thanks, Maxim