Arch Linux User Repository

✔ Do not flag this package out-of-date.

It updates automatically on each install.

@DAC324 I'm curious, are you still having issues with pulseaudio? I'm encountering the same and wonder if it's just a me thing.

Added quotes to the user flags while stripping comment lines.

Current snapshot (92.0.4511.0) has a problem with pulseaudio:

Failed to create secure directory (/run/user/1000/pulse): Operation not permitted
The futex facility returned an unexpected error code.
Received signal 6
#0 0x5638bf3cabf9 (/opt/chromium-snapshot/chrome+0x6523bf8)
#1 0x5638bf3373d3 (/opt/chromium-snapshot/chrome+0x64903d2)
#2 0x5638bf3ca721 (/opt/chromium-snapshot/chrome+0x6523720)
#3 0x7f054d6af960 (/usr/lib/libpthread-2.33.so+0x1395f)
#4 0x7f054c86bef5 __GI_raise
#5 0x7f054c855862 __GI_abort
#6 0x7f054c8adf38 __libc_message
#7 0x7f054c8adf6a __GI___libc_fatal
#8 0x7f054d6b1960 __futex_abstimed_wait_common64
#9 0x7f054d6ab260 __pthread_cond_wait
#10 0x5638bf3d7a7f (/opt/chromium-snapshot/chrome+0x6530a7e)
#11 0x5638bf3d8351 (/opt/chromium-snapshot/chrome+0x6531350)
#12 0x5638bf3d7faf (/opt/chromium-snapshot/chrome+0x6530fae)
#13 0x5638bf34f516 (/opt/chromium-snapshot/chrome+0x64a8515)
#14 0x5638bf39f097 (/opt/chromium-snapshot/chrome+0x64f8096)
#15 0x5638bf3705bb (/opt/chromium-snapshot/chrome+0x64c95ba)
#16 0x5638bf29dc8b (/opt/chromium-snapshot/chrome+0x63f6c8a)
#17 0x5638bf2d384c (/opt/chromium-snapshot/chrome+0x642c84b)
#18 0x5638bf2d4b02 (/opt/chromium-snapshot/chrome+0x642db01)
#19 0x5638bf2d213d (/opt/chromium-snapshot/chrome+0x642b13c)
#20 0x5638bf2d2add (/opt/chromium-snapshot/chrome+0x642badc)
#21 0x5638bc20e249 ChromeMain
#22 0x7f054c856b25 __libc_start_main
#23 0x5638bc20dfea _start
  r8: 0000000000000000  r9: 00007ffc1b5d89d0 r10: 0000000000000008 r11: 0000000000000246
 r12: 00007ffc1b5d8c30 r13: 0000000000001000 r14: 0000000000000000 r15: 00007f054a16f000
  di: 0000000000000002  si: 00007ffc1b5d89d0  bp: 00007ffc1b5d8cf0  bx: 00007f054b7e2d00
  dx: 0000000000000000  ax: 0000000000000000  cx: 00007f054c86bef5  sp: 00007ffc1b5d89d0
  ip: 00007f054c86bef5 efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
 trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]

@mrxx: Reason why the user agent is so important for me: Google as well as some other services refuse to work properly if the browser's user agent is not recognized.

As for the comments in ~/.config/chromium-flag.conf to be handled correctly: Replace the cat command by grep -v '^#' where the file is read:

# Allow users to override command-line options
if [[ -f ~/.config/chromium-flags.conf ]]; then
   CHROMIUM_USER_FLAGS="$(grep -v '^#' ~/.config/chromium-flags.conf)"
fi

This causes all lines starting with one single # char to be ignored.

@mrxx: Indeed, changing the call to Chrome in /usr/bin/chromium-snapshot-bin to

exec /opt/chromium-snapshot/chrome "$CHROMIUM_USER_FLAGS" "$@"

does the trick. With this, I can keep my user agent string in ~/.config/chromium-flags.conf as usual :)

Please do not call /opt/chromium-snapshot/chrome directly. Use the wrapper and quote the parameter(s):

chromium-snapshot-bin "$TESTFLAG"

@mrxx Thanks for updating so quickly. Unfortunately, at least here, it does not help. As soon as I add the user agent line to ~/.config/chromium-flag.conf, I get the same behavior again. The user agent is truncated at the first space, and the remainder is treated as separate commands.

I investigated a little bit further.

The launcher reads ~/.config/chromium-flags.conf and puts its contents into one single variable which is then passed to chrome on the command line. So far, so good, but transferring something like

--user-agent="Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36"

into a variable seems to fail, perhaps because of the presence of double quotes and spaces in the string. When I start Chrome from the command line with

exec /opt/chromium-snapshot/chrome --user-agent="Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36"

the flag is correctly recognized. However, when I first transfer the flag in a variable, let's say like

TESTFLAG="--user-agent=\"Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36\""

I get the correct contents:

echo $TESTFLAG
--user-agent="Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36"

But when I now try to start Chrome with that variable

exec /opt/chromium-snapshot/chrome $TESTFLAG "$@"

it fails to pass the contents of $TESTFLAG correctly to Chrome but stops at the first space.

Looks like /usr/bin/chromium-snapshot-bin needs to be amended. The line

exec /opt/chromium-snapshot/chrome $CHROMIUM_USER_FLAGS "$@"

has to be amended by double quotes like

exec /opt/chromium-snapshot/chrome "$CHROMIUM_USER_FLAGS" "$@"

Thanks for pointing this out, DAC324. I've added quotes to the launch parameters.

The launcher seems to be unable to handle comments in ~/.config/chromium-flags.conf, and it is also unable to handle spaces in any of the command line flags.

For example,

--user-agent="Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36"

causes the launcher to stop reading the user agent string at the first space and passing everything else to the browser separately. You end up with a user agent string of "Mozilla/5.0 and a bunch of pages opened with all the other parts of this user agent string as URLs to be opened. Escaping the spaces does not help. What can I do to pass the user agent nevertheless to the browser?

Note to anyone using this for the new Wayland support: You'll need to run using the following flags for a native Wayland experience --enable-features=UseOzonePlatform --ozone-platform=wayland