pro/im_webapp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
2,031 Commits 2 Branches 0 Tags
e3217a5de94ef3bb3205e881c6bb423f55d20b46
Commit Graph
265 Commits
Author SHA1 Message Date
Your NameandClaude Sonnet 5 4e8f45d7d8 路由从 hash 换成 History API（pushState/replaceState/popstate），不再依赖 location.hash 
HashNavigation 改名 Navigation（src/lib/navigation.js），接口不变，内部改用真实路径：
parseUrlHash/composeUrlHash 改名 parseUrl/composeUrl；navigateTo/navigateReplace 改调
pushState/replaceState 后手动派发 popstate（pushState/replaceState 不会像赋值 location.hash
那样自动触发事件，这里复用 navigateReplace 早就在用的同一个手动 dispatch 手法）；goBack()
不用改，history.back() 本来就是真实浏览器历史机制。新增 Navigation.currentUrl() 替代调用方
原本直接读的 window.location.hash（这个类从来没包装过这个读取）。

一处需要专门处理的边界情况：当 path[0] 是空字符串（"不选中侧栏视图、只开一个会话"这个仓库里
的合法状态）时，拼出的真实路径开头会变成双斜杠，被浏览器当协议相对地址解析、试图跳到一个叫
会话id的host，pushState 直接抛 SecurityError。composeUrl/parseUrl 内部用占位 token "_" 处理
这种情况，对外的调用方（19个文件）完全无感。

tinode-web.jsx 的 handleHashRoute 改名 handleRouteChange，监听从 hashchange 换成 popstate；
service-worker.js 的推送通知点击跳转手动改写成同样的路径格式（这个文件在打包之外单独执行，
没法 import Navigation）。index.html/index-dev.html 加了 <base href="/">——所有静态资源引用
都是相对路径，hash 路由下页面路径永远是 /，换真实路径后深层地址刷新会按当前目录解析出错误
资源地址导致白屏，这一行是标准修法。nginx.conf 的 try_files 兜底规则本来就适用两种路由，只
更新了注释。

实机验证：地址栏不再有 #；点击会话/设置等各类视图正常跳转；浏览器前进后退和应用内"返回"
按钮都正常；收藏页内部的类型 tab 切换（navigateReplace）确认不产生新的历史记录；在会话页/
个人中心页刷新、直接用完整深层路径打开新标签页都能正确恢复到位，资源正常加载不白屏。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-07 21:00:39 +08:00
Your Name ac8f0cf315 补上好友申请前后关系状态聊天页的入口，并把验证留言渲染成真实消息气泡 
第3章要求pending_inbound/pending_outbound/none/blocked几种关系状态都能在真实聊天
窗口里看到（参考图 个人对话框（对方的状态）/（我的状态）.png、开启沟通页面.png）。
messages-view.jsx里对应的横幅逻辑（"以上是打招呼的消息"/"好友申请正在等待处理"等）
本身早就是对的，但排查发现两个问题：

1. 全项目没有任何入口能导航进这个视图——"新朋友"列表(FriendRequests)每一行没有
   onClick；好友个人主页(Profile)非好友分支只显示一段cannotAddReason纯文字，没有
   任何可点击进聊天的按钮。发起方和接收方在成为好友之前都完全看不到这个视图。
2. 验证留言原文（发好友申请时填的那段话，存在im_friend_requests表的message字段，
   不是真实Tinode消息，没有走topic.publish()）没有被当作消息渲染出来，参考图里
   明确是作为聊天页第一条消息气泡展示的。

修复：
- contact-management-view.jsx: FriendRequests每一行加onClick，用(onCreateTopic||
  onTopicSelected)跳进对应聊天（同一套Profile.openChat已经验证过的冷启动安全写法，
  接受/拒绝按钮补stopPropagation不受影响）；Profile非好友分支（blocked_by_peer/
  blocked_by_me/pending_inbound/pending_outbound）补一个"查看聊天"按钮，跟
  cannotAddReason文字并排展示（不复用people-profile-actions的两列grid，那是给
  发消息+音视频通话两个平级按钮设计的）。ContactManagementView/sidepanel-view.jsx
  早前就已经把onCreateTopic透传到位，这次只是多接一层。
- messages-view.jsx: loadRelationshipContext新增loadPendingRequestMessage，
  relationship是pending_inbound/pending_outbound时，用relationshipContext自带的
  request_id去GET /friend-requests换真实留言文本（没有留言用参考图默认文案"请求
  添加你为好友"兜底），渲染成一条合成的消息气泡插在消息列表最前面（不进
  messageNodes、不调用发消息接口）——pending_inbound左对齐、pending_outbound右
  对齐，气泡样式直接复用chat-message.jsx真实消息已经在用的.bubble/.left/.right
  这套CSS（app里"发出的"气泡实际是这套已实现的浅色而非参考图的蓝色，保持跟同一
  会话里其它真实消息一致，不単独改这一条的颜色去凑旧版参考图）。

验证：真实两个新账号（vcm909641发起→hankqa14b接收）走了一遍完整流程——
从"新朋友"列表点击行正确进入聊天页，留言气泡+"以上是打招呼的消息"横幅正确显示；
从Profile页"查看聊天"进入，留言气泡右对齐+"好友申请正在等待处理"横幅正确显示；
点"通过验证"接受申请后正确留在列表页不误触发导航；接受后重新打开同一会话，
合成气泡正确消失，被真实的"你们已成为好友，现在可以开始聊天了。"系统消息取代，
无残留/无重复。
 2026-09-06 17:24:36 +08:00
Your NameandClaude Sonnet 5 30e6d5e300 修复风控弹窗取消后再次发送同一条回复，引用内容与正文被永久追加重复 
现象：对一条历史消息点"回复"，输入含链接的文本触发风控弹窗后点"取消发送"
（预览条正确保留，这是既有修复的正常行为），不改动文本再次点发送、这次
在弹窗里点"我已知晓，继续发送"——最终发出的消息里，正文被写了两遍（引用
块本身只有一份），例如输入"排查根因4 xxx"，实际发出"[引用] 排查根因4
xxx排查根因4 xxx"。第三次发送同一条文本会变成正文三遍，以此类推。

根因：sendMessage()给回复拼接引用内容时写的是
`Drafty.append(Drafty.sanitizeEntities(this.state.reply.content), msg)`。
Drafty.sanitizeEntities和Drafty.append（umd/tinode.dev.js，第三方SDK，
未改动）都会原地修改第一个参数并把同一个引用返回，从不做深拷贝——
sanitizeEntities内部直接改content.ent[i]再return content，append直接
first.txt+=、first.fmt.push()再return first。这里把this.state.reply.content
（React state里"正在回复"预览条依赖的同一个对象）原样传进去，等于每次
点发送都会把当次输入的正文永久焊死在这条回复引用的原始内容上。

平时这个副作用不可见：一次成功发送后handleCancelReply()马上清掉
state.reply，被污染的对象跟着一起扔掉。但URL风控检查会把真正调用
doSend()（进而调用这行代码）的时机推迟到弹窗resolve之后，"取消发送"
按现有修复（a964d51b）刻意不清空state.reply以保留预览条——这就让
被污染的引用内容留了下来，等下一次点发送时，同一个已经被污染的对象
再被追加一次，正文因此重复。

修复：拼接前对this.state.reply.content做一次深拷贝，让两个SDK方法的
原地修改只作用于用完即扔的副本，不管sendMessage对同一条还没清空的
回复调用多少次都不影响原始状态。

