Fix add-email preserve identity email state flow
This commit is contained in:
QLHazyCoder
+7
-6
@@ -153,8 +153,8 @@
|
||||
- 注册邮箱运行态 `registrationEmailState = { current, previous, source, updatedAt }`
|
||||
- 当前手机号注册运行态 `signupPhoneNumber / signupPhoneActivation / signupPhoneCompletedActivation`
|
||||
- 侧栏“注册手机号”输入框只同步运行态 `signupPhoneNumber / accountIdentifierType / accountIdentifier`，不属于持久配置，也不参与配置导入导出
|
||||
- 邮箱身份写入时会把 `accountIdentifierType / accountIdentifier` 改回邮箱，并清理旧的 `signupPhone*` 注册手机号运行态，避免后续 Step 4 / Step 8 被旧手机号污染而误走短信分支
|
||||
- 邮箱写入统一通过 `setEmailState*` 同步更新 `email` 与 `registrationEmailState`；如果当前邮箱因 Step 8 恢复被清空，但还需要保留上一份 Duck / add-email 对比基线，则只清空 `current`，保留 `previous`
|
||||
- 普通邮箱身份写入会把 `accountIdentifierType / accountIdentifier` 改回邮箱，并清理旧的 `signupPhone*` 注册手机号运行态，避免后续 Step 4 / Step 8 被旧手机号污染而误走短信分支；但 Step 8 `add-email` 这类明确要求保留手机号身份的链路除外
|
||||
- 邮箱写入统一通过 `setEmailState*` 或共享注册邮箱状态持久化 helper 同步更新 `email` 与 `registrationEmailState`；如果当前邮箱因 Step 8 恢复被清空，但还需要保留上一份 Duck / add-email 对比基线，则只清空 `current`，保留 `previous`；如果当前链路显式要求 `preserveAccountIdentity`，则在写入邮箱的同时保留 `signupPhone* / accountIdentifier*`
|
||||
- 本轮联动自检重点：
|
||||
1. Step 2 一旦自动取到手机号，必须立刻广播并回填侧栏运行态手机号。
|
||||
2. sidepanel 重新加载后，必须从当前 state 恢复“注册手机号”文本框，而不是只恢复邮箱。
|
||||
@@ -469,8 +469,8 @@ IP 代理模块在同步、切换、Change、出口探测和自动运行成功
|
||||
|
||||
1. 先确认当前认证页真实状态，而不是只看 `accountIdentifierType`。
|
||||
2. 当前是 `add-email`：
|
||||
- 调用 `resolveSignupEmailForFlow` 按需获取或生成本轮绑定邮箱；手机号注册不会在 Step 2 提前生成邮箱，只有真实进入 `add-email` 时才占用邮箱资源
|
||||
- 如果邮箱生成器已经在生成阶段写回运行态，这里不会再重复覆盖 `registrationEmailState`，但会保留手机号身份
|
||||
- 调用 `resolveSignupEmailForFlow` 按需获取或生成本轮绑定邮箱；手机号注册不会在 Step 2 提前生成邮箱，只有真实进入 `add-email` 时才占用邮箱资源；这里会显式打开 `preserveAccountIdentity`
|
||||
- 如果邮箱生成器已经在生成阶段写回运行态，这里不会再重复覆盖 `registrationEmailState`；无论是复用已有邮箱，还是 Duck / Cloudflare / Cloud Mail / iCloud / 自定义邮箱池这类现场生成的新邮箱，都会走共享注册邮箱状态持久化规则保留手机号身份
|
||||
- 内容脚本发送 `SUBMIT_ADD_EMAIL` 填写邮箱并提交
|
||||
- 页面进入邮箱验证码页后，用绑定邮箱作为 `step8VerificationTargetEmail`
|
||||
3. 当前是邮箱验证码页：
|
||||
@@ -653,7 +653,7 @@ Plus 模式可见步骤：
|
||||
- UI 文案输出
|
||||
|
||||
- `background/registration-email-state.js`
|
||||
统一维护当前注册邮箱、上一份比较基线邮箱、来源与更新时间，并提供 Duck 生成前解析比较基线、Step 8 清空当前邮箱但保留历史基线的共享工具。
|
||||
统一维护当前注册邮箱、上一份比较基线邮箱、来源与更新时间，并提供 Duck 生成前解析比较基线、Step 8 清空当前邮箱但保留历史基线，以及 Step 8 `add-email` 写入邮箱时保留手机号身份的共享工具。
|
||||
|
||||
- `background/generated-email-helpers.js`
|
||||
在原有 Duck / Cloudflare / iCloud / Cloudflare Temp Email 生成链路之外，新增 Gmail / 2925 的共享生成接入；Duck 生成前会按“侧栏当前可见邮箱 -> `registrationEmailState.current` -> `registrationEmailState.previous`”的顺序解析比较基线。
|
||||
@@ -678,7 +678,7 @@ Plus 模式可见步骤：
|
||||
|
||||
补充：
|
||||
|
||||
- 所有生成器在返回邮箱后都会统一调用 `setEmailState(..., { source })` 回写运行态，保证 `email` 与 `registrationEmailState` 同步更新。
|
||||
- 所有生成器在返回邮箱后都会统一调用共享注册邮箱状态持久化入口回写运行态：普通邮箱流等价于 `setEmailState(..., { source })`，而 Step 8 `add-email` 的手机号身份流会在更新 `email / registrationEmailState` 的同时保留 `signupPhone* / accountIdentifier*`，避免 sidepanel 短暂看到手机号被清空。
|
||||
- Duck 生成链路不会再直接拿“生成前瞬间读到的输入框值”当唯一基线，而是优先使用 sidepanel 当前可见邮箱，再回退到共享的注册邮箱运行态基线，避免生成前后地址对比失效。
|
||||
|
||||
### 7.1.1 Cloud Mail
|
||||
@@ -841,6 +841,7 @@ Plus 模式可见步骤：
|
||||
- `icloudFetchMode` 决定生成注册邮箱时复用已有 Hide My Email 别名，还是始终创建新别名。
|
||||
- `icloudTargetMailboxType = icloud-inbox` 时，Step 4 / Step 8 直接打开 iCloud Mail 收件箱轮询验证码。
|
||||
- `icloudTargetMailboxType = forward-mailbox` 时，注册邮箱仍由 iCloud Hide My Email 生成，但 Step 4 / Step 8 改为打开 `icloudForwardMailProvider` 指定的转发目标邮箱收码；当前支持 `qq / 163 / 163-vip / 126 / gmail`。
|
||||
- Step 8 `add-email` 里无论 iCloud 最终是复用未使用别名，还是新建并保留 Hide My Email 别名，选中的邮箱都会先走共享注册邮箱状态持久化；当当前账号主身份仍是手机号时，这一步不会先广播清空手机号再恢复。
|
||||
|
||||
Hide My Email 获取与管理链路：
|
||||
|
||||
|
||||
Reference in New Issue
Block a user