Unfortunately this is "correct" behavior. Firefox on Linux does not support passkeys, because Firefox doesn't have a built-in password manager (like Chrome does), and there is also no OS-level password manager to integrate with (unlike on Mac OS or Windows). If you install a third-party password manager like 1Password, passkey support should work correctly.

We could probably do a better job of communicating this more clearly to the user.

Change #1238443 had a related patch set uploaded (by Catrope; author: Catrope):

[mediawiki/extensions/OATHAuth@master] Skip passkey feature detection on Firefox on Linux

https://gerrit.wikimedia.org/r/1238443

Change #1238443 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@master] Skip passkey feature detection on Firefox on Linux

https://gerrit.wikimedia.org/r/1238443

It looks like this is worse than I thought. Firefox on Linux will say that it doesn't support passkeys, even when certain third-party password managers are installed that do support them. If 1Password is installed, Firefox does correctly say that it supports passkeys, but if Bitwarden or KeePassXC are installed, Firefox incorrectly says it doesn't support them.

@Catrope, I am able to reproduce this with firefox-nightly-149.0a1-20260215214423, so does an upstream Mozilla Bugzilla ticket exist for that? One certainly should, if it doesn't.

However, are you certain that your diagnosis is correct? I ask because I also observe this in chromium-144.0.7559.132-1.fc43:

{F72138744}

This image cannot be seen: https://www.mediawiki.org/wiki/Phabricator/Help#File_visibility

so does an upstream Mozilla Bugzilla ticket exist for that?

I took a look via https://bugzilla.mozilla.org/query.cgi?format=advanced and did not find one.

This image cannot be seen: mediawiki.org/wiki/Phabricator/Help#File_visibility

@Aklapper, resolved — apologies, and thanks. Hopefully, that screenshot demonstrates that what I observe in Chromium is equivalent to what you (and I) observe in Firefox.

I took a look via bugzilla.mozilla.org/query.cgi?format=advanced and did not find one.

Someone, please file one, because that would be a very significant defect, and I've not the competence to file it myself.

In T415089#11621343, @rokejulianlockhart wrote:

However, are you certain that your diagnosis is correct? I ask because I also observe this in chromium-144.0.7559.132-1.fc43:

If I remember correctly, Chromium (unlike Chrome) does not integrate with your Google account, and doesn't have Google Password Manager integration. If you don't have a browser extension like 1Password or Bitwarden or whatever installed, then there is no way the browser can store a passkey, so disabling the button is correct behavior. (If you do have one of these browser extensions please let me know.)

If you do have one of these browser extensions please let me know.

@Catrope, indeed, I did (and do) have nngceckbapebfimnlniiiahkandclblb installed:

…as I did for firefox (albeit the slightly older .XPI, available via AMO).

Change #1309841 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/extensions/OATHAuth@master] Passkeys: Show warning when browser does not support passkeys

https://gerrit.wikimedia.org/r/1309841

My patch adds a warning message instead. This is what it looks like. We can also show both message and button possibly ?

Maybe we could do the disabled-button-plus-warning-notice style? That way everyone gets the button (so if following some guidance telling them to click the button they don't worry they're in the wrong venue), but they also get feedback immediately.

In T415089#12112435, @Jdforrester-WMF wrote:

Maybe we could do the disabled-button-plus-warning-notice style? That way everyone gets the button (so if following some guidance telling them to click the button they don't worry they're in the wrong venue), but they also get feedback immediately.

The button is currently there initially, but as the JS executes it is replaced with the message. The thing holding me back from a disabled button is mostly the following in our design guidelines: "Avoid using disabled buttons on forms and instead rely on validation."

Also reading it again, the warning should probably be a notice and not a warning (which i guess might scare people)

In T415089#12112456, @TheDJ wrote:

the following in our design guidelines: "Avoid using disabled buttons on forms and instead rely on validation."

Hmm, that's a nice guideline in isolation but a pretty poor experience for users when sitting next to someone else that has a different UX, and makes for complex / impossible written user gudiance. Oh well.

In T415089#12112461, @Jdforrester-WMF wrote:

In T415089#12112456, @TheDJ wrote:

the following in our design guidelines: "Avoid using disabled buttons on forms and instead rely on validation."

Hmm, that's a nice guideline in isolation but a pretty poor experience for users when sitting next to someone else that has a different UX, and makes for complex / impossible written user gudiance. Oh well.

With disabled button it looks like: