Autofill has stopped turning up

Description of the issue:

For some reason, I’ve lost the ability to use autofill - it just doesn’t show up anymore when I’ve selected a UN/PW/address input field, e.g.:

I can right-click and I see:

but when I try clicking on it, nothing happens.

This is consistent across every website I’ve tried and includes payment details and physical address - essentially rendering the password manager and address/payment autofills nonfunctional. I still get the key in the address bar:

image

and from there I can copy and paste stuff, but I’m sure you’ll agree this is not how daily usage of the password manager/etc is supposed to be.

How can this issue be reproduced?

Unfortunately, I have no idea :disappointed_face:

Expected behaviour is to see the little pop-up that I can click to autofill the details…

Brave Version( check About Brave):

Additional Information:

Extra note: Nothing shows up when I start typing, either

same issue on my OnePlus 9 Pro with Oxygen OS 14.0…

You know, yesterday while helping someone with DNS (in another thread) I did notice it didn’t autofill my Firewall’s login, and I had to actually pull up the saved password and type it in. I thought nothing of it honestly.

On Archive.org:

I am seeing the popup, and it is working. But, on my Firewall?

Nadda, no popup whatsoever. And I absolutely can confirm it’s there:

So yea, for me at least, some forms are outright not working, OPNsense firewalls for example, but on some sites it still is.

For reference, I’m on: 1.85.111, but I do believe I ran into this yesterday before I updated, which would have been the previous release.

1 Like

Strange, I’ll have to test further - but it’s been universal for me.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Description of the issue:

For a few months now, autofill does not pop up for any username/password, physical address or payment field.

The key shows in the top right of the address bar but the popup/dialog/whatever it’s called that used to be created nearby (X input field) on a website no longer appears for me to select credentials from, resulting in me needing to type everything in as if the password manager/autofill never existed (though in some occasions I can click on the key and copy and paste, but this is not intended workflow and is poor practice). Right-clicking on an input field shows “Select password” but if I click it, nothing happens.

How can this issue be reproduced?

Unfortunately unknown… it just stopped working one day.

Expected result: Autofill works as normal by appearing with saved UN/PW/address/payment details for me to select from, when an input field for such data is clicked/highlighted/etc.

Brave Version( check About Brave):

image

Additional Information:

  • CachyOS Linux (Arch, Wayland)

If this sounds familiar, I already made this post a while ago, but nothing ever came of it, so I’m here to ask about it once more, as this is frustrating

@darkmann you never came back to report on anything after mentioning needing to test further. Then it seems this auto locked due to lack of responses. I just reopened.

They did release new update today, so maybe try updating on that just to see if anything works.

But then also would be good to know if:

  • This is happening on all websites?
  • You are using extensions?
  • It happens in a new profile, if you made one?
  • The same things happens in Brave Beta and/or Brave Nightly.

@Mattches also going to tag you on this since went under the radar before. Not sure if you have any ideas.

OK so yes this is all websites.

I am using some extensions:

I’m… not sure how to make a new profile.

Can confirm the same happens in Beta. (which by all means is a new profile, I installed it just now to test - hence nowt to do with extensions). Logged into a site, saved my creds, logged out, no box when I select UN or PW fields.

Terminal yields some guff I don’t think is related but I’ll include anyway:

