From ArchWiki

Everything is syncing except for password

"rm ~/.config/chromium/Default/Login\ Data*" is destructive action without any challenge to the user. The user who executes this command will lose all of his defined passwords Mozlima (talk) 19:07, 28 February 2021 (UTC)Reply[reply]

Certainly. But I would argue that the usage of rm always causes data loss. So this is something obvious in my opinion, also the user is usually expected to have backups. This is not the reason why I undid your edit. The reason for that is described in the comment, it needed mostly language improvements.
-- NetSysFire (talk) 01:02, 1 March 2021 (UTC)Reply[reply]

Use of official Chrome API keys in Chromium

If this thread is any indication of Arch's strategy going forward, we might be wary of linking readers of this wiki to guides for using the official Chrome API keys with the chromium package.

On the other hand, it's not clear to me if Google will continue after March 15th to allow use of their APIs with individually issued API keys, as long as they are not shared?

Compwiztobe (talk) 08:27, 9 March 2021 (UTC)Reply[reply]

More on the use of individually issued keys:, thanks to Foutrelis.
Compwiztobe (talk) 11:43, 9 March 2021 (UTC)Reply[reply]

"Add another account" on Google sites doesn't stick

I noticed this at some point since chromium stopped supporting the Sync API without your own OAuth credentials (see that separate discussion for more details). When using a google service such as or, normally we can select the profile icon and "Add another account" to have multiple logins active (note this is website login, NOT chromium login). On windows (and formerly in chromium on linux) these added accounts remain logged in, but now in chromium on linux it seems every 24 hours or so any additional accounts are logged out, making it quite a hassle to manage documents and email across multiple accounts, even with the same persistent browser session over several days (need to log in to additional accounts again about every day). Again, this is not the case on windows, additional accounts remain logged in.

Anyone know more about this, or have a way to work around it?

Compwiztobe (talk) 10:09, 27 July 2021 (UTC)Reply[reply]

I have the exact same issue and it's really interesting to hear that this behavior doesn't happen on Windows. I thought it was the API (missing API) but with this I'm sure it's just chromium on linux problem. N0k0m3 (talk) 23:28, 31 October 2021 (UTC)Reply[reply]
Long time ago, but still seeing this issue, and I should clarify that it's Chrome official build from Google on Windows that behaves as expected, not chromium on Windows (untested). On Arch, I've also since started using the google-chrome-stable package from AUR for limited use, and this works fine for keeping multiple accounts logged in to google services, as well as using the Sync API with a Google-hosted enterprise account for work (non google domain), neither of which seem to work with chromium on Arch (I believe I even tried adding my API keys to the cloud console for the enterprise acct, but I don't recall exactly..). --Compwiztobe (talk) 11:59, 19 September 2023 (UTC)Reply[reply]

Hardware video acceleration still not work for proprietary NVIDIA driver

For me,adding the --disable-vulkan flag works.Here is the the minimal version that works on my computer:


However,the disadvantage of this way is that the gpu process sometimes crashes.

—This unsigned comment is by 13905069 (talk) 2023-01-10T02:52:10. Please sign your posts with ~~~~!

From the logs (or maybe the source code), do you have any idea what graphics API it is that Chromium is instead using? I would probably expect that that flag disables Vulkan, and then uses OpenGL; either option being proxied through Angle. -- CodingKoopa (talk) 22:46, 10 January 2023 (UTC)Reply[reply]
While playing the video,here is the log:
[469879:469879:0111/] : Passthrough is not supported, GL is desktop, ANGLE is
[469879:469879:0111/] : Attempt to read from an uninitialized SharedImage. Initialized region: (0, 0, 0, 0) Size: (720, 1280)
[469879:469879:0111/] : [.RendererMainThread-0x28f001ce1000]GL ERROR :GL_INVALID_OPERATION : SharedImageProviderImpl::OpenSharedImageForRead: Couldn't access shared image for mailbox:B1:50:6D:64:9A:C2:F9:31:57:A8:C3:8E:F2:42:18:05
[469879:469879:0111/] : [.RendererMainThread-0x28f001ce1000]GL ERROR :GL_INVALID_OPERATION : glRasterCHROMIUM: RasterCHROMIUM: serialization failure
I don't konw exactly which is using,because GL and ANGLE appear at the same time.When Vulkan is enabled,no error appeared(except for the first line above),.By the way,my graphics card is NVIDIA GeForce GTX 1650,and my driver is the latest.
13905069 (talk) 02:22, 11 January 2023 (UTC)Reply[reply]

GPU acceleration enabled by default

From the article: “By default Chromium on Linux does not use any GPU acceleration.” If I start Chromium without any flags, chrome://gpu/ shows “Hardware accelerated” several times.

--Markus00000 (talk) 17:48, 25 February 2023 (UTC)Reply[reply]

Neat, maybe they consider it stable enough to enable it by default on some systems. The article can be updated once an accompanying commit, bug report, or article is found. Otherwise, I would hold off because video acceleration is notoriously messy and there could be a confounding variable. -- CodingKoopa (talk) 03:20, 7 March 2023 (UTC)Reply[reply]

New flag for hardware video acceleration with VA-API

Using UHD Graphics 630, --enable-features=VaapiVideoDecoder did not work. Neither did adding --enable-features=VaapiIgnoreDriverChecks or --disable-features=UseChromeOSDirectVideoDecoder.

This thread mentions --enable-features=VaapiVideoDecodeLinuxGL. Using only this flag worked. I am not sure how to best integrate it into the current section.

Markus00000 (talk) 06:32, 31 October 2023 (UTC)Reply[reply]

+1 from me on this one. Seemingly none of the old tricks work anymore except this new flag (alone). On Intel HD Graphics 520 hardware. Using LIBVA_DRIVER_NAME=iHD. With google-chrome-beta. Both X11 and Wayland tested.
~~~ Greyltc (talk) 21:07, 10 November 2023 (UTC)Reply[reply]