[bug#67512] [PATCH 5/5] gnu: Add librewolf.

[Ian Eure]

Herman Rimm <herman@rimm.ee> writes:

> On Sun, Jan 28, 2024 at 01:23:40PM -0800, Ian Eure wrote:
> > Herman Rimm <herman@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