darkmann@darkWS:~$ brave-beta
WARNING: radv is not a conformant Vulkan implementation, testing use only.
[419484:419484:0115/233222.934084:ERROR:chrome/browser/ui/views/user_education/impl/browser_user_education_interface_impl.cc:154] Attempting to show IPH IPH_DiscardRing before browser initialization complete; IPH will not be shown.
[419484:419484:0115/233223.129774:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:296] Unable to set image transfer function.
[419484:419484:0115/233223.129781:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:214] Failed to populate image description for color space {r:[0.6160, 0.3263], g:[0.2512, 0.5987], b:[0.1429, 0.0525], w:[0.3127, 0.3290]}, transfer:SRGB, matrix:RGB, range:FULL}
[419484:419484:0115/233223.129864:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:296] Unable to set image transfer function.
[419484:419484:0115/233223.129867:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:214] Failed to populate image description for color space {r:[0.6160, 0.3263], g:[0.2512, 0.5987], b:[0.1429, 0.0525], w:[0.3127, 0.3290]}, transfer:SRGB, matrix:RGB, range:FULL}
[419484:419484:0115/233223.129871:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_management_surface.cc:63] Failed to get image description for color space.
[419484:419484:0115/233223.160714:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:296] Unable to set image transfer function.
[419484:419484:0115/233223.160722:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:214] Failed to populate image description for color space {r:[0.6160, 0.3263], g:[0.2512, 0.5987], b:[0.1429, 0.0525], w:[0.3127, 0.3290]}, transfer:SRGB, matrix:RGB, range:FULL}
[419484:419484:0115/233223.233433:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:296] Unable to set image transfer function.
[419484:419484:0115/233223.233442:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:214] Failed to populate image description for color space {r:[0.6160, 0.3263], g:[0.2512, 0.5987], b:[0.1429, 0.0525], w:[0.3127, 0.3290]}, transfer:SRGB, matrix:RGB, range:FULL}
[419484:419484:0115/233224.968560:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:296] Unable to set image transfer function.
[419484:419484:0115/233224.968568:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:214] Failed to populate image description for color space {r:[0.6160, 0.3263], g:[0.2512, 0.5987], b:[0.1429, 0.0525], w:[0.3127, 0.3290]}, transfer:SRGB, matrix:RGB, range:FULL}
[419484:419484:0115/233224.968610:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:296] Unable to set image transfer function.
[419484:419484:0115/233224.968612:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:214] Failed to populate image description for color space {r:[0.6160, 0.3263], g:[0.2512, 0.5987], b:[0.1429, 0.0525], w:[0.3127, 0.3290]}, transfer:SRGB, matrix:RGB, range:FULL}
[419484:419484:0115/233224.968617:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_management_surface.cc:63] Failed to get image description for color space.
[419484:419484:0115/233227.980540:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:296] Unable to set image transfer function.
[419484:419484:0115/233227.980548:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:214] Failed to populate image description for color space {r:[0.6160, 0.3263], g:[0.2512, 0.5987], b:[0.1429, 0.0525], w:[0.3127, 0.3290]}, transfer:SRGB, matrix:RGB, range:FULL}
[419484:419484:0115/233227.980609:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:296] Unable to set image transfer function.
[419484:419484:0115/233227.980612:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:214] Failed to populate image description for color space {r:[0.6160, 0.3263], g:[0.2512, 0.5987], b:[0.1429, 0.0525], w:[0.3127, 0.3290]}, transfer:SRGB, matrix:RGB, range:FULL}
[419484:419484:0115/233227.980617:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_management_surface.cc:63] Failed to get image description for color space.
[419484:419484:0115/233227.992773:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:296] Unable to set image transfer function.
[419484:419484:0115/233227.992778:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:214] Failed to populate image description for color space {r:[0.6160, 0.3263], g:[0.2512, 0.5987], b:[0.1429, 0.0525], w:[0.3127, 0.3290]}, transfer:SRGB, matrix:RGB, range:FULL}
[419484:419484:0115/233228.007048:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:296] Unable to set image transfer function.
[419484:419484:0115/233228.007052:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:214] Failed to populate image description for color space {r:[0.6160, 0.3263], g:[0.2512, 0.5987], b:[0.1429, 0.0525], w:[0.3127, 0.3290]}, transfer:SRGB, matrix:RGB, range:FULL}


So far tested with Onshape and Gmail on the Beta application. Same results for both. Nothing turns up if I type the first character of the saved data, either.

Normally would be the hamburger (three line menu) → More tools → add new profile.

This would have done a clean profile with most settings at default and no extensions installed. Just is a good troubleshooting step.

Yeah, if you have it with no extensions then is a sign there.

When you installed, which method did you use? I’m speaking of all the options at listed at https://brave.com/linux/

These are the areas typically restricted by keyring. Or rather, the password store backend. As I’m not familiar with Linux at all, I’m limited on answering. I’m not sure if someone like @MasterLink has better thought.

That said, I did key in some ideas and your issue, asking ChatGPT if it had any ideas. I don’t know if this is legitimate, hallucination, or something else. But figured it wouldn’t hurt to throw this out there:

ChatGPT:

Yes. That pattern is very well known on Linux, especially on Arch based systems like CachyOS.

When Chrome or Brave can still show passwords in the built in password manager but refuse to autofill them, the browser vault is intact but the OS level secret service that unlocks it for live use is failing. Autofill depends on the system keyring being unlocked at login. Viewing passwords does not.

Here are the main causes that break autofill while leaving the password manager readable.

The most common one is a locked or broken keyring. On Linux, Chrome and Brave encrypt saved logins using the desktop keyring, either GNOME Keyring or KWallet. If that keyring did not unlock at login, Brave can read the encrypted database but cannot decrypt entries in real time to inject into forms. You can still open the password manager because it prompts you for your OS password and decrypts on demand.

Another common cause is Wayland plus missing secret service. On Wayland, Chromium browsers require a working org.freedesktop.secrets service. If gnome-keyring-daemon or kwalletd is not running or crashed, autofill silently fails.

A third cause is a password mismatch. If the login password changed but the keyring password did not, the keyring stays locked. Autofill fails, but manual viewing still works because it asks for credentials each time.

A fourth cause is a Chromium security hardening change. In late 2023 and 2024, Chromium disabled fallback unencrypted storage. If the system keyring is not available, autofill is disabled by design. Older versions used to fall back to weaker encryption.

This is why you often see this break after:

  • a desktop environment switch, such as KDE to GNOME or the reverse
  • a Wayland migration
  • a password change
  • a keyring corruption or reset
  • reinstalling or removing gnome-keyring or kwallet

On CachyOS in particular, this happens a lot when someone installs GNOME apps on KDE or switches to Hyprland. Brave then looks for GNOME Keyring while KDE is running KWallet, or the reverse.

