After staring into the abyss of minified JS code, it looked like it is assumed that WebAuthn works if the account has a second-factor configured that uses it. The logic seems to be “if one can configure it, then the same person must be able to use”, which disregards the fact that the user may change user-agents from one session to the next. OTOH, there seems to be code to trigger the panel with fallbacks to other methos if the “Promise” returned by the “navigator.credentials.{get,create}()“ functions resolves to “null”, which according to https://developer.mozilla.org/en-US/docs/Web/API/CredentialsContainer means: “If a single credential cannot be unambiguously obtained, the promise resolves with null.“ It seemed worth checking what would happen if we pretend to support WebAuthn but resolve the “Promise” that way. After some tinkering, adding the following to the WPE MiniBrowser worked: // In the activate() function, after adding the optional content // filter, make sure to always have a content manager and add the // user script. if (!userContentManager) userContentManager = webkit_user_content_manager_new(); const char *googleAuthUserScriptSource = "(function (N) { \n" " 'use strict'; \n" " function resolve_to_null() { \n" " return new Promise((resolve, reject) => { \n" " setTimeout(() => { \n" " resolve(null); \n" " }, 300); \n" " }); \n" " } \n" " N.credentials = { \n" " get: resolve_to_null, \n" " create: resolve_to_null, \n" " }; \n" "})(navigator);\n"; const char *googleAuthUserScriptURLs[] = { "https://accounts.google.com/*", nullptr, }; g_autoptr(WebKitUserScript) googleAuthUserScript = webkit_user_script_new(googleAuthUserScriptSource, WEBKIT_USER_CONTENT_INJECT_TOP_FRAME, WEBKIT_USER_SCRIPT_INJECT_AT_DOCUMENT_START, googleAuthUserScriptURLs, nullptr); webkit_user_content_manager_add_script(userContentManager, googleAuthUserScript);

This seems to be an issue in the website code itself, not really on WebKit. Therefore I have reported the issue in the WebCompat tracker: https://webcompat.com/issues/184312 We may be able to provide a quirk in WebKit in the meantime, I'm trying to look into that.

Pull request: https://github.com/WebKit/WebKit/pull/52813

<rdar://problem/163580319>

Committed 302791@main (b08846a9d6c8): <https://commits.webkit.org/302791@main> Reviewed commits have been landed. Closing PR #52813 and removing active labels.