IceCat lacks WebGL support

  • Done
  • quality assurance status badge
Details
8 participants
  • Sarah Morgensen
  • Jonathan Brielmaier
  • Julien Lepiller
  • Ludovic Courtès
  • Maxim Cournoyer
  • Tobias Geerinckx-Rice
  • Mark H Weaver
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
normal
L
L
Ludovic Courtès wrote on 19 Jan 2019 16:49
(name . Bug Guix)(address . bug-guix@gnu.org)
87o98cr6kx.fsf@gnu.org
Hello,

If you enable WebGL support in ‘about:config’, then stop it and run:

Toggle snippet (26 lines)
$ export LIBGL_DRIVERS_PATH=$(guix build mesa)/lib/dri
$ icecat https://get.webgl.org
1547912837231 addons.webextension.tortm-browser-button@jeremybenthum WARN Please specify whether you want browser_style or not in your browser_action options.
1547912837231 addons.webextension.https-everywhere@eff.org WARN Please specify whether you want browser_style or not in your browser_action options.
1547912837232 addons.webextension.{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} WARN Please specify whether you want browser_style or not in your browser_action options.
JavaScript warning: moz-extension://b84ee99d-7e50-4975-9d16-3806d330a3b2/lib/adblockplus.js, line 0: Successfully compiled asm.js code (total compilation time 1ms; not stored in cache (too small )
libGL error: MESA-LOADER: failed to retrieve device information
libGL error: unable to load driver: i915_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: i915
libGL error: MESA-LOADER: failed to retrieve device information
libGL error: unable to load driver: i915_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: i915
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
JavaScript warning: https://get.webgl.org/, line 193: Error: WebGL warning: Failed to create WebGL context: WebGL creation failed:
* Error during native OpenGL init.
* Exhausted GL driver caps.
* Exhausted GL driver options.
JavaScript warning: https://get.webgl.org/, line 197: Error: WebGL warning: Failed to create WebGL context: WebGL creation failed:
* Error during native OpenGL init.
* Exhausted GL driver caps.
* Exhausted GL driver options.

and the web page reads:

While your browser seems to support WebGL, it is disabled or
unavailable.

Weird thing is that glxgears and glxinfo (from ‘mesa-utils’) both work
well.

Thoughts?

Ludo’.
J
J
Julien Lepiller wrote on 19 Jan 2019 18:07
(address . 34135@debbugs.gnu.org)
20190119180750.13c17654@lepiller.eu
Le Sat, 19 Jan 2019 16:49:02 +0100,
Ludovic Courtès <ludo@gnu.org> a écrit :