If they are on KDE, the fix is usually to make sure kwalletd is running and that Brave is set to use it.
If they are on GNOME or Hyprland, the fix is usually to make sure gnome-keyring-daemon is running and unlocked.

This is not a browser bug. It is the Linux secret store failing to unlock at session start, which blocks autofill but not manual password access.

If you know whether the system is KDE, GNOME, or Hyprland, the exact fix can be narrowed down to a few commands.

Yeah, that seems to be all GPU related.

ChatGPT

What does matter is what is missing from that log.

There is no mention of a secrets backend. When Chromium starts normally with a working keyring, you usually see lines referring to:

  • org.freedesktop.secrets
  • libsecret
  • kwallet
  • gnome-keyring
  • or SecretService

The fact that none appear strongly suggests Brave is running without a working secret service on that Wayland session.

I used pacman for the regular install, drawing from repo cachyos/. This, not being on your supplied page of installation methods for Linux, could well be a pointer. However, I used paru for the Beta application (as it was not available via pacman) - so I think we can rule that out.

Here you can see my kwalletd is alive and well, not needing to have been started manually, or anything:

I can go and poke the CachyOS forums to see if the keyring thing is the issue.

1 Like

Well, I’m going to hope @Mattches or others can follow up later. Due to the lateness in the day, I’m guessing likely won’t be until tomorrow. And if not then, will not be until next week.

What I’ll leave you with is one last ChatGPT reply. But I don’t want to keep just doing copy/paste AI replies as I figured you’d be checking with it directly if you wanted it. At least just was trying to make up as much of an attempt as I can in this moment to help.

ChatGPT

That screenshot is useful, and it narrows the problem instead of disproving it.

Yes, kwalletd6 is running. That only proves the wallet daemon exists. It does not prove that Brave is actually able to talk to it as a Secret Service.

Chromium browsers do not talk to KWallet directly. They talk to org.freedesktop.secrets over DBus. On KDE, that is provided by the KWallet Secrets Service bridge. That bridge is a separate component, and it is often the thing that is missing or broken even while kwalletd itself is running.

So what you have is this:

  • kwalletd6 running
  • Wayland session active
  • Brave beta running
  • but no Secret Service exposed to Chromium

When that happens, Chromium does exactly what you are seeing. It allows viewing passwords but refuses to autofill.

This is extremely common on Arch based KDE Wayland systems because the Secret Service bridge is optional and not always installed or enabled.

You can confirm the break with one command:

busctl --user list | grep secret

On a working system, you should see:

org.freedesktop.secrets

If that line is missing, Brave cannot access KWallet even though kwalletd is running.

The missing piece is usually one of these packages or services:

  • kwallet-pam
  • ksecretsservice
  • kwalletmanager
  • or the KWallet Secrets Service DBus module

On CachyOS this often happens after updates, switching desktops, or reinstalling KDE components.

So the screenshot proves only this:
KWallet is running.
It does not prove Brave can use it.

Brave requires kwalletd + Secret Service bridge + DBus registration. If any one of those three is missing, autofill dies but password viewing keeps working.

That matches your symptom perfectly.

I just installed chromium itself to check - and indeed I can reproduce this issue with Chromium as well.

Here’s the output from your CGPT command suggestion:

But I don’t know if it proves anything any which way.

Best thing I should do now really is go ask the CachyOS guys.

Thanks for your patience!

1 Like

Bah, I’m going to make a liar of myself. Morbid curiosity had me ask ChatGPT just to try to learn a bit from it on what things are saying. And if I have a potential answer, why not share, right? haha. Anyway, I will sincerely stop after this. If you want, you can follow up on it yourself at https://chatgpt.com/share/69697f32-1d0c-800a-b5d4-fc10030ccf2b

Otherwise, hopefully the experts at least get you the better answer. Good luck.

ChatGPT (trimmed response, not full copy/paste)

So this is not a missing daemon problem. It is a Chromium to KWallet integration break.

What is happening is this:

Chromium and Brave on Wayland now require a working XDG Desktop Portal secrets backend when running in a sandboxed Wayland environment.

There is a dirty but very telling test. Launch Chromium or Brave like this:

XDG_CURRENT_DESKTOP=KDE \
CHROME_USE_PORTAL=0 \
brave-beta

If autofill suddenly works, you have confirmed that the KDE secrets portal is what is broken.

The long term fix is an update to xdg-desktop-portal-kde or ksecretd. Until then, people are working around it by either:

  • disabling portal usage for Chromium
  • or forcing GNOME keyring instead
  • or running under XWayland

So yes, going to the CachyOS folks is reasonable, but the bug lives upstream in KDE and Chromium, not in CachyOS itself.

No joy with those variables in front of the command I’m afraid (though I don’t know if I did it properly, TBH)


I’m off for the night anyway. Will troubleshoot further tomorrow

I am having the same issue I am running on the latest version of stable Brave on CachyOs. I have tried the nightly version as well but no luck. I deleted the config file but also nothing changed.

1 Like