验证：真实浏览器操作，对消息点回复，输入带链接文本发送触发风控弹窗，
点"取消发送"（预览条与文本保留正常），不改文本再次发送并这次确认
"继续发送"——发出的消息引用块和正文都只出现一次，不再重复。

第14+轮最小粒度测试 Ch4 发现（回复+风控弹窗联动场景，紧邻已知修复
a964d51b验证时发现）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-06 16:24:30 +08:00
Your NameandClaude Sonnet 5 b200dc2525 修复长按消息菜单"撤回"功能完全失效：LOCAL_SEQID 经 webpack externals 解析为 undefined 
现象：验证第2章长按消息弹出菜单的时间窗口门控时发现，无论消息是不是自己刚发的、群主/普通
成员、发送后多少秒，长按菜单里永远不出现"撤回"这一项——服务端 messagePolicy 明确返回
recall_window_seconds=120，但这个选项在任何情况下都不会出现。

根因：messages-view.jsx 原来 `import { ..., LOCAL_SEQID } from 'tinode-sdk'`，但
webpack.config.js 把 'tinode-sdk' 映射到全局变量 `tinode`（externals: {'tinode-sdk': 'tinode'}），
而这个全局对象（umd/tinode.dev.js 的 UMD 导出）只挂了 {AccessMode, Drafty, TheCard, Tinode}
四个键，从未包含 LOCAL_SEQID——尽管 tinode-sdk 的 ES 模块本身确实导出了这个常量
（umd/tinode.dev.js 内部仍以 `const LOCAL_SEQID = 0xFFFFFFF;` 定义并在多处话题方法里使用，只是
没有挂到对外暴露的全局对象上）。externals 映射对"这个键不在对象上"和"这个导出根本不存在"没有
区分，所以按名字导入被静默解析成 `undefined`，没有任何构建报错。撤回菜单项的门控条件
`params.seq > 0 && params.seq < LOCAL_SEQID` 因此变成 `seq < undefined`，在 JS 里恒为
false——不是时间窗口判断错了，是入口条件本身就从未为真过，撤回功能对所有用户、所有消息实质性
完全失效。

用控制台直接调用 MessagesView 实例的 handleShowMessageContextMenu 并打印各分支布尔值定位到
这一步：seq=2 这样明显合法的正整数，seqOk 却是 false，才追到 LOCAL_SEQID 本身是 undefined。

修复：messages-view.jsx 不再从 'tinode-sdk' 导入 LOCAL_SEQID，改为本文件内本地声明
`const LOCAL_SEQID = 0xFFFFFFF`，与 SDK 内部定义保持一致（未改动 webpack externals 映射本身——
其它页面都依赖它保持现状，改映射风险更大、影响面更广）。

验证：登录测试账号，在群聊里发一条新消息立即长按，确认"撤回"正确出现在菜单中；点击后
`POST /topics/{topic}/messages/{seq}/recall` 返回 200，消息从会话中正确消失；对比一条已经
超过 recall_window_seconds（同时也超过 edit_window_seconds）的旧消息，确认"撤回"和"编辑"
仍正确不显示，时间窗口判断本身未被破坏。

注：umd/index.dev.js 本次未随此提交提交——工作区里并行的其它 agent 仍在改
contact-management-view.jsx / sidepanel-view.jsx 且未提交，重新构建的 index.dev.js 会把它们的
未提交改动一起编译进同一产物文件，为避免混入不相关改动，只提交 messages-view.jsx 按路由懒加载
的独立 chunk（umd/src_views_messages-view_jsx.dev.js 及其 .map），不受这个问题影响。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-06 16:05:19 +08:00
Your NameandClaude Sonnet 5 b6adc032a2 修复发送含链接消息时切换话题，风控弹窗可能把消息送错会话 
现象：在会话A输入含链接的消息并点发送，POST /security/urls/check 请求还未返回时切换到
会话B，请求返回后风控弹窗会在会话B里弹出（本该属于会话A），此时点"继续发送"，消息被
真实发进了会话B，而不是最初输入它的会话A——跨会话消息误投递。

复现：会话A（kcg051307）输入"https://example.com/racefix?token=fix002"点发送，立即
（在checkURL网络请求返回前）切换到会话B（r12c56b2），风控弹窗在会话B视图下弹出；点
"继续发送"后消息被投递进会话B，会话A完全没有收到，会话B收到了本不该发给它的内容
（本次因B恰好还不是好友触发"发送失败"提示，但发送动作本身已经指向了错误的会话，
如果B是好友会真实送达）。

根因：`getDerivedStateFromProps`在话题切换时会把`riskDialog`重置为null，但这只能防住
"弹窗已经弹出、随后切换话题"这一种时序——它防不住"checkURL还在进行中就切换话题，
此时机的.then()回调在切换之后才执行"这种反过来的时序：这次setState({riskDialog:{...}})
是在切换完成之后才发生的，不会被这次重置覆盖，于是在当前（错误的）话题下重新弹出弹窗，
且弹窗里的`doSend`闭包沿用的是`this.props.sendMessage`，按确认时的当前话题发送，
不是消息最初输入时所在的话题。

修法：sendMessage()进入URL风险检测分支时已经缓存了`topicForDraft`（用于清草稿），
在checkURL的.then()回调最开头加一道判断——如果`this.state.topic`已经不等于
`topicForDraft`，说明用户已经离开发起这次检测的会话，直接返回false（视同消息被放弃，
不弹窗、不发送），不再继续读取风控结果或setState。这与本文件已有的"两条风险消息连续
触发、后一个覆盖前一个"场景处理逻辑（resolve(false)后覆盖）是同一种"宁可丢弃، 不可
错误投递"的一贯取舍，只是这次要防的是切换会话而不是重复触发。

验证：npm run build:dev后浏览器实测——(1) 会话A输入风险链接点发送，立即切换到会话B，
2秒后确认会话B里没有弹出风控弹窗（修复前必现）；(2) 切回会话A确认最后一条消息仍是修复
前测试遗留的旧消息，本次新消息没有出现在A也没有出现在B，两个会话都没有收到，符合
"宁可丢弃不可错投"的设计；(3) 对照组（不切换话题、正常触发风控）依旧能看到弹窗并正确
发送/取消，未被这次改动影响。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-06 15:57:22 +08:00
Your NameandClaude Sonnet 5 ddf23d40b2 修复新会话首次打开时消息历史被静默截断为1条、对方已读回执永不刷新 
根因：tinode-web.jsx的prefetchLatestMessagePreviews()（会话列表"最后一条消息"预览）
会在会话列表一渲染就对每个有动态但本地无缓存摘要的话题调用
topic.subscribe(startMetaQuery().withLaterData(1)...)，只为预览目的抓取"最新1条"
消息——这常常发生在用户真正点开这个会话之前。这次订阅会把tinode-sdk的
Topic._attached置为true，且把_maxSeq设成那一条消息的seq。

用户随后点开会话时，messages-view.jsx自己的subscribe()发现topic.isSubscribed()
已经是true就直接return，从未真正发出过完整的{sub}请求。即使去掉这个短路，
SDK的Topic.subscribe()本身在_attached为true时也会无条件短路成
Promise.resolve(this)，完全不看传入的getParams——所以无论如何都不会把
withLaterSub()/withAux()等真正需要的查询发给服务端。