Toggle quote (51 lines)
> Hello,
>
> If you enable WebGL support in ‘about:config’, then stop it and run:
>
> --8<---------------cut here---------------start------------->8---
> $ export LIBGL_DRIVERS_PATH=$(guix build mesa)/lib/dri
> $ icecat https://get.webgl.org
> 1547912837231
> addons.webextension.tortm-browser-button@jeremybenthum WARN
> Please specify whether you want browser_style or not in your
> browser_action options. 1547912837231
> addons.webextension.https-everywhere@eff.org WARN Please
> specify whether you want browser_style or not in your browser_action
> options. 1547912837232
> addons.webextension.{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
> WARN Please specify whether you want browser_style or not in your
> browser_action options. JavaScript warning:
> moz-extension://b84ee99d-7e50-4975-9d16-3806d330a3b2/lib/adblockplus.js,
> line 0: Successfully compiled asm.js code (total compilation time
> 1ms; not stored in cache (too small ) libGL error: MESA-LOADER:
> failed to retrieve device information libGL error: unable to load
> driver: i915_dri.so libGL error: driver pointer missing libGL error:
> failed to load driver: i915 libGL error: MESA-LOADER: failed to
> retrieve device information libGL error: unable to load driver:
> i915_dri.so libGL error: driver pointer missing libGL error: failed
> to load driver: i915 libGL error: unable to load driver:
> swrast_dri.so libGL error: failed to load driver: swrast JavaScript
> warning: https://get.webgl.org/, line 193: Error: WebGL warning:
> Failed to create WebGL context: WebGL creation failed:
> * Error during native OpenGL init.
> * Exhausted GL driver caps.
> * Exhausted GL driver options.
> JavaScript warning: https://get.webgl.org/, line 197: Error: WebGL
> warning: Failed to create WebGL context: WebGL creation failed:
> * Error during native OpenGL init.
> * Exhausted GL driver caps.
> * Exhausted GL driver options.
> --8<---------------cut here---------------end--------------->8---
>
> and the web page reads:
>
> While your browser seems to support WebGL, it is disabled or
> unavailable.
>
> Weird thing is that glxgears and glxinfo (from ‘mesa-utils’) both work
> well.
>
> Thoughts?
>
> Ludo’.

Try setting security.sandbox.content.read_path_whitelist to /gnu/store/
(with a leading /) in about:config.
L
L
Ludovic Courtès wrote on 20 Jan 2019 23:45
(name . Julien Lepiller)(address . julien@lepiller.eu)(address . 34135@debbugs.gnu.org)
87womzlzhm.fsf@gnu.org
Hi Julien,

Julien Lepiller <julien@lepiller.eu> skribis:

Toggle quote (3 lines)
> Try setting security.sandbox.content.read_path_whitelist to /gnu/store/
> (with a leading /) in about:config.

Setting it to “/gnu/store/” (with a trailing slash) works, thank you!

It turns out that setting LIBGL_DRIVERS_PATH is even unnecessary.

I suppose we should patch the default value of
‘security.sandbox.content.read_path_whitelist’ in our package. What do
people think?

Thanks,
Ludo’.
R
R
Ricardo Wurmus wrote on 21 Jan 2019 09:24
(name . Ludovic Courtès)(address . ludo@gnu.org)
87d0oqe7u2.fsf@elephly.net
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (15 lines)
> Hi Julien,
>
> Julien Lepiller <julien@lepiller.eu> skribis:
>
>> Try setting security.sandbox.content.read_path_whitelist to /gnu/store/
>> (with a leading /) in about:config.
>
> Setting it to “/gnu/store/” (with a trailing slash) works, thank you!
>
> It turns out that setting LIBGL_DRIVERS_PATH is even unnecessary.
>
> I suppose we should patch the default value of
> ‘security.sandbox.content.read_path_whitelist’ in our package. What do
> people think?

It isn’t much of a sandbox if all of /gnu/store would be permitted. Can
this be reduced to the paths of store items that are known at build
time?

--
Ricardo
J
J
Julien Lepiller wrote on 21 Jan 2019 09:49
(address . 34135@debbugs.gnu.org)
7A88B01C-EAB9-47BA-98EC-16F91C7993E7@lepiller.eu
Le 21 janvier 2019 09:24:53 GMT+01:00, Ricardo Wurmus <rekado@elephly.net> a écrit :
Toggle quote (25 lines)
>
>Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi Julien,
>>
>> Julien Lepiller <julien@lepiller.eu> skribis:
>>
>>> Try setting security.sandbox.content.read_path_whitelist to
>/gnu/store/
>>> (with a leading /) in about:config.
>>
>> Setting it to “/gnu/store/” (with a trailing slash) works, thank you!
>>
>> It turns out that setting LIBGL_DRIVERS_PATH is even unnecessary.
>>
>> I suppose we should patch the default value of
>> ‘security.sandbox.content.read_path_whitelist’ in our package. What
>do
>> people think?
>
>It isn’t much of a sandbox if all of /gnu/store would be permitted.
>Can
>this be reduced to the paths of store items that are known at build
>time?

You'll have to list every library and there dependencies. Is that possible? Also I think icecat has read permission to /usr by default, so setting permission to the store is similar.
L
L
Ludovic Courtès wrote on 21 Jan 2019 10:54
(name . Julien Lepiller)(address . julien@lepiller.eu)
874la2l4j3.fsf@gnu.org
Julien Lepiller <julien@lepiller.eu> skribis:

Toggle quote (29 lines)
> Le 21 janvier 2019 09:24:53 GMT+01:00, Ricardo Wurmus <rekado@elephly.net> a écrit :
>>
>>Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Hi Julien,
>>>
>>> Julien Lepiller <julien@lepiller.eu> skribis:
>>>
>>>> Try setting security.sandbox.content.read_path_whitelist to
>>/gnu/store/
>>>> (with a leading /) in about:config.
>>>
>>> Setting it to “/gnu/store/” (with a trailing slash) works, thank you!
>>>
>>> It turns out that setting LIBGL_DRIVERS_PATH is even unnecessary.
>>>
>>> I suppose we should patch the default value of
>>> ‘security.sandbox.content.read_path_whitelist’ in our package. What
>>do
>>> people think?
>>
>>It isn’t much of a sandbox if all of /gnu/store would be permitted.
>>Can
>>this be reduced to the paths of store items that are known at build
>>time?
>
> You'll have to list every library and there dependencies. Is that
> possible?

That would be possible, yes, though we’d have the build-time
dependencies rather than the run-time dependencies (since we cannot know
the run-time dependencies until IceCat is built.)

That said putting all of /gnu/store wouldn’t be that bad I think—at
least user data remains inaccessible, which is much better than exposing
/usr on FHS distros.

Thoughts?

Ludo’.
R
R
Ricardo Wurmus wrote on 21 Jan 2019 15:12
(name . Ludovic Courtès)(address . ludo@gnu.org)
87bm4adrqa.fsf@elephly.net
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (6 lines)
> That said putting all of /gnu/store wouldn’t be that bad I think—at
> least user data remains inaccessible, which is much better than exposing
> /usr on FHS distros.
>
> Thoughts?

Sounds fine to me then.

--
Ricardo
J
J
Jonathan Brielmaier wrote on 12 May 2020 20:19
IceCat lacks WebGL support
(address . 34135@debbugs.gnu.org)
195c017f-1a5e-6d6a-1cc0-d0ad63849b93@web.de
429c8284d232c3f9fbe3dc87a3da323f3a864c03 did preliminary work for ffmpeg
white listing. So we need to add the WebGL required stuff as well to
that whitelist. I'll see what I can do.
J
J
Jonathan Brielmaier wrote on 17 May 2020 22:24
(address . 34135@debbugs.gnu.org)
d1ef0d73-93dd-b8c4-9045-58196a3eed3a@web.de
I tried a little around with WebGL today but couldn't get any further.

Setting
```
webgl.disabled.false
webgl.msaa-force;true
security.sandbox.content.read_path_whitelist;/gnu/store/
```

doesn't help. Not even `security.sandbox.content.level;0` changed
anything for the good.

So it still says:
```
JavaScript warning: https://get.webgl.org/,line 197: Error: WebGL
warning: <SetDimensions>: Failed to create WebGL context: WebGL creation
failed:
* Refused to create native OpenGL context because of blacklist entry:
FEATURE_FAILURE_GLXTEST_FAILED
* Exhausted GL driver options.
```

I'm on an intel laptop with i965 driver.
J
J
Jonathan Brielmaier wrote on 17 May 2020 22:44
(address . 34135@debbugs.gnu.org)
23cb317a-0573-e204-eaa9-cc3bdd97d512@web.de
Ah I forgot to mention all the bug reports on the net which are maybe
correlated to this bug.

There seems to be an issue with libdrm-2.4.101 but Guix is still on
libdrm-2.4.100:
The Mozilla upstream bug is

I also found a bug about hardware acceleration requires LLVM to be
whitelisted, but I couldn't find any "Permission denied" errors in the
logs. While running Icecat with `MOZ_SANDBOX_LOGGING=1` set.
T
T
Tobias Geerinckx-Rice wrote on 23 May 2020 23:14
(name . Jonathan Brielmaier)(address . jonathan.brielmaier@web.de)
875zcmtkv5.fsf@nckx
Jonathan,

Jonathan Brielmaier ???
Toggle quote (3 lines)
> I tried a little around with WebGL today but couldn't get any
> further.

Try this:

- install mesa
- export LD_LIBRARY_PATH="$HOME/.guix-profile/lib"
- set webgl.disabled = false
- set security.sandbox.content.read_path_whitelist = /gnu/store/
(the trailing slash seems to be significant, but you knew that
already)

Works for me,

T G-R
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQT12iAyS4c9C3o4dnINsP+IT1VteQUCXsmSHgAKCRANsP+IT1Vt
eXeIAQDiPSNC3pPexiiKr8JiUeTF6onkSvj89YHH0mrzeztXYQEAwuKJjossJxyT
NDbRQQcx2/A+A+BbL86HOI1WJ3Bs4g8=
=d637
-----END PGP SIGNATURE-----

J
J
Jonathan Brielmaier wrote on 24 May 2020 00:02
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
9d8a5734-ed0b-ad51-c894-96a3042caef5@web.de
On 23.05.20 23:14, Tobias Geerinckx-Rice wrote:
Toggle quote (15 lines)
> Jonathan,
>
> Jonathan Brielmaier ???
>> I tried a little around with WebGL today but couldn't get any further.
>
> Try this:
>
> - install mesa
> - export LD_LIBRARY_PATH="$HOME/.guix-profile/lib"
> - set webgl.disabled = false
> - set security.sandbox.content.read_path_whitelist = /gnu/store/
>  (the trailing slash seems to be significant, but you knew that  already)
>
> Works for me,

Works not for me :(
S
S
Sarah Morgensen wrote on 26 Sep 2021 02:11
(name . Ludovic Courtès)(address . ludo@gnu.org)
86y27kureb.fsf@mgsn.dev
Hi Ludo,

I ran into this bug today, so I took a look through this...

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (43 lines)
> Julien Lepiller <julien@lepiller.eu> skribis:
>
>> Le 21 janvier 2019 09:24:53 GMT+01:00, Ricardo Wurmus <rekado@elephly.net> a écrit :
>>>
>>>Ludovic Courtès <ludo@gnu.org> writes:
>>>
>>>> Hi Julien,
>>>>
>>>> Julien Lepiller <julien@lepiller.eu> skribis:
>>>>
>>>>> Try setting security.sandbox.content.read_path_whitelist to
>>>/gnu/store/
>>>>> (with a leading /) in about:config.
>>>>
>>>> Setting it to “/gnu/store/” (with a trailing slash) works, thank you!
>>>>
>>>> It turns out that setting LIBGL_DRIVERS_PATH is even unnecessary.
>>>>
>>>> I suppose we should patch the default value of
>>>> ‘security.sandbox.content.read_path_whitelist’ in our package. What
>>>do
>>>> people think?
>>>
>>>It isn’t much of a sandbox if all of /gnu/store would be permitted.
>>>Can
>>>this be reduced to the paths of store items that are known at build
>>>time?
>>
>> You'll have to list every library and there dependencies. Is that
>> possible?
>
> That would be possible, yes, though we’d have the build-time
> dependencies rather than the run-time dependencies (since we cannot know
> the run-time dependencies until IceCat is built.)
>
> That said putting all of /gnu/store wouldn’t be that bad I think—at
> least user data remains inaccessible, which is much better than exposing
> /usr on FHS distros.
>
> Thoughts?
>
> Ludo’.

While it looks like preliminary precise whitelisting was done for
ffmpeg, it seems that this approach may require excessive effort for
WebGL. I've attached a security sandbox log generated with

MOZ_SANDBOX_LOGGING=1 icecat https://get.webgl.org

using Guix's default value of security.sandbox.content.read_path_whitelist.

You see that it does whitelist paths from ld.so.conf, but that isn't
enough. It seems some of the paths it tries to read (notably, the last)
aren't even in icecat's inputs. For example, after whitelisting libxcb,
it needs

/gnu/store/w68jrgqqbfcakm27wm4zf7hmpgw294my-libxxf86vm-1.1.4/lib/libXxf86vm.so.1

and after whitelisting that one,

/gnu/store/jwga98k68l0h5c45jx7z4jdjzhfc34vm-libxshmfence-1.3/lib/libxshmfence.so.1

and so on. Both the above are propagated-inputs in mesa. So, it seems
to "properly" fix this, we would need to read *all* input libraries
recursively. I've also attached a successful log (with
read_path_whitelist set to "/gnu/store/").

Until someone devises a method to do that, whitelisting "/gnu/store/"
seems like the best option. I've attached a patch for that.

--
Sarah
Attachment: sandbox.log
Attachment: successful_sandbox.log
From 48e223d33746516010677197ce12b7bf3bb6637c Mon Sep 17 00:00:00 2001
Message-Id: <48e223d33746516010677197ce12b7bf3bb6637c.1632614888.git.iskarian@mgsn.dev>
From: Sarah Morgensen <iskarian@mgsn.dev>
Date: Sat, 25 Sep 2021 17:05:24 -0700
Subject: [PATCH] gnu: icecat: Fix sandbox path whitelist.


* gnu/packages/gnuzilla.scm (icecat)[arguments]<#:phases>
{fix-ffmpeg-runtime-linker}: Move sandbox whitelist logic to...
{set-sandbox-whitelist}: ...here. Set whitelist to "/gnu/store/".
---
gnu/packages/gnuzilla.scm | 30 ++++++++++--------------------
1 file changed, 10 insertions(+), 20 deletions(-)

Toggle diff (45 lines)
diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm
index 431b487fd0..e71df45966 100644
--- a/gnu/packages/gnuzilla.scm
+++ b/gnu/packages/gnuzilla.scm
@@ -1124,26 +1124,16 @@ from forcing GEXP-PROMISE."
;; Arrange to load libavcodec.so by its absolute file name.
(substitute* "dom/media/platforms/ffmpeg/FFmpegRuntimeLinker.cpp"
(("libavcodec\\.so")
- libavcodec))
- ;; Populate the sandbox read-path whitelist as needed by ffmpeg.
- (let* ((mime-info (assoc-ref inputs "shared-mime-info"))
- (libavcodec-runpath (call-with-input-file libavcodec
- (compose elf-dynamic-info-runpath
- elf-dynamic-info
- parse-elf
- get-bytevector-all)))
- (whitelist (cons (string-append mime-info "/share/mime/")
- (map (lambda (dir)
- (string-append dir "/"))
- libavcodec-runpath)))
- (whitelist-string (string-join whitelist ","))
- (port (open-file "browser/app/profile/icecat.js" "a")))
- (format #t "setting 'security.sandbox.content.read_path_whitelist' to '~a'~%"
- whitelist-string)
- (format port "~%pref(\"security.sandbox.content.read_path_whitelist\", ~S);~%"
- whitelist-string)
- (close-output-port port))
- #t)))
+ libavcodec)))))
+ (add-after 'fix-ffmpeg-runtime-linker 'set-sandbox-whitelist
+ (lambda _
+ (let ((port (open-file "browser/app/profile/icecat.js" "a"))
+ (whitelist-string "/gnu/store/"))
+ (format #t "setting 'security.sandbox.content.read_path_whitelist' to '~a'~%"
+ whitelist-string)
+ (format port "~%pref(\"security.sandbox.content.read_path_whitelist\", ~S);~%"
+ whitelist-string)
+ (close-output-port port))))
(replace 'bootstrap
(lambda _
(invoke "sh" "-c" "autoconf old-configure.in > old-configure")

base-commit: 69f37702dfcda776a190d5c40fad8518469ce3c4
--
2.33.0
M
M
Mark H Weaver wrote on 26 Sep 2021 11:50
87h7e7ekcq.fsf@netris.org
Hi Sarah,

Thanks for looking into this, and more generally for all the work you've
been putting into Guix lately.

Sarah Morgensen <iskarian@mgsn.dev> writes:
Toggle quote (4 lines)
> While it looks like preliminary precise whitelisting was done for
> ffmpeg, it seems that this approach may require excessive effort for
> WebGL.

Perhaps, but I don't think that's yet been established.

For what it's worth, as the maintainer of our IceCat package since the
early years of Guix, I'm uncomfortable allowing the IceCat sandbox to
obtain a complete list of software (with precise versions) installed on
our users' systems. I hope that we will not give up so easily on
precise whitelisting.

Toggle quote (11 lines)
> For example, after whitelisting libxcb,
> it needs
>
> /gnu/store/w68jrgqqbfcakm27wm4zf7hmpgw294my-libxxf86vm-1.1.4/lib/libXxf86vm.so.1
>
> and after whitelisting that one,
>
> /gnu/store/jwga98k68l0h5c45jx7z4jdjzhfc34vm-libxshmfence-1.3/lib/libxshmfence.so.1
>
> and so on.

I agree that this approach would be very tedious, but there are better
ways. I faced a similar problem before I wrote the existing precise
whitelisting code (which your proposed patch would remove): 'libavcodec'
had too many dependencies, and I didn't want to maintain a list of them
all. I eventually realized that 'libavcodec's RUNPATH would cover most
of what was needed, and in fact only one additional directory needed to
be added manually.

Would you like to try adding the RUNPATHs of Mesa's libraries to the
whitelist, i.e. using the same code that computes 'libavcodec-runpath'?

To find the directories that must be added manually, how about scraping
the *successful* log for a list of file names in /gnu/store and
distilling it down to a set of packages?

Toggle quote (4 lines)
> Both the above are propagated-inputs in mesa. So, it seems
> to "properly" fix this, we would need to read *all* input libraries
> recursively.

Even if we had to do that, it wouldn't be an excessive amount of effort.
We already have the code to extract the RUNPATH of a library and add it
to the whitelist. Doing that for all libraries found in FOO/lib/*.so
for all inputs FOO shouldn't be much harder, no?

What do you think? Would you like to try it?

Regards,
Mark

--
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about https://stallmansupport.org.
M
M
Maxim Cournoyer wrote on 29 Aug 2023 22:48
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 34135@debbugs.gnu.org)
87msy98thw.fsf@gmail.com
Hi,

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (39 lines)
> Hello,
>
> If you enable WebGL support in ‘about:config’, then stop it and run:
>
> $ export LIBGL_DRIVERS_PATH=$(guix build mesa)/lib/dri
> $ icecat https://get.webgl.org
> 1547912837231 addons.webextension.tortm-browser-button@jeremybenthum WARN Please specify whether you want browser_style or not in your browser_action options.
> 1547912837231 addons.webextension.https-everywhere@eff.org WARN Please specify whether you want browser_style or not in your browser_action options.
> 1547912837232 addons.webextension.{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} WARN Please specify whether you want browser_style or not in your browser_action options.
> JavaScript warning: moz-extension://b84ee99d-7e50-4975-9d16-3806d330a3b2/lib/adblockplus.js, line 0: Successfully compiled asm.js code (total compilation time 1ms; not stored in cache (too small )
> libGL error: MESA-LOADER: failed to retrieve device information
> libGL error: unable to load driver: i915_dri.so
> libGL error: driver pointer missing
> libGL error: failed to load driver: i915
> libGL error: MESA-LOADER: failed to retrieve device information
> libGL error: unable to load driver: i915_dri.so
> libGL error: driver pointer missing
> libGL error: failed to load driver: i915
> libGL error: unable to load driver: swrast_dri.so
> libGL error: failed to load driver: swrast
> JavaScript warning: https://get.webgl.org/, line 193: Error: WebGL warning: Failed to create WebGL context: WebGL creation failed:
> * Error during native OpenGL init.
> * Exhausted GL driver caps.
> * Exhausted GL driver options.
> JavaScript warning: https://get.webgl.org/, line 197: Error: WebGL warning: Failed to create WebGL context: WebGL creation failed:
> * Error during native OpenGL init.
> * Exhausted GL driver caps.
> * Exhausted GL driver options.
>
> and the web page reads:
>
> While your browser seems to support WebGL, it is disabled or
> unavailable.
>
> Weird thing is that glxgears and glxinfo (from ‘mesa-utils’) both work
> well.
>
> Thoughts?

I don't reproduce this issue, using Guix 9f4b6bc with IceCat version
102.14.0-guix0-preview1, although I must *not* set LIBGL_DRIVERS_PATH
the way you did otherwise it fails.

I'm using an nvidia 8800 GTS card with the nouveau driver, and the
spinning cube displays fine at https://get.webgl.org/.

Is it still a problem for you?

--
Thanks,
Maxim
L
L
Ludovic Courtès wrote on 9 Sep 2023 12:52
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 34135-done@debbugs.gnu.org)
875y4jzkhg.fsf@gnu.org
Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

Toggle quote (7 lines)
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> If you enable WebGL support in ‘about:config’, then stop it and run:
>>
>> $ export LIBGL_DRIVERS_PATH=$(guix build mesa)/lib/dri
>> $ icecat https://get.webgl.org

[...]

Toggle quote (17 lines)
>> While your browser seems to support WebGL, it is disabled or
>> unavailable.
>>
>> Weird thing is that glxgears and glxinfo (from ‘mesa-utils’) both work
>> well.
>>
>> Thoughts?
>
> I don't reproduce this issue, using Guix 9f4b6bc with IceCat version
> 102.14.0-guix0-preview1, although I must *not* set LIBGL_DRIVERS_PATH
> the way you did otherwise it fails.
>
> I'm using an nvidia 8800 GTS card with the nouveau driver, and the
> spinning cube displays fine at https://get.webgl.org/.
>
> Is it still a problem for you?

Nope, closing!

Ludo’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 34135@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 34135
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch