Package: guix-patches;
Reported by: Ian Eure <ian <at> retrospec.tv>
Date: Tue, 28 Nov 2023 20:12:01 UTC
Severity: normal
Tags: patch
Done: Andrew Tropin <andrew <at> trop.in>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: Ian Eure <ian <at> retrospec.tv> To: 67512 <at> debbugs.gnu.org Subject: [bug#67512] [PATCH 5/5] gnu: Add librewolf. Date: Tue, 06 Feb 2024 15:29:22 -0800
Herman Rimm <herman <at> rimm.ee> writes: > On Sun, Jan 28, 2024 at 01:23:40PM -0800, Ian Eure wrote: >> >> Herman Rimm <herman <at> rimm.ee> writes: >> >> > Librewolf should not link to addons.mozilla.org, using this >> > build phase >> > from torbrowser: >> > >> >> What’s the rationale for not using addons.mozilla.org? >> >> gnuzilla.gnu.org appears to be broken, it’s serving an Apache >> default page, >> as if the vhost isn’t configured. Does the browser request >> some path within >> that domain, which does work? I’m not familiar with the >> mechanism used for >> this. > > Apologies, the URL is: https://gnuzilla.gnu.org/mozzarella/. It > is used > because addons.mozilla.org contains nonfree extensions, from > [1]: > I’ll look into this and see what it takes to adjust. >>> LibreWolf disables DRM by default[1], so I don’t believe this >>> flag is >>> necessary. I can confirm that it’s disabled in the browser >>> built from >>> the package definition without this flag. >>> >> >>I looked a bit deeper into this. There are actually no >>EME-related >>configuration options in Librewolf at all, either to enable or >>disable it. >>It’s always disabled. > > Interesting, I applied the patch series onto 551d013, built > librewolf, > removed ~/.librewolf and ~/.mozilla, started librewolf and went > to > about:config, where 'browser.eme.ui.enabled' has the default > value > 'true', so I can see and toggle the checkbox for 'play > DRM-controlled > content' in about:preferences. I don't know why > 'browser.eme.ui.enabled' > is 'true' by default for me, but I think adding --disable-eme > will set > the default to 'false', like it is in the icecat-minimal > about:config. > I completely misunderstood the various settings and systems at play here, which I believe led us to talk past each other. The summary of the situation, best as I can tell, is this: - EME support: a build setting controlling whether the browser supports *any kind* of encrypted media playback. - Widevine support: one kind of DRM, implemented as an EME plugin. - `browser.eme.ui.enabled' browser preference: controls whether the UI for DRM is visible. Controls visibility *only*. A browser build without EME will still show this if `browser.eme.ui.enabled' is `true' (but the control does nothing). A browser build *with* EME (and one or more DRM plugins) can have this set to `false' and still play DRM’d content. - The checkbox within the EME UI: On browsers built with EME and DRM plugin(s), controls whether that is allowed to be used. On browsers without EME+Widevine, does nothing. The default configuration of a clean install of a stock LibreWolf build is: - The browser is built with EME and Widevine support - The UI to enable DRM is visible. - Within that UI, the checkbox is unchecked (meaning DRM is not enabled). I have rebuilt with --disable-eme and confirmed that even with browser.eme.ui.enabled=true and the "Play DRM-controlled content" box checked, the resulting build cannot play DRM’d streams. This was actually somewhat difficult, since I don’t use or have access to any commercial streaming service, but I found a website which lets you test DRM playback, and used that to compare behavior of a LibreWolf binary obtained from the project with my build. Should anyone else want to verify, or need to do this kind of testing, the site is: https://www.nuevodevel.com/nuevo/showcase/drm > When running grep in a Librewolf repo [3] for the aformentioned > terms, > only the --disable-jxl configure flag is modified in toolkit/ > moz.configure, so I don't think the Librewolf developers disable > EME.I > am not sure though, I don't want to rebuild librewolf with the > --disable-eme flag to look for the difference. > The "source" repo contains patches and orchestration to produce the LibreWolf source tarball. The setting which disables DRM by default is in their settings repo[1], which is a submodule. The likely scenario is that you cloned the repo with the eminently reasonable assumption that this would produce a full copy of its contents, and grepped them. Unfortunately, Git submodules are deeply unreasonable, and do not work this way -- you must perform manual actions to populate or update them, which is very easy to forget, especially if one doesn’t work with them regularly. LibreWolf’s specific wording is "We disable DRM by default," which I believe is accurate, but fails to capture the fullness of the situation, i.e. that DRM support is included, but dormant. So you’re also correct that they don’t disable EME -- the disabling happens above that layer. This was not clear to me in the earlier discussions. I’ve removed EME from the build, and will work on replacing Mozilla’s addons with Mozarella, then send an updated patch series. Separately, I’ve also managed to unbundle libpng, libwebp, and nss; fixed the glxinfo utility program; and eliminated a redundant copy of the main binary. Thanks, — Ian [1]: https://gitlab.com/librewolf-community/settings/-/blob/ba238a9ca6bfd509f31e6eb4a45c14c11b7ef7fe/librewolf.cfg#L258-263
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.