现场复现：全新注册的两个互为好友账号之间发4条真实消息，全新session下第一次点开
该会话，只渲染出最新1条，其余3条静默丢失；对方的已读回执（应变蓝色双勾）永远
不刷新——这两个现象都会在离开会话再重新打开后自愈（因为离开会清掉_attached），
但用户在此之前看到的是一个残缺、状态错误的会话。

修复分两处：
1. subscribe()内，若topic已经isSubscribed()，先topic.leave(false)（只清客户端和
   服务端的订阅态，不清本地已缓存消息），再执行真正的subscribe()，确保这次一定
   是货真价实的、服务端会认真处理getParams的订阅请求。
2. 把消息分页查询从withLaterData(MESSAGES_PAGE)（"给我比本地_maxSeq更新的消息"）
   改成withData(undefined, undefined, MESSAGES_PAGE)（"给我最新的N条消息"，不依赖
   本地缓存游标）。前者在_maxSeq被上述预览订阅污染后会查询"since:被污染的seq+1"，
   服务端自然返回空；后者是绝对查询，对全新话题（_maxSeq为0，两者退化成同一个
   since:undefined查询）行为不变，对被污染的话题能正确要回完整历史。

第14+轮最小粒度测试 Ch3-4 发现（P2P单聊消息状态机场景）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-06 13:46:58 +08:00
Your NameandClaude Sonnet 5 e6e51f625e 群系统事件消息改为居中纯文本渲染，不再走普通气泡+作者名的展示逻辑 
根因：群里的系统事件消息（成员加入、角色变更、公告发布等，x-im-type=system_action/
system_notice）服务端并不带真实的 `from`，但 messages-view.jsx 一直把它们和普通消息
一样交给 ChatMessage 渲染——chat-message.jsx 的 fullDisplay 逻辑会在气泡下方额外画一行
发送者名字，解析不到发送者时回退显示"未找到"。对照参考图 内容沟通对话3-开启进群验证与
拉人状态.png，这类系统事件应该是居中的纯灰字提示，不带头像、不带气泡、不带作者名——现状
既不符合参考图，也让"未找到"这种内部占位文案暴露给了用户。

怎么修：meta-message.jsx 新增 systemText 分支，复用日期分隔条同一套"居中提示"视觉语言
（.meta .bubble.system，无背景、纯居中灰字）；messages-view.jsx 在消息渲染分支里识别
system_action/system_notice 且不带可操作按钮（group_invitation_created 那种带
"立即加入"按钮的除外，仍走完整气泡展示）的消息，改为渲染 MetaMessage 而不是 ChatMessage。

验证：用真实群（3 个真实账号）走了两遍"扫码申请入群→通过审批"，会话里"有成员通过审批
加入了群聊。"正确显示为居中灰字，不再出现气泡、头像和"未找到"作者名；带按钮的
group_invitation_created 消息不受影响，仍是完整气泡+"立即加入"按钮。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-06 13:39:35 +08:00
Your NameandClaude Sonnet 5 a964d51ba5 修复回复/编辑消息触发风控弹窗时，"正在回复"预览条在弹窗结果出来前就被清空 
现象：对一条历史消息点"回复"，输入含链接的文本点发送，风控弹窗（安全提醒/警示级）
刚弹出的同时，composer 里"正在回复 XX"的预览条就已经消失了；如果这时候点"取消发送"，
这条回复就被永久放弃——原来引用的消息内容和回复关系不再存在，也没有任何提示，唯一的
恢复办法是回到那条历史消息重新点一次"回复"。编辑消息（修改一条已发消息的内容后再次
包含链接）是同一根因的同款问题，只是编辑可以靠重新点"编辑"找回原文，没有回复那么彻底
不可逆。

根因：sendMessage() 原来在根据 this.state.reply / this.props.forwardMessage 组装好
msg/head 之后，同步、无条件地立刻调用了 this.handleCancelReply()（清空 reply/编辑
状态），这一步发生在下面的 URL 风控检查（POST /security/urls/check）之前——但风控
弹窗要等用户点"继续发送"或"取消发送"才会真正决定要不要走 doSend()，这中间的等待期里
UI 状态已经被提前清空了。

修法：把 handleCancelReply() 从三处提前调用点移到 doSend() 内部、真正调用
this.props.sendMessage(...) 之前。这样它只在真的要发送时才执行——不含链接的普通消息
里 doSend() 本来就是同步立即执行，时机与原来完全一样；命中风控的消息里，"继续发送"
时才会触发（此时清空回复状态是正确的，消息确实发出去了），"取消发送"时 doSend()
根本不会被调用，回复/编辑的预览条和引用内容都会完整保留，可以直接修改文本重试或
自己手动取消。转发场景不受影响：转发消息不会触发这条风控检查（originalText 恒为
null），移动调用时机对它是纯粹的时序等价替换。

验证：真实浏览器操作，对一条消息点"回复"，输入含 https://example.com/a?token=abc123
的文本发送——警示弹窗弹出的同时预览条仍然可见；点"取消发送"后弹窗消失、预览条依旧
完整保留、composer 文本不变；再次点发送、这次点"我已知晓，继续发送"，消息正确以
带引用卡片的回复形式发出，预览条在发送成功后才清空。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-06 13:32:59 +08:00
Your NameandClaude Sonnet 5 cdca509183 修复群邀请消息卡片丢弃"立即加入"按钮，被邀请人无法接受邀请 
根因：POST /groups/{topic}/invitations 邀请成功后，后端会往邀请人与被邀请人的
单聊会话里发一条 x-im-type=system_action、template=group_invitation_created 的
消息，content.actions 里带着真实可用的 {type:"group_invitation_accept",
label:"立即加入", target_id:<invitation_id>}（对照参考图 6.3 加入群聊.png）。但
chat-message.jsx 原来对所有 system_action/system_notice 消息一律只取
content.text 渲染成纯文本，这个 action 数据被整体丢弃，消息只显示"邀请你加入群聊。"
没有任何按钮——im-api.js 里封装好的 acceptGroupInvitation() 因此从来没有调用点。

怎么修：chat-message.jsx 在原有的文本兜底之前，单独识别 content.actions 里
type=="group_invitation_accept" 的这一种模板，渲染一张带按钮的小卡片（其余
system_action/system_notice 模板的纯文本渲染保持不变，不受影响）；
messages-view.jsx 新增 handleAcceptGroupInvitation，调用 acceptGroupInvitation()
并用已有的 showToast 反馈结果，逐层传给 ChatMessage 的新 onAcceptGroupInvitation
prop。按钮点击后按 busy/joined/pending_approval/error 四态展示，避免重复提交。

验证：用两个真实账号（A 建群，直接对 B 发起 POST /invitations）复现，重新构建后
B 的会话里正确出现"邀请你加入群聊。"+"立即加入"按钮；点击后正确调用
POST /group-invitations/{id}/accept 并把返回的失败原因("服务器繁忙，请稍后重试")
展示出来——这一步暴露了一个独立的后端 500 bug（accept 接口本身的实现有问题，
已记录在测试报告里，不在本次前端修复范围内），前端的请求发起、按钮状态机和错误展示
均已确认按预期工作。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-06 13:26:14 +08:00
Your NameandClaude Sonnet 5 68044fa1bb 修复"查找聊天记录"跳转定位到原消息在全部入口100%失效 
componentDidUpdate里的jumpToSeq检查只在这个值发生变化时触发，但
tinode-web.jsx从不会同时渲染MessagesView和第7章侧边栏（!chapterSevenActive
门禁），所以从History的搜索结果/图片宫格/视频宫格跳转，每次都是卸载
第7章视图、挂载一个"首次渲染就已经带着jumpToSeq"的全新MessagesView
实例——componentDidUpdate根本不会跑（它不处理首次挂载）。7.12/7.15/
7.16全部"定位到消息来源"入口100%失效：jumpseq参数永久留在URL里，
会话固定停在最底部。

