GNU bug report logs - #67512
[PATCH 0/5] Add LibreWolf

Previous Next

Full log

Message #47 received at 67512 <at> debbugs.gnu.org (full text, mbox):

From: Herman Rimm <herman <at> rimm.ee>
To: Ian Eure <ian <at> retrospec.tv>
Cc: 67512 <at> debbugs.gnu.org
Subject: [bug#67512] [PATCH 5/5] gnu: Add librewolf.
Date: Fri, 2 Feb 2024 19:44:49 +0100

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]:

  A free system distribution must not steer users towards obtaining any
  nonfree information for practical use, or encourage them to do so. The
  system should have no repositories for nonfree software and no
  specific recipes for installation of particular nonfree programs. Nor
  should the distribution refer to third-party repositories that are not
  committed to only including free software; even if they only have free
  software today, that may not be true tomorrow. Programs in the system
  should not suggest installing nonfree plugins, documentation, and so
  on.

  For instance, a free system distribution must not contain browsers
  that implement EME, the browser functionality designed to load DRM
  modules.

>> 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.

Looking at the firefox source [2], 'browser.eme.ui.enabled' is set to
true if MOZ_WIDEVINE_EME is defined, false otherwise. MOZ_WIDEVINE_EME
gets defined by being in MOZ_EME_MODULES, which is set to eme_modules in
toolkit/moz.configure where a comment reads:

  # Widevine is enabled by default in desktop browser builds.

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.

Cheers,
Herman

[1]: https://www.gnu.org/distros/free-system-distribution-guidelines.en.html
[2]: https://archive.mozilla.org/pub/firefox/releases/123.0b5/source/firefox-123.0b5.source.tar.xz
[3]: https://codeberg.org/librewolf/source.git

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.