GNU bug report logs -
#34135
IceCat lacks WebGL support
Previous Next
Reported by: Ludovic Courtès <ludo <at> gnu.org>
Date: Sat, 19 Jan 2019 15:50:02 UTC
Severity: normal
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34135 in the body.
You can then email your comments to 34135 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org:
bug#34135; Package
guix.
(Sat, 19 Jan 2019 15:50:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ludovic Courtès <ludo <at> gnu.org>:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org.
(Sat, 19 Jan 2019 15:50:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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 <at> jeremybenthum WARN Please specify whether you want browser_style or not in your browser_action options.
1547912837231 addons.webextension.https-everywhere <at> 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’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#34135; Package
guix.
(Sat, 19 Jan 2019 17:09:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 34135 <at> debbugs.gnu.org (full text, mbox):
Le Sat, 19 Jan 2019 16:49:02 +0100,
Ludovic Courtès <ludo <at> gnu.org> a écrit :
> 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 <at> jeremybenthum WARN
> Please specify whether you want browser_style or not in your
> browser_action options. 1547912837231
> addons.webextension.https-everywhere <at> 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.
Information forwarded
to
bug-guix <at> gnu.org:
bug#34135; Package
guix.
(Sun, 20 Jan 2019 22:46:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 34135 <at> debbugs.gnu.org (full text, mbox):
Hi Julien,
Julien Lepiller <julien <at> 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?
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#34135; Package
guix.
(Mon, 21 Jan 2019 08:26:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 34135 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hi Julien,
>
> Julien Lepiller <julien <at> 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
Information forwarded
to
bug-guix <at> gnu.org:
bug#34135; Package
guix.
(Mon, 21 Jan 2019 08:50:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 34135 <at> debbugs.gnu.org (full text, mbox):
Le 21 janvier 2019 09:24:53 GMT+01:00, Ricardo Wurmus <rekado <at> elephly.net> a écrit :
>
>Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Hi Julien,
>>
>> Julien Lepiller <julien <at> 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.
Information forwarded
to
bug-guix <at> gnu.org:
bug#34135; Package
guix.
(Mon, 21 Jan 2019 09:55:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 34135 <at> debbugs.gnu.org (full text, mbox):
Julien Lepiller <julien <at> lepiller.eu> skribis:
> Le 21 janvier 2019 09:24:53 GMT+01:00, Ricardo Wurmus <rekado <at> elephly.net> a écrit :
>>
>>Ludovic Courtès <ludo <at> gnu.org> writes:
>>
>>> Hi Julien,
>>>
>>> Julien Lepiller <julien <at> 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’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#34135; Package
guix.
(Thu, 24 Jan 2019 14:03:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 34135 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
> 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
Information forwarded
to
bug-guix <at> gnu.org:
bug#34135; Package
guix.
(Tue, 12 May 2020 18:21:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 34135 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-guix <at> gnu.org:
bug#34135; Package
guix.
(Sun, 17 May 2020 20:25:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 34135 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-guix <at> gnu.org:
bug#34135; Package
guix.
(Sun, 17 May 2020 20:45:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 34135 <at> debbugs.gnu.org (full text, mbox):
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:
https://gitlab.freedesktop.org/mesa/drm/-/issues/39
The Mozilla upstream bug is
https://bugzilla.mozilla.org/show_bug.cgi?id=1623885
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.
https://github.com/netblue30/firejail/issues/2106
Information forwarded
to
bug-guix <at> gnu.org:
bug#34135; Package
guix.
(Sat, 23 May 2020 21:15:02 GMT)
Full text and
rfc822 format available.
Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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,
T G-R
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#34135; Package
guix.
(Sat, 23 May 2020 21:15:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org:
bug#34135; Package
guix.
(Sat, 23 May 2020 22:04:01 GMT)
Full text and
rfc822 format available.
Message #41 received at submit <at> debbugs.gnu.org (full text, mbox):
On 23.05.20 23:14, Tobias Geerinckx-Rice wrote:
> 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 :(
Information forwarded
to
bug-guix <at> gnu.org:
bug#34135; Package
guix.
(Sat, 23 May 2020 22:04:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org:
bug#34135; Package
guix.
(Sun, 26 Sep 2021 00:13:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 34135 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ludo,
I ran into this bug today, so I took a look through this...
Ludovic Courtès <ludo <at> gnu.org> writes:
> Julien Lepiller <julien <at> lepiller.eu> skribis:
>
>> Le 21 janvier 2019 09:24:53 GMT+01:00, Ricardo Wurmus <rekado <at> elephly.net> a écrit :
>>>
>>>Ludovic Courtès <ludo <at> gnu.org> writes:
>>>
>>>> Hi Julien,
>>>>
>>>> Julien Lepiller <julien <at> 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
[sandbox.log (text/plain, attachment)]
[successful_sandbox.log (text/plain, attachment)]
[0001-gnu-icecat-Fix-sandbox-path-whitelist.patch (text/x-patch, inline)]
From 48e223d33746516010677197ce12b7bf3bb6637c Mon Sep 17 00:00:00 2001
Message-Id: <48e223d33746516010677197ce12b7bf3bb6637c.1632614888.git.iskarian <at> mgsn.dev>
From: Sarah Morgensen <iskarian <at> mgsn.dev>
Date: Sat, 25 Sep 2021 17:05:24 -0700
Subject: [PATCH] gnu: icecat: Fix sandbox path whitelist.
Fixes <https://issues.guix.gnu.org/34136>.
* 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(-)
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
Information forwarded
to
bug-guix <at> gnu.org:
bug#34135; Package
guix.
(Sun, 26 Sep 2021 09:53:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 34135 <at> debbugs.gnu.org (full text, mbox):
Hi Sarah,
Thanks for looking into this, and more generally for all the work you've
been putting into Guix lately.
Sarah Morgensen <iskarian <at> mgsn.dev> writes:
> 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.
> 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?
> 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>.
Information forwarded
to
bug-guix <at> gnu.org:
bug#34135; Package
guix.
(Tue, 29 Aug 2023 20:50:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 34135 <at> debbugs.gnu.org (full text, mbox):
Hi,
Ludovic Courtès <ludo <at> gnu.org> writes:
> 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 <at> jeremybenthum WARN Please specify whether you want browser_style or not in your browser_action options.
> 1547912837231 addons.webextension.https-everywhere <at> 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
Reply sent
to
Ludovic Courtès <ludo <at> gnu.org>:
You have taken responsibility.
(Sat, 09 Sep 2023 10:54:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Ludovic Courtès <ludo <at> gnu.org>:
bug acknowledged by developer.
(Sat, 09 Sep 2023 10:54:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 34135-done <at> debbugs.gnu.org (full text, mbox):
Hi Maxim,
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
> Ludovic Courtès <ludo <at> 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
[...]
>> 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’.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 07 Oct 2023 11:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 199 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.