修复过程中还发现一个真实的竞态：首次挂载意味着componentSetup()刚刚
才发起topic订阅（异步、fire-and-forget），jumpToMessage自己的
topic.getMeta()调用要求订阅已建立，立即调用会抢在订阅完成前——实测
这个抢跑的getMeta()调用真实收到了服务端 {"code":403,"text":"permission
denied"} 拒绝（不是本地兜底，是真实的服务端往返），而真正的订阅请求
当时还在路上。改为轮询已有的isSubscribed()标志（而不是猜一个固定延迟
或改造subscribe()暴露其内部promise），封顶5秒，真正卡住的订阅仍会
落到jumpToMessage自己已有的错误处理上。

第十二轮最小粒度测试 Ch7 发现，已用真实浏览器验证：从工作台等其它
页面跳转过来时，消息正确加载、jumpseq参数正确从URL清除。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-06 05:30:53 +08:00
Your NameandClaude Sonnet 5 fc757cc043 修复消息发送失败/排队中时长按菜单仍提供"撤回" 
判断只查 params.seq > 0，未排除 tinode-sdk 本地占位 seq（LOCAL_SEQID，
268435455，同样是正数）——发送失败/仍在排队的消息会被误判成"已持久化
的真实消息"，点击撤回后端正确拒绝（无此消息），却给用户一个答非所问
的"请求内容有误"提示。

第十一轮最小粒度测试 Ch3-4 发现。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-06 02:13:34 +08:00
Your NameandClaude Sonnet 5 d759f67b11 第八轮最小粒度测试：修复CSS选择器/JSX结构不匹配的一整类bug，清理Tinode品牌残留 
第八轮改用"读CSS选择器+核对JSX结构"的方式复测全部11章，命中了7轮纯接口测试从未发现的一类
问题——选择器写对了但目标元素的实际DOM结构/className对不上，样式静默失效：

- 语音通话最小化胶囊按钮尺寸被同特异度规则覆盖；移动端悬浮通话窗口left/right/width三值同时
  生效导致过度约束；来电全屏页认证徽章/姓名标题缺少专属样式覆盖
- 我的收藏-语音卡片三列grid对应实际只有1个子元素，播放器被压缩到卡片左侧一角；链接/记录头部
  完全没有基础样式，退化成浏览器默认外观
- 多选模式下"收到的"消息气泡被flex auto-margin一起拖到最右侧；.avatar-box/#send-message-panel
  两处逗号断句错误导致后半句选择器丢失祖先限定
- 按住说话悬浮反馈渲染成内联胶囊，而参考图要求的居中悬浮卡片样式其实已经存在（挂在了另一个非
  生产demo组件上）；批量转发确认框沿用了80%视口高度；audio-player.jsx的playback类点在canvas
  上而非包裹层，波形和计时器可能纵向堆叠
- "消息已撤回"占位符误拼了日期分隔条的class而非专属的deleted

品牌清理：浏览器标签页标题、未读数标题更新均硬编码"Tinode"；LINK_CONTACT_US等三个链接常量
指向开源Tinode项目自己的域名（联系我们改为跟用户条款/隐私协议一致的toast，不再发起外部mailto）。

以及：空会话丢失.chat-box样式类、青少年模式PIN定位、若干收藏/文件类型展示细节。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-05 17:09:42 +08:00
Your NameandClaude Sonnet 5 f2218a822e 修复用户实测反馈的4处问题：品牌名泄露、修改密码页注释泄露、安全提醒页未居中、群相关行间距 
- 品牌名：BASE_APP_NAME 从 "TinodeWeb" 改为 "MeetingIM"（关于页/青少年模式文案不再暴露 Tinode 字样）；
  logo-view.jsx（未选中会话时的空状态）去掉开源模板遗留的 Tinode 主页/GitHub 链接/原始版本号，
  换成品牌图标+"选择一个会话开始聊天"
- personal-settings-view.jsx：删除 ChangePassword 页面里被误当正文渲染的开发注释（提及 Tinode 协议），
  改回真正的代码注释
- base.css：.risk-info-page（安全提醒整页）补 margin:0 auto——原来复用模态弹窗的 .risk-dialog 样式，
  宽屏下整块内容贴左显示，没有居中
- base.css：.group-member-picker/.group-settings-header/.group-member-section-title 的 strong/small
  漏加入既有的 line-height:1.3 覆盖名单，继承通用 button{line-height:2.2rem}，导致群成员列表/群聊设置
  头部的姓名与角色/简介文字行间距异常大、贴底部分割线过近

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-05 13:06:18 +08:00
Your NameandClaude Sonnet 5 bede45fd7f 第七轮深度测试：修复7个agent发现的12处前端问题，重点是列表分页截断与呼叫/播放状态机 
- 通话状态机（Ch8）：canStartCall 补齐通话中重复发起的防护，callShouldStart 补齐放弃/失败路径的清理
- 分页截断（Ch5-6）：新增 fetchAllPages 辅助函数，修复通讯录/黑名单/好友申请/群成员/管理员/禁言等
  11 处列表只读首页导致真实成员被遗漏的问题；群角色判断改用不受分页影响的 getGroup().my_role
- 消息与媒体（Ch3-4/Ch7/Ch9）：录音超时污染时长、手动重试丢失 head 导致消息被错误分类、批量删除
  未取消上传中附件、语音播放器补齐同时只能播一条、workplace-collaboration-view 冗余重试请求
- 独立密码/青少年模式（Ch10-11）：设置密码后按调用来源判断是否应自动开启青少年模式，避免关闭流程
  中途"忘记密码"被误当成开启；注销账号确认文案补充群主后果说明

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-05 12:18:25 +08:00
Your NameandClaude Sonnet 5 f42b8536e5 第六轮深度测试：7个并行agent覆盖全部11章，修复21处前端问题 
Ch1-2: 用户名注册邀请码错误改为友好文案(原为原始TypeError泄露给用户)；
  企业注册页扫描图标补上点击反馈。
Ch3-4: 发名片消息补传typeHint(此前被后端误分类成text，搜索/历史摘要显示成JSON)；
  文件卡片按mime大类区分图标颜色(此前所有文件都是同一个灰色通用图标)；
  表情面板补上专属退格/发送按钮(浅蓝禁用/深蓝启用两态)；订正一处与截图不符的代码注释。
Ch5-6: 群聊设置页"群成员"补上可点击的完整成员列表页(复用MemberPicker字母分组)；
  群文件页去掉无依据的硬编码"/10GB"容量上限显示。
Ch7: 收藏点击图片/视频缩略图补上预览；"查找聊天记录-链接"tab补上定位回原消息；
  文件下载页返回入口按来源tab纠正；批量转发成功计数改为按目标会话去重
  (原公式混用"收藏条数"和"目标会话数"两个维度，混选多条收藏转发时可能显示负数)；
  收藏/视频tab切换补上URL路由同步。
Ch8: topic.onInfo在通话期间补上事件转发(此前通话中"对方正在输入"和已读回执静默失效)；
  主叫等待接听页补上"正在等待对方接受邀请…"文案；语音通话最小化胶囊的还原按钮移出
  拖拽区域(原来嵌在draggable内部，指针捕获可能吞掉点击)；修复中等窗宽(641-750px)下
  本地摄像头预览遮挡"切换摄像头"按钮的CSS重叠。
Ch9: 部门树展开时跳过child_count=0的注定空请求；月报字数上限从硬编码1000改为读取
  后端真实的10000；发起会议补上"结束时间需晚于开始时间"的本地校验和更具体的报错；
  日报/月报统计接口补上department_id透传(此前包装函数注释断言后端会忽略，实际已支持)。
Ch10-11: URL风险检测补上g标志(原来一条消息只检查第一个链接，第二个链接哪怕是高危
  也不会被拦截)；补上"安全教育"设置入口(原功能完整实现但零入口，需手改hash才能打开)；
  修改密码按钮补上busy态反馈；青少年模式PIN页补上"忘记独立密码"入口(后端已支持重置，
  前端未接)；"关于我们"补上"联系我们"行。

7个agent同时对全部11章存量后端问题条目逐一复核，结论详见待整理的后端问题清单更新
(Ch1-2发现一条P0级后端问题：验证码固定值"123456"，已记录未修复，不在此commit修改
im_be仓库范围内)。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-05 03:48:28 +08:00
Your NameandClaude Sonnet 5 d42591284f 第五轮深度测试：管理员撤回、所有人@提醒、失效附件UI，并核对现存后端问题清单 
- messages-view.jsx: 拖拽发送/回复菜单在编辑态下的旁路修复；群主/管理员可撤回他人消息
  (对齐后端 authorizeIMMessageMutation 的 allowAdmin)；新增"所有人"@提醒(head.mention_all)。
- chat-message.jsx: system_action 头类型消息按 system_notice 同款渲染(此前显示"内容无效")。
- content-library-view.jsx: 语音/链接/图文收藏与聊天记录卡片补上 removed(已失效)态UI，
  之前只有 FileCard 处理了这个状态。
- call-panel.jsx: handleVideoOfferMsg(5步.then链，用reject sentinel跳过后续步骤)、
  handleToggleSpeakerClick 补组件卸载守卫，修完此前遗漏的两处。
- group-management-view.jsx: 治理开关(Governance.setField)和群主转让(OwnerSelect)
  补上乐观锁 version 参数(此前从不传，服务端 version<=0 时会跳过冲突检测)；群文件搜索框
  文案承诺"搜索文件名或者上传者"但服务端q参数只匹配文件名，改为拉取全量列表本地按文件名+
  已解析的上传者昵称一起过滤；群公告详情页补上从未被调用过的已读上报(readGroupAnnouncement)。

以上均用真实账号在浏览器/直接请求验证：管理员撤回、system_action渲染、mention_all、
文件按上传者搜索、公告已读上报(200)、治理开关stale-version探测确认409冲突检测生效。

7个并行测试agent对全部11章做了第二轮回归+现存后端问题清单逐条复核，结论待整理进
docs/IM-后端问题清单*.md（全部现存条目复核后均建议保留，多条证据强度从推断升级为已验证）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-05 02:07:47 +08:00
Your NameandClaude Sonnet 5 4a30cfa6b3 第四轮深度测试：修复7个agent发现的问题，重点是编辑态附件覆盖的完整旁路和通话面板崩溃防护 
再次派7个agent覆盖全部11章，验证第三轮修复+找新问题。本次委托agent专门交叉核对
上一轮每一项修复是否真的生效，多数确认有效，但抓出2处"看似修好、实则有旁路"的情况
和若干新问题。

**编辑消息+拖放文件仍可静默覆盖被编辑消息（上一轮修复的完整旁路，Ch3-4 agent发现）**
上一轮给`onAttachFile`/`onAttachImage`/`onAttachAudio`三个prop加了editingMessage门禁，
但`isDragEnabled()`（messages-view.jsx）没有检查这个状态——拖放文件到聊天窗口走的是
`handleFileDrop`直接调用`handleAttachImageOrVideo`/`handleAttachFile`类方法本身，完全
绕开了被置null的props。编辑态下不点"+"号、直接把文件拖进聊天窗口，依然会静默替换掉
被编辑消息的原文。已给`isDragEnabled()`补上同款判断，这是`handleDrop`和渲染层拖放提示
两处调用的唯一门禁函数，一次性堵住。

同一个agent还发现编辑态下点击"回复"另一条消息会静默放弃当前编辑（`handlePickReply`
覆盖`this.state.reply`但不清`contentToEdit`，发送时值走了`reply`分支而不是`editing`
分支，编辑框里的原文被当成对另一条消息的新回复发出去，原消息未被修改）——已在
`handleShowMessageContextMenu`里比照`menu_item_edit`的年龄过滤模式，编辑态下直接不
提供"回复"这个菜单项。

**实名认证驳回提醒的dismissKey修复上一轮实际没生效（Ch1-2 agent发现，已重新修复）**
上一轮把dismissKey从纯status改成"submission_id或status"，但live验证发现
`bootstrap.security.realname`这个数据源根本不包含submission_id字段（后端serveIMBootstrap
的实现只有status/required/allow_skip/remind_after四个硬编码字段）——所以这个修复在
真实环境下永远退化回status，等于没有变化，两次独立驳回依然会互相误压制提醒。这次改为
额外调用专用的`GET /security/realname`接口（该接口的实现确实会返回submission_id），
用它的数据驱动dismissKey和提醒触发条件，bootstrap的字段只保留用于remind_after/
allow_skip这些它独有的字段。已用真实账号验证dismissKey现在正确从这个新数据源生成。

**呼叫面板未卸载防护补全到call-panel.jsx（Ch8 agent发现，同类问题上一轮只修了
audio-recorder.jsx）**
`start()`/`unmuteVideo()`/`handleSwitchCameraClick()`三处的getUserMedia/
enumerateDevices异步链，结尾都会touch `this.localRef.current`/`this.state.localStream`，
但都没检查组件是否已经卸载——权限弹窗未决出结果时通话结束（呼出超时/收到挂断/对方
主动挂断)，这些promise resolve后会在死实例上抛TypeError，被各自的catch吞掉后又会展示
一句过期的原始英文报错。三处都补了`this._unmounted`检查，拿到的媒体流/轨道直接停止
而不是继续使用。

