chromium-browser file:///myfile.html hangs while loading; --use-gl=egl is the fix

[tinker2much]

Try to open the attached simple html file (remove the extra ".txt") using chromium-browser on bullseye 32 or 64, on any of [pi0w, pi2, pi02w, pi3a+, pi3b]:

chromium-browser file:///home/pi/chromium_egl.html

It will hang while loading and eventually have to be killed.

Apply this line, try again, and it will work, as it still does on buster WITHOUT such fix: echo 'export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --use-gl=egl"' | sudo tee /etc/chromium.d/egl

chromium_egl.html.txt

Some facts about the system I just tried this on: Zero2 W 512MB armv7l bullseye 32 5.15.32-v7+

1538 SMP Thu Mar 31 19:38:48 BST 2022

Chromium 98.0.4758.106 Built on Raspbian , running on Raspbian 11

NOTE: As a two-for-one, this also fixes my issues with using chromium-browser in kiosk mode, but it would be more work to give you a cut down version of the cgi program I use in that application.

[HoldOffHunger]

Hey hey, is this the same problem as https://github.com/RPi-Distro/chromium-browser/issues/28 ?

[tinker2much]

Yes, I think this is all converging, with various trails and clues having met up on the Raspberry Pi forum. I didn't know that taoteh1221 was going to post the solution in #28. Some people had trouble with various websites. I originally had trouble with my cgi kiosk application, where the html is generated. I couldn't easily provide my cgi app, but I found that the same thing happened with a local html file via file://, so that's what I provided for an easily reproducible example. Let's hope this fixes everybody's problems.

[tinker2much]

I saw this forum post by michalng, where he gives the solution; a few posts before that he actually mentions issue #28. In any case, I think he gets the credit.

[HoldOffHunger]

Um, okay.

[tinker2much]

I have to report that on bullseye 64 (same kernel number as the 02W above) the same chromium-browser version (98.0.4758.106) works fine even WITHOUT the above-mentioned egl fix, on a Pi4-4GB and a Pi4-8GB, .

So there's a memory threshold? I don't have a Pi4 with 1GB or 2GB to test this on. But under bullseye 64 on a Pi3B with 1GB, the egl line needed. And under bullseye 32 on a 1GB Pi2 and the 512MB 0W, 02W, and 3a+, it's needed.

[tinker2much]

Yesterday I installed the just released version of chromium-browser (101.0.4951.57-rpt1) over the recent version (98.0.4758.106-rpt1). It is great to see the pi mods applied to such a recent chromium (just a pinch back from the latest you can get in a flatpak.) This new version partly changes or improves the mis-behavior I reported in this issue.

FACT 1: The 101 version WILL open that html file WITH or WITHOUT the egl line being applied. However, it seems to take longer without, and it's almost like it tries twice with some kind of failure the first time. See attached stdout/stderrs copied from a terminal session where I first tried it WITH the egl line, then removed such line, then tried it WITHOUT the line. See the "exit_code=512". Note: this was run on a Pi0W. chromium_with_and_without_egl.txt (As I said before, I was really wanting a recent chromium with pi mods that allowed me to run my kiosk application on low-powered pi's, the existing chromium-browser versions having started to fail on bullseye. It was really hard to figure out how to give you an easy subset of my kiosk app, but failing to open this simple html file seemed like a good proxy failure case.)

FACT 2: This 101 version DOES allow my kiosk application to run on various pi models WITH or WITHOUT the proposed egl fix, although on some models it takes longer WITHOUT the egl line (more noticeably on less powerful models.) I wonder if the exit_code=512 error is happening behind the scenes there too, causing a second attempt that increases the time. All test cases are the time in seconds between typing "startx" and getting the opening screen of my app to appear in chromium-browser. All cases were run at least 3X, with the times averaged. All were on bullseye32 except for the Pi3B which was bullseye64: PiZeroW: with_egl=60, without= 78 PiZero2W: with=28, without=32 Pi3A+: with=32, without=29 Pi3B: with=20, without=20 I hope any of this helps you.

[XECDesign]

Many thanks for re-testing!

@jc-kynesim Shouldn't we be default to egl anyway? AIUI, that line shouldn't have any effect.

[tinker2much]

I noticed your latest -rpt2 release so I reran some tests again.

It doesn't seem to change Fact 1 behavior, see above. Adding the explicit egl line STILL makes it run faster, with fewer error messages in stderr/stdout. See attached file, showing behavior and timings with and without the manual egl line; note the error_code=512. chromium_with_and_without_egl_rpt2.txt Also, regarding FACT 2 above, my kiosk application under chromium-browser still runs faster with the manual egl line. I only reran the pi0w timings, but they're each within a second of the ones before (timings are in seconds from startx to my kiosk screen appearing.)

pi0w: without the fix: 79, 78, 80 == average 79 seconds

WITH the egl fix line: 62, 61, 60 == average 61 seconds

Summary: In my tests, this doesn't seem to be an improvement over 101-rpt1. It is still an improvement over 98, because I couldn't even run the simple file-based test before without the manual egl line.

[XECDesign]

Yup, the rpt2 bump was to fix #32, so I wouldn't expect the behaviour to be any different.