`<SignIn />` and `<SignUp />` email and name fields have no `autocomplete`, so browsers don't offer the user's email
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 3/5
- 預估耗時
- 1-2 天
- 新手友好度
- 72/100
- Issue 類型
- 缺陷
- 描述清晰度
- 描述清楚
- 活躍度
- 活躍
- 技術堆疊
- next.js, react, typescript
研究方向
Start with packages/ui/src/components/SignIn/SignInStart.tsx at the identifier field mentioned in the issue, then locate the corresponding SignUp fields and their tests. Check how identifier types and passkey autofill are handled, and run the relevant component tests. Done when the fields receive the standard autocomplete tokens described in the issue, including a valid field name before webauthn.
由索引模型根據 Issue 內容生成。
描述
Reproduction
No special setup needed: any app with the default <SignIn /> / <SignUp /> and email (email code) as the only identifier shows it, e.g. a fresh Next.js quickstart.
Description
With email as the sign-in identifier, the prebuilt components render the email and name fields without any autocomplete attribute:
<!-- <SignIn /> -->
<input id="identifier-field" name="identifier" type="text" inputmode="email" ...>
<!-- <SignUp /> -->
<input id="firstName-field" name="firstName" type="text" ...>
<input id="lastName-field" name="lastName" type="text" ...>
<input id="emailAddress-field" name="emailAddress" type="text" inputmode="email" ...>
So Safari (macOS/iOS/iPadOS), the iOS QuickType keyboard and password managers can't tell the field is an email field, and they don't offer the user's email. This is worst with passwordless sign-in (email code): there's no password field, so the browser never saves a login. Users type their full email by hand on every sign-in. We see it in session recordings: the same users typing their email letter by letter every week, and users have reported it.
type="text", name="identifier" and a translated label (here French, "Adresse e-mail") leave the browser almost nothing to guess from.
In the source, the identifier field only gets autocomplete when passkey autofill is on, and then the value is webauthn on its own:
autoComplete={isWebAuthnAutofillSupported ? 'webauthn' : undefined}
There's no prop or appearance option to set it, so the only workaround is adding the attribute to Clerk's DOM from outside with a MutationObserver.
Steps to reproduce:
- Enable email (email code) as the only identifier in the dashboard.
- Render
<SignIn />(or<SignUp />). - Inspect the email field, or focus it in Safari on iOS/iPadOS.
Expected behavior:
The fields carry standard autocomplete tokens, so browsers, keyboards and password managers can offer the user's details:
- Sign-in identifier:
emailwhen email is the only identifier,telfor phone only,usernamefor username or mixed identifiers. With passkey autofill, addwebauthnafter the field name (username webauthn,email webauthn). A barewebauthnisn't a valid value per the HTML spec, which expects it after a field name. - Sign-up:
emailonemailAddress,given-nameonfirstName,family-nameonlastName,telonphoneNumber,usernameonusername.
This is also an accessibility issue: WCAG 2.1 SC 1.3.5 Identify Input Purpose (Level AA) asks for autocomplete on fields that collect the user's own information.
Actual behavior:
No autocomplete attribute on these fields (unless passkeys are on, then a bare webauthn). Safari and the iOS keyboard don't suggest the user's email.
Environment
@clerk/nextjs: 7.5.2
@clerk/clerk-js: 6 (loaded from Frontend API)
@clerk/ui: 1.40.0 (loaded from Frontend API)
next: 16.3.1
react: 19
Seen in: Safari on iPadOS (user report); confirmed in Chromium and WebKit (Playwright)
- 主要語言
- TypeScript
- 星號
- 1.8k
- 分支
- 480
- 平均合併
- 1 天 19 小時
- 30 天內合併 PR
- 285
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
clerk/javascript 的其他 Issue
-
難度 2/5 1-3 小時 新手友好度 78/100
clerk/javascript#10026 · 2 則留言 ·
維護者通常 1 天內回覆
-
@clerk/nextjs: onBeforeSetActive never settles when invalidateCacheAction rejects (e.g. after a redeploy), so setActive and signOut hang forever可能已有人在做 @RaphaelFakhri 於 15 天前認領。 未關閉
難度 2/5 1-3 小時 新手友好度 78/100
clerk/javascript#9987 · 1 則留言 ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 18/100
clerk/javascript#10231 · 2 則留言 · 3 個 reaction ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 25/100
clerk/javascript#10185 · 1 個 reaction ·
維護者通常 1 天內回覆
-
難度 4/5 1-2 天 新手友好度 45/100
clerk/javascript#10118 ·
維護者通常 1 天內回覆
相似的 Issue
-
Area/Cloud Needs Triage Type/Bug
難度 1/5 1-3 小時 新手友好度 86/100
wso2/product-integrator#2847 ·
維護者通常 1 天內回覆
-
bug
難度 2/5 1-3 小時 新手友好度 67/100
bluesky-social/social-app#12118 ·
維護者通常 1 天內回覆
-
enhancement
難度 1/5 1 小時以內 新手友好度 85/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 77/100
heygen-com/hyperframes#6021 ·
維護者通常 1 天內回覆
-
check:passed streams:edit
難度 2/5 1-3 小時 新手友好度 68/100
維護者通常 1 天內回覆