**其余修复**：`call-message.jsx`补上和`call-status.jsx`一致的"进行中"状态文案（原来
通话进行中且消息还没有最终时长时显示"0:00"而不是"进行中"，已用真实渲染验证过两个
组件行为不一致）；`tinode-web.jsx`的`handleCallClose`补上重置`callSeq`（避免跨通话
残留旧值）+ 更新`armCallRingTimeout`注释准确描述它是后端30秒建立超时的二级兜底而非
主要防线（后端`call_establishment_timeout`默认30秒，已有独立机制处理"直接不接"的
常见场景）；`REASON_MESSAGES`补充`API_KEY_REQUIRED`/`METHOD_NOT_ALLOWED`（此前记录过
一次真实的部署期API Key配置漂移事故，属于这两个reason的真实触发场景）；
`message-center-view.jsx`的`NOTIFICATION_TEXT`补充风险确认"取消"结果的文案（发消息
前风险提示点"取消发送"会产生这个系统通知，此前只收录了"继续"）；会话列表"置顶"从
只变背景色改为真正排到列表最前（原来只有CSS着色，没有任何排序逻辑，已用真实群聊
置顶验证过排序生效且系统消息/文件助手两个固定入口仍保持在最前）；好友聊天设置页
置顶/免打扰开关在初始GET未完成前禁用（避免`version:null`打到后端400）；
`content-library-view.jsx`的`DownloadPage`修复带外附件下载使用未做域名归一化的裸
相对路径（生产环境webapp和文件域名跨域时会必现下载失败，已拆出`resolveFileUrl`
辅助函数只做URL拼装不做预先fetch，跟`getFileUrl`的实际下载区分开）；
`security-support-view.jsx`的意见反馈分类配置改用`useCachedData`获得重试能力（原来
独立实现的边车缓存逻辑没享受到本轮`use-cached-data.js`的重试修复）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-05 01:03:41 +08:00
Your NameandClaude Sonnet 5 93b856aec8 第三轮深度测试：修复7个并行agent发现的前端问题，含REASON_MESSAGES系统性补全 
派了Ch1-2/3-4/5-6/7/8/9/10-11共7个agent对全部11章重新深度测试。后端问题已核实追加进
docs/IM-后端问题清单-2026-09-04.md（新增6-9条，发给用户）；本次是前端问题的修复。

**REASON_MESSAGES系统性补全（最高优先级，多个agent独立发现同一个缺口）**
im-api.js的REASON_MESSAGES表新增22个条目，最重要的是PERMISSION_DENIED——后端
server/im_http.go里403响应统一用这个reason（30余处调用），但表里原来只有一个从未
被后端实际发送过的死条目FORBIDDEN，导致全站几乎每一个403从工程一开始就在展示原始
英文"permission denied"。一并补上VERSION_CONFLICT/MALFORMED_REQUEST（Ch9 agent实测
命中）、NOT_FOUND、VERIFICATION_RATE_LIMITED（动态文案，同TOO_MANY_ATTEMPTS模式）等。
新增translateReason()导出函数并用于send-message.jsx的sendFavorite——favorites/forward
等几个批量接口恒定200、真实成败包在items[].reason里，imRequest的自动翻译够不到这种
per-item场景，之前直接显示原始reason字符串。tinode-web.jsx同理补了CTRL_ERROR_TEXT_CN
（原生WS {ctrl}协议错误，同样绕开REASON_MESSAGES）并修了原表从未真正匹配过的bug——
CommError会把状态码拼进message变成"authentication failed (401)"，原表按裸文本精确
匹配，看着正常纯粹是因为401/403兜底文案凑巧一样，一旦命中"unknown authentication
scheme"这类会被兜底文案误导、"policy violation"这类会直接漏出英文。uploadLargeFile/
createChatUploader/createFileDownloader同样绕开REASON_MESSAGES（走原生{ctrl}协议），
补了UPLOAD_CTRL_TEXT_CN小词典。已用真实账号端到端验证：favorites/forward到P2P目标
触发的PERMISSION_DENIED现在正确显示"没有权限执行此操作"；draft接口版本冲突正确显示
"内容已被修改，请刷新后重试"。

**编辑消息时打开附件面板会静默覆盖被编辑消息（Ch3-4 agent发现，数据损坏级别）**
sendMessage对editing状态一律用head.replace，但onAttachFile/onAttachImage/onAttachAudio
原来只在forwardMessage时置空，编辑态没有同款门禁——编辑一条消息不改文字、点"+"选张图片
或名片，会直接把附件内容替换掉被编辑消息的原文，无任何确认。messages-view.jsx新增
editingMessage门禁，和forwardMessage一样把三个attach回调置空（等价于隐藏整个"+"按钮）。
已用真实浏览器验证：编辑态下"+"按钮消失，取消编辑后正常恢复。

**草稿防抖单一共享定时器丢字（Ch1-2、Ch3-4两个agent独立发现）**
handleComposerChange用单个this.draftSaveTimer，话题A打字触发600ms保存后300ms内切到
话题B，会把A的定时器clearTimeout掉，那次输入永久丢失；version也在定时器触发时才重新
读state，此时可能已经在别的话题上，退化成硬编码0——叠加后端draft接口对version=0"无条件
跳过乐观锁"的行为（已记入后端清单新增6），可能静默覆盖别的标签页写入的更新草稿。改为
按话题分开的定时器map，version在调用的当下（保证仍在该话题）同步捕获进闭包。

**呼叫状态机两处真实bug（Ch8 agent此前发现，本次重新核实live代码后确认+修复）**
1. 通话中导航离开messages-view.jsx整个组件树（切到工作台/个人设置，或移动端切回会话
   列表）时，没有任何hangup清理——componentSetup已有的"切换话题时正确挂断"逻辑只在
   componentDidUpdate里，组件真正卸载时不会触发。CallPanel自己的componentWillUnmount
   只做本地清理，不通知对方也不重置tinode-web.jsx顶层callState，导致下次切回通话话题
   时remount出一个callState卡在CALL_STATE_IN_PROGRESS的"僵尸"面板——start()走"我们刚
   接听"分支直接return，从不调getUserMedia，本地媒体永久拿不到。补了对称的
   componentWillUnmount挂断逻辑。
2. this.callTimeoutTimer声明后从未被真正setTimeout赋值——呼出无人接听或accept信令
   （fire-and-forget的{note}包）被丢会永久卡在"呼叫中"。补了armCallRingTimeout()，
   60秒未接通按跟手动取消完全一样的路径挂断（不发明新的通话结果语义），在收到对方
   accept信号的两处分支都正确清timer。

**其余前端修复（按文件）**
- messages-view.jsx: @提醒mentionedUsers只在切话题时清空，同一话题内后续消息里字面
  文本"@张三"会被静默解析成真实提醒（发送后清空）；jumpToMessage点开已撤回/删除的
  搜索结果原来只console.error静默失败，补了用户可见的错误提示；批量收藏对
  favorites/batch共享Idempotency-Key导致的静默丢失（已知后端问题）不再照单全收
  "收藏成功"，改为发送后重新拉取真实收藏列表核对每条是否真的落地。
- audio-recorder.jsx: getUserMedia权限弹窗未决出结果时组件被卸载，补_unmounted
  标记避免在死实例上继续跑mediaRecorder.start()。
- send-message.jsx: disabled变为true时（对方拉黑/被禁言等实时ACS变化）没有强制结束
  正在进行的按住录音，可能remount出无用户手势的"自动录音"；mouseup/touchend覆盖不到
  拖出窗口/切换标签页/权限弹窗抢焦点的释放场景，补了blur/visibilitychange兜底。
- tinode-web.jsx: messages-menu视图和messages-home共用MessageCenterView实例无key，
  从messages-home以非整体刷新方式切到messages-menu时菜单打不开，补key={view}。
- message-center-view.jsx: 实名认证驳回提醒的dismiss key只按用户+状态区分，同一状态
  的两次独立驳回会互相误压制，改按submission_id区分。
- contact-management-view.jsx: Profile/Settings靠getUserProfile刷新拉黑状态，但该
  接口对被拉黑对象直接403，导致"之前会话就已拉黑"的场景完全感知不到——叠加
  getConversationContext兜底（该接口对拉黑目标正确返回200+relationship）。
- group-management-view.jsx: AdminList显示群主/管理员姓名漏了group_nickname兜底；
  JoinRequests从聊天页横幅进入时返回按钮硬编码回group-settings（应回聊天本身），
  从Governance进入时返回group-settings而非group-governance（与AdminList/Muted不一致）。
- workplace-collaboration-view.jsx: OrganizationDirectory/DeptNode的部门树加载失败
  被无条件当成"暂无数据"渲染，补loadError区分+重试链接。
- personal-settings-view.jsx: CacheClear对navigator.storage/caches整个不存在的情况
  只有react出了范围的.catch()覆盖不到的同步抛错，加了特性检测+try/catch；
  YouthModeVerify触发TOO_MANY_ATTEMPTS锁定后确定按钮没有禁用/倒计时，会继续发出
  注定失败的请求。
- security-support-view.jsx: 意见反馈category字段在config未加载完成前可为空但没有
  提交前校验，会打到后端400。
- use-cached-data.js: bootstrap等首次拉取失败且无缓存兜底时永久停在undefined，加了
  一次3秒后重试（仅在完全没有缓存值时触发，已有缓存值维持原"显示旧数据"行为不变）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-04 23:29:52 +08:00
Your NameandClaude Opus 5 505a6d7d56 补齐第3-4章composer功能缺口：跨话题草稿/@提醒/表情面板/附件面板/名片/收藏发送/按住说话/语音未读红点 
第3-4章复测确认这批原型图要求的功能之前完全没做（真实聊天引擎 messages-view.jsx/
send-message.jsx 从Ch1开始一直是最基础的版本：两个附件图标+文本框+发送/麦克风，
没有@、没有表情面板、没有7宫格附件面板、没有名片/收藏发送、语音是点一下进入录音模式
不是按住说话）。这次一次性把8项都接上，除了新功能外，过程中顺带发现并修了4个真bug。

**跨话题草稿**（im-api.js 新增 getTopicDraft/updateTopicDraft，messages-view.jsx）
话题切换时拉取 GET /topics/{topic}/draft（真实验证过P2P用原生话题名——对方user_id——
可以正常读写，接口内部自己会查Subs.Get校验，不需要额外归一化），输入框内容600ms防抖
PUT回去；真正发送成功后立即清空服务端草稿，不等下一次防抖。真实验证：输入文字→切走
再切回→草稿还在；刷新整个页面（新WS会话）→草稿依然从服务端正确恢复。

**@提醒**（send-message.jsx 新增 mention 相关状态和UI，messages-view.jsx 新增
mentionSearch/mentionedUsers/applyMentionResolution）
只在群聊开放，检测"光标前最近一个未闭合的@"触发面板，调 getGroupMembers(topic,
{mentionable:true, query}) 做实时搜索。协议层面：Tinode原生Drafty.parse本来就会把
纯文本里的"@word"自动识别成MN实体，但data.val存的是匹配到的原始文字，不是uid——
真正的uid只有用户从选择器里点选时才知道，记在 messages-view.jsx 的
this.mentionedUsers，发送前重新parse一遍把匹配上的占位符换成真uid。真实验证：选
"kcg051307"发送后直接查后端存储，MN实体的data.val确认是真实uid
"usrYVeV0yZs8tw"，不是原始文字。

**表情面板**（send-message.jsx）
2个tab（😊表情/♡常用），常用表情本地localStorage维护。图片没有拍到第二个tab具体
内容，判断"常用"是这类两tab设计里最常见、也是本项目里唯一有本地存储依据能撑起来的
语义。真实验证：点表情正确插入文本框，用过的表情正确出现在"常用"tab。

**7宫格附件面板**（send-message.jsx，替换原来常驻的照片/文件两个图标）
照片/拍摄/语音通话/名片/文件/收藏/视频通话。语音通话、视频通话复用第8章已有的
handleStartAudioCall/handleStartVideoCall（从 tinode-web.jsx 新抽出 canStartCall()
方法，同时替换掉"..."菜单里原来的内联判断，避免同一个判断逻辑两处维护),仅P2P且
真实通话功能可用时才不置灰——真实验证过群聊里这两项正确显示为禁用状态。

**名片消息**（send-message.jsx openCardPicker/sendCard，复用原生TheCard/
Drafty.appendTheCard）
选好友生成名片，uid必须用TheCard.setTinodeID写进vCard的comm数组（不是随便塞进某个
字段——widgets/the-card-mini.jsx渲染时用TheCard.getFirstTinodeID读这个协议项来判断
"发消息"按钮指向谁）。真实验证：选中好友后发出的名片消息真实带"聊天"按钮，点击可用。

**收藏发送到当前会话**（send-message.jsx openFavPicker/sendFavorite，复用Ch7的
forwardFavorites接口）
真实联调中发现并修复一个新bug：这个接口和其它几个批量接口一样，HTTP层恒定200，
真实成败要看items[].status——原来的写法完全没检查这个字段，等于假装总是成功。已改成
检查失败项并报错。同时真实测试还发现该接口对P2P目标会返回200+items[0].status:
"failed", reason:"PERMISSION_DENIED"（哪怕是真实好友、这个会话本身发消息完全正常），
看起来是后端这个接口自己的写权限判断有问题，不是前端能修的，已记录。

**按住说话+上滑取消录音**（send-message.jsx新增手势处理，audio-recorder.jsx新增
holdMode展示态）
mousedown/touchstart直接挂载AudioRecorder（挂载即开始录音，复用原有机制不动），
移动超过80px判定为"松开取消"，松手时通过ref直接调组件内部的handleDone/handleDelete。
过程中发现并修复3个真bug：① injectIntl包裹AudioRecorder默认不支持ref转发
（"Function components cannot be given refs"警告，ref静默失效)，加
{forwardRef:true}修好；② handleDelete从来没有像handleDone那样判空mediaRecorder，
录音还没真正开始（getUserMedia尚未resolve)就点删除会直接抛TypeError，这是原有代码
一直存在的问题，这次因为按住松手可能在录音刚开始的瞬间发生而被真实触发；③
cleanUp()同理没判空this.stream。补上判空后，"从未真正开始录音就结束"这个场景会
直接当作取消处理并正确调用onDeleted，不会再把UI卡在录音态出不来（真实验证：这个
环境的浏览器面板本身会拦截麦克风访问，用这个"getUserMedia永远拒绝"的真实场景反而
完整测出了正常/取消两条路径在录音真正开始前结束时都不再卡死或报错）。

**语音消息未读红点**（chat-message.jsx/audio-player.jsx/formatters.js）
纯客户端概念，原生Tinode的recv/read只到"消息本身有没有被看到"，跟"这条语音有没有
真的被点开听过"是两回事。audio-player.jsx的播放按钮新增可选onPlay回调（不传不影响
现有调用方），formatters.js的AU分支透传给它，chat-message.jsx按话题维护一份
localStorage"已播放seq集合"，对收到的（非自己发的）语音消息，没播放过就在气泡右上角
显示红点。真实验证：用原生SDK的_routeData往话题本地缓存注入一条真实结构的语音消息
（浏览器面板拦截麦克风，没有真实语音消息可用，用这个方式验证渲染/播放回调/持久化
三段逻辑），红点正确出现；直接触发播放回调后红点消失且localStorage正确写入对应seq。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-04 21:59:09 +08:00
Your NameandClaude Opus 5 5a07bb4e3b 修复全页面走查发现的 P0 前端问题（第一批） 
八个 agent 对 11 章逐页对照设计稿+后端源码后，先修其中"功能不可用/崩溃/谎报成功"级别的：

崩溃与数据错误
- content-library-view: Highlight 按 [start,len] 数组解构后端返回的 {start,end} 对象，
  对象不可迭代会直接抛 TypeError，任何文本搜索命中都让整个结果区渲染崩掉。服务端偏移还叠加
  两个问题（Go 字节下标 vs JS UTF-16；偏移基准是全文但 snippet 会被开窗截断），改为在展示
  文本上本地匹配关键词。
- content-library-view: firstAttachment 用 Drafty.attachments，SDK 里硬过滤 tp=='EX'
  只认文件附件，图片(IM)/视频(VD)/语音(AU) 一个都取不到——收藏缩略图、语音播放源、聊天记录
  图片视频宫格全部拿不到资源。改用 Drafty.entities 按类型分派（chat-message.jsx 已有先例）。
- message-center-view: 系统通知的机器码兜底会把真实数据吞掉（日报提醒的 summary 就是日期
  字符串 "2026-08-20"，会议通知的 summary 是标题），改为查表命中才替换。
- message-center-view: 会话列表漏了 avatar 字段，每行都只能落到兜底图标；同文件
  frequentContacts() 本来就是对的，照它补上。

功能不可用
- auth-onboarding-view: 首次开启青少年模式是死路——设完密码丢弃了服务端返回的
  enable_action_token，从不调 enableYouthMode，用户走完短信验证+设密码后模式仍是关的。
  现在拿着这个 token 把最后一步做完。
- group-management-view: "投诉/举报"是个 onToast('暂未开放') 死桩，而 target_type='group'
  这条链路早就通了。接上真实举报页。
- tinode-web: 刷新/深链会被弹回首页。两个原因叠加：初始化白名单还是上游 Tinode 的
  ['cred','reset','register']；handleLoginSuccessful 无条件把 hash 改写成 workbench，
  刷新触发的自动登录也走这条。抽出 SIDE_PANEL_VIEWS 常量复用，并区分登录流程与自动登录。
- widgets/meta-message: deleted 分支从未实现，撤回一条消息后时间线上什么都不剩。

谎报成功 / 判定错误
- tinode-web + personal-settings-view: 改密码不返回 Promise，服务端拒绝时照样弹"密码已更新"。
- group-management-view: 禁言批量读 result.succeeded，但该接口返回的是 {topic, items}，
  succeeded 恒为 undefined，不管成没成都弹"设置成功"。两个接口结构不同，分开判定。
- workplace-collaboration-view: 会议取消状态写成 'cancelled'，后端是 'canceled' 单 l，
  会议取消后"取消会议"按钮还挂着。

样式与显示
- base.css: 删掉旧版 .organization-department 的 padding-left !important，它压过按层级算出的
  内联缩进，导致部门行全平、只有人员行缩进。
- base.css: 补 .youth-password-gate（原来 0 条规则），PIN 框缺 position:relative 和居中。
- security-support-view: shield_lock 不在经典 Material Icons 里（只有 Symbols），会显示成
  字面文本；.risk-info-page 也是 0 条规则，整页渲染成裸项目符号列表。改用 verified_user 并
  补上 .risk-dialog。
- contact-management-view: 好友资料页性别直接输出后端枚举，显示成 "male"。
- workplace-collaboration-view: 层级标注两条路径两种格式（树形深三层变"3级"、搜索硬传"三"），
  统一成一个 helper。

已记录不在前端修的后端缺口：recallMessage 的 version 只能传 1，因为所有消息读取接口
（messagePayload/messageSearchPayload/mediaMessagePayload/favoriteSnapshot）都不下发 version，
冲突错误里也不回传真实值，被编辑过的消息撤回必然失败。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-03 18:31:26 +08:00
Your NameandClaude Sonnet 5 251c9de87c Convert im_webapp from static mock prototypes to real backend integration 
Implements all 11 product chapters (auth, messaging, contacts, groups,
files/favorites, calls, workplace/reports, settings, security) against the
real /v1/im REST API and native Tinode WS protocol, replacing the hardcoded
mock data the ba8f48ee prototype commit shipped with. Adds src/lib/im-api.js
as the REST client, plus supporting fixes across messages-view.jsx and the
attachment/upload/download pipeline (wrong SDK auth headers, group topic
naming, seq/timezone edge cases) found via live end-to-end testing against
the real backend.

Backup checkpoint before reconciling with origin/dev's parallel rewrite.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-03 11:40:53 +08:00
or-else e6dfde28f6 restore topic subscription after a reconnect 2026-03-01 18:31:24 +03:00
or-else 234fb48b93 cleanup 2026-01-20 12:58:58 +03:00
or-else a54ae70746 split out a few modules, handle esc key 2026-01-19 15:41:33 +03:00
or-else dea781b423 adding TheCard preview 2026-01-17 12:55:45 +03:00
or-else 930f4f0656 TheCard handling in messages 2026-01-16 20:51:57 +03:00
or-else 4cd3e84178 make subscriber count work with older server 2025-10-28 12:32:52 +03:00
or-else ca492e2e93 wallpapers in dark/light mode seem to work now 2025-10-26 21:51:40 +03:00
or-else ec3974f2f0 dark/light mode wallpaper filters partially work 2025-10-26 19:56:55 +03:00
or-else 16e688d4c1 fix CallPannel: do not remount between menimized/full screen 2025-10-10 14:58:01 +03:00
or-else 1085d1caf6 allow messaging while call is in progress (same topic only for now) 2025-10-08 16:49:45 +03:00
or-else abf5b19758 translations added 2025-10-06 21:02:41 +03:00
or-else 8ca7f5cd3e support for showing the number of subscribers 2025-09-29 20:51:51 +03:00
or-else 79a1bc98b2 add config option to send on Enter vs send on CTRL-Enter 2025-08-10 15:25:05 +03:00
or-else 7d1011400e merge devel 2025-08-10 12:15:14 +03:00
or-else 56790262f3 rename drafty form response content type to text/x-drafy-fr 2025-08-10 10:30:47 +03:00
or-else 6bec95e084 automatically change mime-type of json files to application/octeat-stream 2025-08-07 16:12:51 +03:00
or-else 6d02cc903c dark mode mostly done 2025-06-13 16:26:48 +03:00
or-else 14b38af8da merge devel 2025-04-14 09:54:36 +03:00
or-else 43fde20643 fix unread count for topics with all messages deleted 2025-04-10 16:20:33 +03:00
or-else b1acfecd4f fixing translations 2025-03-12 19:40:33 +03:00
or-else 3b78971a39 fix menu [delete for all] 2025-03-06 16:41:25 +03:00
or-else 5e92189b97 ability to hard-delete p2p messages, debugged pinned messages 2025-02-22 18:55:53 +03:00
or-else 30bf77d4ba sending messages to self works 2025-02-16 22:06:02 +03:00
or-else 6c1c8cf336 removed incomplete video conferences 2025-02-14 21:40:44 +03:00
or-else 02e8bd2f74 merge devel 2025-02-08 19:50:34 +03:00
Andrew 5fb85ce822 Fix sending of "read" notifications after backing out of a group on mobile. 
https://groups.google.com/g/tinode/c/DMmeN79dZe0
 2023-08-11 15:46:46 -04:00
or-else 94575b5a07 pass viewport to call panel 2023-06-15 13:11:23 -07:00
or-else a86d07f854 merge next 2023-06-10 12:14:59 -07:00
or-else 5d664b86cb merge devel 2023-06-09 17:16:22 -07:00