Your Name
0de8c0b5ac
fix: message list shaking/flickering when scrolling to top or bottom
...
topic.onData = notify (wireTopicCallbacks) fires once per individual
message, not once per batch. Live-instrumented a real loadOlder() page
fetch (24 older messages): scrollHeight/scrollTop mutated in ~14
separate small steps over ~400ms, each one racing loadOlder()'s own
scroll-compensation and ConversationView's separate autoscroll-to-
bottom effect before the page had actually finished arriving -- that
rapid multi-step crawl is what reads as "shaking" rather than one
clean jump.
Coalesce notifications landing within the same animation frame into a
single flush, so a burst of onData calls (initial load, loadOlder(), a
fast run of incoming messages) triggers at most one re-render per
frame instead of N. messageSnapshots invalidation stays synchronous
(pure cache bookkeeping); only the listener callbacks that schedule
React's re-render are batched.
Live-verified with the same instrumentation: the same 24-message
loadOlder() fetch now produces 2 dom-mutation events instead of 14,
with scrollTop only moving once the batch has actually settled instead
of crawling in lockstep with a growing scrollHeight.
2026-09-18 17:11:40 +08:00
Your Name
f5a512b8c9
fix: recall/edit not syncing to the other party in real time
...
docs/IM-前后端对接文档.md:416,1256 documents a custom {info what:"im",
event:"message.recalled"|"message.edited"} push to every other online
topic member, with an explicit instruction to refresh that message by
topic+seq+version rather than waiting for the user to re-enter the
conversation. Nothing recognized "im" as a valid `what` value (the
native SDK's own _routeInfo has no such case either, same gap as the
existing group.dissolved handling right above this fix), so the push
arrived over the wire but never triggered anything -- the peer's local
message cache kept the stale pre-recall/pre-edit content until some
unrelated full resync happened to refetch it.
Widen the `what` union (both the app-level RawTopicInfo and the SDK's
own onInfo callback type) to include 'im', and on that event issue the
same targeted single-message getMeta(...).withData(seq,seq+1,1) refetch
ConversationView's jump-to-message feature already established.
Live-verified: recalling a message now shows "⚠ 消息已删除" on the
other party's screen immediately, with no manual refresh.
2026-09-18 16:09:52 +08:00
Your Name
1a4a96461a
feat: show group announcement read count and send read receipts
...
Backend added read_count/member_count/read_summary to the announcement
payload in today's deploy (previously confirmed absent). Wire it up:
- groups.ts: add the three fields to the GroupAnnouncement type.
- GroupAnnouncementModal.tsx: render "已读N/M" per README §4.8, and
call readGroupAnnouncement() on open -- that endpoint existed in
groups.ts already but was never called from anywhere, so opening an
announcement never told the server this member had read it.
2026-09-18 16:05:04 +08:00
Your Name
b4675b70e1
docs: correct root-cause comment on avatar CORS investigation
...
The OSS bucket's CORS rule does allow the app's auth headers -- just
scoped to the real web/web1-5.118im.com origins. The earlier failure
was from testing against a local dev origin, never in any CORS
whitelist, not from OSS lacking CORS entirely.
2026-09-18 15:18:32 +08:00
Your Name
74f4e753ef
fix: don't route already-absolute avatar URLs through authenticated fetch
...
Default-avatar placeholders return avatar_file_id as a complete OSS URL
rather than a short file id. The previous fix stopped re-wrapping that
URL into a malformed /v0/file/s/https://... request, but still routed
it through useAuthedBlobUrl's authenticated fetch -- live-confirmed
that OSS bucket serves default avatars with no CORS headers at all, so
the cross-origin fetch carrying auth headers gets blocked at preflight
and the tile silently falls back to the plain letter. An absolute URL
needs no credentials; render it directly as a plain <img src> instead.
2026-09-18 15:13:27 +08:00
Your Name
7fff1a7b3a
fix: call media-connect state, blocklist banner staleness, group rename, avatar URL
...
- stores/calls.ts, CallRoot.tsx: distinguish signaling-connected from
actual media-joined (mediaJoined flag), so a call whose mic never
attaches no longer shows a live timer/"网络良好"; propagate a
disconnected reason on post-accept media failure so both sides agree
on the outcome instead of one side seeing a normal "已结束".
- DetailColumn.tsx: invalidate conversation-context alongside blocks on
block/unblock, so the composer's blocked-notice banner updates
immediately instead of only after a window-focus refetch.
- GroupDetailColumn.tsx: add an owner-only group rename control
(updateGroup was already implemented but never wired to any UI).
- Avatar.tsx: stop re-wrapping an already-absolute avatar_file_id (seen
on default-avatar placeholders) into a malformed
/v0/file/s/https://... request.
2026-09-18 15:01:08 +08:00
Your Name
0c5b329179
修复Zentao批量报告的6个前端bug：来电UI不弹出/黑名单发送无提示/群名校验/群人数与通话记录显示uid
...
用户提供了一份Zentao导出的bug清单（#21/23/24/25/26/27/28共7条），逐条实机复现
排查，修复了其中6个真正的前端bug，1个是纯后端问题（禁言不生效）已记录到
docs/IM-后端问题清单.md，1个（好友申请404/500）未能独立复现只记录了测试团队
的原始报告，另1个（离线状态推送）实测后确认并非报告描述的"永久不更新"，只是
有正常的心跳超时延迟。
- **#23 来电UI完全不弹出**（根因最深的一个）：initCallSignaling用的是
`me.getMeTopic().contacts()`枚举联系人再查最新消息——但这个方法只反映`me`
话题自己的订阅同步进度，一个P2P话题可能早就真正订阅上、能收到消息，`me`的
同步却还没跟上，导致这个联系人在枚举里直接消失。用两个真实账号实机验证：
被叫方`me.contacts()`只枚举出1个群，主叫方完全没出现，来电消息静默丢失。
topics.ts里`getChatListSnapshot()`自己的注释早就写明了这个坑、并且已经改
用`mapTopics()`规避，只是`stores/calls.ts`这个监听器当时没有跟着改。现在
统一复用`getChatListSnapshot()`，实机验证来电卡片正确弹出。
- **#28 拉黑后发送消息无原因提示**：读tinode-sdk源码确认发送失败的具体原因
从架构上就拿不到——`Topic#publishMessage`自己的`.catch()`把服务端拒绝原因
吞掉、只留一个`_failed`标记，不会重新抛出。改成事前判断：新增
`getConversationContext()`（P2P专用，`relationship`字段区分
`blocked_by_me`/`blocked_by_peer`），发送区直接换成对应文案的横幅，两个
方向都拿真实账号互相拉黑验证过。
- **#26 群名超长/留空自动名两个校验问题**：`MAX_TITLE_LENGTH`一直是60，但
后端`im_http.go`真实校验的是32字（读源码确认），导致33-59字之间的群名能
输入、能提交，然后被后端拒绝只显示通用错误。改成32，从输入框这一层就不
再放行超长名。另外群名留空时自动拼接的成员昵称组合，理论上可能被内容审核
拒绝——这种情况下用户根本不知道"名字"是问题所在，补了针对性提示。
- **#27 通话记录/群列表显示原始uid、群人数显示0人**（2处独立bug）：
1. `CallHistoryView.tsx`按`peer_user_id`（真实usr id）去匹配聊天列表的
`contact.topic`（建立过真实会话后已经是服务端重命名过的p2p哈希），两个
不是同一个id空间，永远匹配不上，一直显示原始id。改成用`item.topic`
（已确认和chatlist的topic是同一个值）去匹配。
2. 实测发现`GET /groups`列表接口的`member_count`会返回0，但同一个群
`GET /groups/{topic}`单独查询正确返回4——两个接口的计数器不一致（后端
已知问题，见问题8），前端这次统一改成"读到0就不显示人数"而不是显示一
个已确认错误的数字。
以上改动均跑过`tsc -b --noEmit`/`oxlint`/`vite build`，除#26外全部用两个真实
账号（systest02/systest04）互相操作实机验证。
2026-09-17 21:51:00 +08:00
Your Name
50767f701f
修复已建立的P2P会话详情栏/头像404：话题名不是对方user_id
...
用户报告：控制台反复出现 GET /v1/im/users/p2pp77kUAkgqpVbZoiTpjPWtg/profile
404。根因：这个应用的多处代码（DetailColumn的好友资料/拉黑/备注/删除好友，以及
本会话早前刚加的头像peerProfileQuery）一直假设"P2P会话的topicId就是对方的
user_id"——这个假设只在"第一次用对方usr...地址打开、还从未真正subscribe过"
这个短暂窗口内成立。读tinode-sdk源码确认：一旦subscribe成功，SDK会把这个话题
从usr...地址重命名为服务端分配的真实p2p...哈希名，而Topic.topicType()自己的
前缀表里根本没有p2p这一项（只有usr映射到P2P类型），导致topic.isP2PType()/
topic.p2pPeerDesc()对已建立的会话恒定返回false/undefined——SDK自己内建的"取
对方身份"方法在这个场景下也是坏的，不只是这个项目自己的代码有问题。
只要一个P2P会话有过真实的消息历史（几乎所有现存对话都是这样），它的topicId
就是这个不能反解的p2p...哈希，而不是对方user_id，直接拿去查/v1/im/users/{id}/
profile、匹配好友列表的user_id、传给拉黑/删除好友接口，全部会用错id。
修复：topics.ts新增getP2PPeerUserId(topic, myUserId)——topicId本身是usr...
前缀时直接返回（还没subscribe过，本来就对），否则读topic.subscribers()真实
的订阅者列表，找出不是自己的那个人的真实user_id；订阅者列表还没加载出来时返回
undefined而不是猜一个不可能对的值，调用方原本就有的enabled门控会正确地等待
而不是提前拿错误id发请求。tinode-sdk.d.ts补充subscribers()方法和Subscription
类型声明（原来完全没声明这个方法）。DetailColumn.tsx/ConversationView.tsx改用
这个真实user_id去查资料/匹配好友/头像取色，不再直接假设topicId能用。
实机验证：真实会话grpMc5uN...不对，是p2pp77kUAkgqpVbZoiTpjPWtg（systest04↔
systest02，有真实历史消息的老会话）——修复前详情栏"ID:"整行空白、404貫穿控制
台；修复后详情栏正确显示"ID：usrp77kUAkgqpU"，好友资料/备注/拉黑状态全部正确
关联到真实好友记录。
2026-09-17 12:52:44 +08:00
Your Name
425b06aa71
消息列表和聊天窗口接入真实上传头像，替换字母色块（联系人页此前已接入）
...
用户报告：头像上传后，联系人页面已经能正确显示，但消息列表（会话列表）和
聊天对话框（顶部头像+消息气泡头像+详情栏）仍然只显示字母色块。
根因：联系人页面（ContactsListColumn/FriendProfileView等）走的是REST
/friends、/users/{id}/profile这些接口，响应里天然带avatar_file_id字段，
接的是同一个Avatar组件。但消息列表/聊天窗口这条线读的是Tinode SDK本地维护的
话题缓存（me.contacts()/topic.public），这个对象里根本没有avatar_file_id
这个字段（那是REST专属字段，SDK的public.fn/public.photo走的是完全不同的同步
机制）——所以即使Avatar组件本身没问题，这几个位置也从来没被塞过真实的
avatar_file_id，只能落到字母兜底分支。
修复：在这几处渲染点旁路补一份轻量的id->avatar_file_id映射，全部复用已经在
发的请求（不新增网络开销）：
- ChatListColumn.tsx（会话列表）：群聊复用自己已有的groups查询（本来就为了
显示"N人"徽标在发），单聊新增一个与ContactsListColumn同key的/friends查询
（对方是好友时才有数据，走查询缓存去重）。
- ConversationView.tsx（聊天窗口顶部+消息气泡）：群聊复用自己已有的group
profile查询；P2P peer新增一个与DetailColumn同key的/users/{id}/profile
查询；"我"发的消息复用（不再限定isSelf才拉）已有的/me查询。
- DetailColumn.tsx（P2P详情栏大头像）：本来就在查/friends和/user-profile，
只是从来没把里面的avatar_file_id接到头像上。
- GroupDetailColumn.tsx（群详情栏大头像+成员格子头像，随上一条commit一起
提交）：同样是本来就在查的group/members数据里现成的字段。
Avatar.tsx新增可选的fallbackBgClass prop——"我"发的消息气泡头像，字母兜底
色块设计上固定是强调色而不是按id哈希取色，原来内联写死bg-accent，现在通过
这个prop走统一组件不用另外复制一份渲染逻辑。
已知未覆盖（跟此前记录的已知缺口一致，本次未处理）：群成员选择器/邀请弹层/
群管理弹层等曝光度更低的头像位置仍是字母色块。
重要：本次修复只是把avatar_file_id正确传给了Avatar组件——实机测试时发现
GET /v0/file/s/{id}这个下载接口目前会302重定向到一个跨域地址，
useAuthedBlobUrl用fetch+鉴权头去请求时，浏览器跟着重定向到那个跨域地址后
被CORS拦截（Failed to fetch，redirect:'manual'下确认type是opaqueredirect）。
用三个不同账号/不同file_id复测结果一致，不是个例。也就是说这条修复目前
"接线是对的"，但只要这个后端问题不解决，任何地方（含联系人页、头像上传页
本身）新上传的头像实际都不会真的显示成图片，只会退回字母色块——这是后端
问题，按惯例记录不在这个仓库里修。
2026-09-16 23:37:31 +08:00
Your Name
804618ad63
修复群聊解散通知覆盖不全：主动退出/解散群聊会误报"该群聊已解散"且留下幽灵会话
...
前情：上一版修复只覆盖了"被动看着群被别人解散"这一种场景（后端走自定义
{info what:"group" event:"group.dissolved"}事件而非原生{pres what:"gone"}，
需要单独识别）。这次用户实测发现同一个"话题彻底消失后清理不干净"的问题在另外
两条路径上都复现了：自己点"退出群聊"、自己（群主）点"解散群聊"。
根因：这两个操作各自的mutation.onSuccess只是navigate('/messages')，没有做任何
本地缓存清理；而服务端在REST调用成功后，通常还会异步地给这条已经不再属于你的
订阅补发一个原生/自定义的"gone"信号——这个信号触发的是topics.ts里那条本该只用
于"被动围观"场景的goneListeners通知链，于是ConversationView的通用"该群聊已
解散"提示被复用到了并不贴切的"我自己退出/解散"场景上，且同一个SDK缓存stub没
被清理的老毛病（getTopic()被再次调用就会重建一个空壳）也照样在这两条路径上
重演，表现为消息列表里多出一个显示原始群ID、"1970/1/1"的幽灵会话。
修复：
- topics.ts的markTopicGoneAndNotify新增goneTopicNames去重判断——只要
forgetTopic已经先标记过这个话题，稍后到达的原生/自定义gone信号就直接跳过
（包括不再触发goneListeners），避免重复通知。
- GroupDetailColumn.tsx的leaveMutation/disbandMutation改成onSuccess里先调用
forgetTopic(topicId)（清缓存+加入排除名单+让上面的守卫生效）再navigate，
不再空等异步信号来做清理。
实机验证：systest04建群拉systest02入群 -> systest02主动退出，返回消息列表后
侧栏不再残留幽灵会话；systest04（群主）解散同一个群，同样返回消息列表且侧栏
干净。顺带在GroupDetailColumn.tsx里把群头像/成员格子头像接上了真实上传头像
（见下一条commit的头像修复，这个文件因为改动集中放在了一起）。
2026-09-16 23:36:35 +08:00
Your Name and Claude Sonnet 5
df22f26628
修复刷新/深链进入已解散的群聊时显示错乱，改成直接跳回消息列表
...
用户实机截图报告：一个群被解散后，如果直接刷新页面（或深链）停留在这个群的
URL上，标题栏/侧边栏显示原始topic id（不是群名）、"1970/1/1"的时间戳、
"0人"成员数，而不是跳转离开。
这跟已有的"正在查看时被实时解散"处理（subscribeTopicGone/onDeleteTopic）
不是同一条路径——那个只覆盖"已经订阅成功、活跃看着的时候被解散"，覆盖不了
"这次页面加载压根没订阅成功过"的情况。实机复现确认：openConversation()对
一个已解散群的{sub}请求会正确收到404 CommError拒绝，但ConversationView
原来的catch只弹一个通用的"加载会话失败，请重试"提示，不会跳转，会话视图就
停留在一个半初始化的空壳状态。
修复：新增isTopicGone()识别这个404，命中后跟"实时解散"走一样的用户体验
（toast提示+跳转回/messages）。同时发现并修复了一个连带的清理问题——单纯
调用getTinode().getTopic(name)（openConversation内部一开始就会调，不管
后面订阅成不成功）就已经在SDK本地缓存里留下一个空壳对象，光是这个空壳存在
就足以让侧边栏显示出这条错乱的记录；而清理这个空壳时又跟ConversationView
自己卸载时的closeConversation()清理逻辑（它自己也会重新调用getTopic()）
产生竞态——直接删除后又被重新创建。改成维护一个"确认已消失"的名单，让聊天
列表的过滤逻辑直接按名字永久排除，不再依赖谁先执行、谁后执行。
实机验证：真实解散一个群后，直接deep-link/刷新回这个群的URL——确认页面
立即跳转回/messages，且侧边栏不再出现这条已解散群的残留记录。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 22:49:17 +08:00
Your Name and Claude Sonnet 5
c53e6552eb
补全群邀请功能的接收方一侧：系统消息里的群邀请通知现在能真正接受
...
追查"邀请功能不完善"时发现的更大缺口：群邀请在需要审批的情况下（群自身的
进群验证，或被邀请人自己的隐私设置要求验证）不会立即拉人入群，而是创建一条
真正的邀请记录，通过系统消息投递给对方（event_type: group.invitation.created，
action.type: group_invitation_accept，带invitation_id）——但这条系统消息
此前完全没有专门处理，走的是所有group.*事件通用的"查看群聊"跳转逻辑，直接
导航到一个对方根本还不是成员的会话，大概率打不开。
协议文档把POST /v1/im/group-invitations/{id}/accept标成"待实现"，和今天
早些时候发现的草稿持久化接口是同一种文档滞后于后端实际进度的情况——读了
im_be的serveIMGroupInvitationResource源码确认这个接口真实可用。
actionRoute()现在对这个特定事件类型不再返回通用的导航链接，卡片里改成渲染
一个真正的"接受邀请"按钮（阻止事件冒泡，避免和卡片自身的整体点击-标记已读
逻辑冲突），点击后调用accept接口，成功直接跳转到这个群（这时候已经是成员
了），失败在卡片上原地显示失败原因。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 22:26:29 +08:00
Your Name and Claude Sonnet 5
66dad284c7
修复邀请入群交互：点击邀请要直接进入邀请，而不是先看成员列表再点第二次
...
用户实测反馈的真实bug：GroupDetailColumn里那个专门的"+邀请"图标（虚线边框
方块，只有canInvite为真才显示——这个权限门控本身一直是对的）点击后走的是
setOpenModal('members')，和"查看全部成员"是完全同一个入口——弹出的是成员
列表，标题栏里那个真正的"邀请"按钮还要再点一次才能看到可邀请的联系人列表。
GroupMembersModal新增initialView属性，"invite"直接以邀请视图打开（跳过
成员列表这一步），"查看全部"/"查看全部成员"两处不受影响仍然打开成员列表。
同时补全了邀请结果的反馈——原来邀请成功后只做了查询失效，无论是"立即加入"
还是需要对方/群设置审批的"待确认"，界面上都没有任何区别于点击前的视觉反馈，
容易让人怀疑是不是点了没反应从而重复点击。读了im_be的serveIMGroupInvitations
源码（不是协议文档的单一示例）确认真实的单人邀请结果有joined/already_member/
pending/pending_approval/failed五种可能，现在每种都有对应的行内文案，
"failed"不计入"已处理"状态，允许原地重试。
实机验证：全新建群后点"+邀请"直接进入邀请视图（标题"邀请成员"，不经过成员
列表）；邀请一个全新好友后确认成功加入、群成员数正确从2变3、界面正确显示
结果反馈。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 22:26:12 +08:00
Your Name and Claude Sonnet 5
3fab8b08b9
被拉入新群时标题栏/桌面通知没有任何提示——扩展兜底同步机制覆盖这个场景
...
reconcileMeSubs()本来就能发现"此前完全不认识的话题"（今天早些时候为解决群聊
被动成员看不到新群加的兜底机制），但发现后只是原样信任服务端返回的read/unread
字段——服务端对一个刚加入的新成员，默认给的读游标经常是"视为已读"（read==seq），
如果这个群目前恰好一条消息都没有，unread就会是0，导致今天新加的标题栏滚动/
favicon角标（由同一个未读数驱动）完全没有反应，被拉群这件事本身悄无声息。
改成：对每一个新发现的话题，不管服务端给的read游标是什么，一律按"我自己完全
没确认过"处理（read清零，unread按当前seq计算）；如果是群，额外通过
subscribeNewGroupDiscovered（新增的发布-订阅，push.ts订阅它去弹真正的桌面
通知"你被拉入了这个群聊"，因为topics.ts不能反向依赖push.ts）触发一条独立的
桌面通知，不依赖未读数是否恰好大于0。
实机验证：systest04建一个只邀请systest05的全新群，systest05这边模拟切回
标签页触发兜底同步后，确认收到桌面通知（title/body/tag均正确）且标题栏
未读数正确增加。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 22:25:55 +08:00
Your Name and Claude Sonnet 5
f570483b62
切换到会话时输入框自动聚焦
...
匹配主流IM客户端的习惯——切进一个聊天窗口应该能直接开始打字，不需要先手动
点一下输入框。只在topicId变化时聚焦一次，不依赖messages（否则每来一条新
消息就会把正在做其他操作的用户的焦点抢走）。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 22:25:38 +08:00
Your Name and Claude Sonnet 5
3df61e9e59
接入服务端消息草稿持久化，修复切换会话/刷新页面丢失未发送草稿（禅道#19）
...
协议文档docs/IM-前后端对接文档.md:1003/1247把`PUT /v1/im/topics/{topic}/draft`
标注成"待实现"、把本地保存写成默认方案——但读im_be自己的源码（server/im_http.go
的serveIMTopicDraft，接的是store.Conversations.GetDraft/PutDraft）确认这个
接口其实真实可用，文档只是没跟上后端进度。之前草稿只有draftByTopic这一份纯
内存状态，没有任何持久化，刷新页面或者（取决于路由是否把ConversationView
整个卸载）切换会话都可能把草稿丢光。
实现：打开一个会话时（每个topic每个会话只拉一次）用GET拉取服务端草稿，如果
本地这个session里还没有内容才用它填充（本地正在打的字优先，不会被服务端的
旧快照打断）；输入停止1.5秒后用PUT保存（带乐观锁version），不是按键就存；
切换到别的会话或整个离开消息页面时立即flush掉还没来得及等到防抖的最新内容，
不会因为切太快而丢最后几个字。加了"最后一次确认同步的内容"记录，避免"打开
会话→加载已有草稿→内容变化触发保存"这个误判成"用户编辑了"从而立刻把同一份
内容又存一遍的多余请求。
实机验证（systest04账号，因为systest01/systest02当时正被用户在真实浏览器里
测试）：
- 刷新页面：输入框正确恢复之前的草稿内容
- 切到另一个具体会话再切回：正确恢复（走的是服务端往返，不是本地状态留存，
切换瞬间有个最多一两秒的短暂加载间隙，之后正确填充）
- 输入后不到1.5秒就切走：flush机制确认立即保存，没有丢内容
- 加载已有草稿本身不会触发多余的重复保存（验证了修复前这个问题真实存在——
版本号无缘无故多跳了一次）
- 发送消息后：本地和服务端的草稿都正确清空
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 21:55:55 +08:00
Your Name and Claude Sonnet 5
4bf4e75cac
修复会话开着但标签页在后台时消息被SDK自动标记已读、未读提示永远不触发的问题
...
用户实测报告：systest01打开着与systest02的会话，切到别的标签页后，systest02
发消息过来，systest01这边的标签页标题完全没反应。追查后发现根因比表面看到的
更深——这不是标题栏本身的bug，是更底层的已读状态被静默污染了。
读tinode-sdk源码确认：TopicMe自己的_routePres在处理服务端推给"me"话题的
`{pres what:"msg"}`通知时（这本来是让未在查看的会话也能收到未读更新的机制），
调用`cont._updateReceived(pres.seq, pres.act)`，只要`act`是假值或者等于自己，
就会无条件把`read`设成`seq`——也就是直接标记成已读。而一个只是保持"打开"状态
的会话（ConversationView挂载着、话题处于订阅状态），哪怕标签页在后台完全没人
看，一样会收到这条推送，被自动标记已读——跟标签页是否可见毫无关系。之前只
在ConversationView自己的显式noteRead()调用上做了可见性判断，根本拦不住这条
更底层、完全独立的SDK自身机制。
修复：在topics.ts里新增一套独立于SDK自身read/unread字段的"真正已读"记录
（markConfirmedRead/confirmedReadSeq），只在会话真正被看到时（打开且标签页
可见）才推进；me.onPres处理`{pres what:"msg"}`时，如果受影响的会话不是当前
正在被查看的那个，就用这份独立记录把SDK刚自动标记的已读状态纠正回去。
openConversation()打开会话时会拿当前seq给这份记录打个初始基准，但同样加了
可见性判断——直接刷新/深链到一个标签页本身就在后台的会话这种边界情况下，
不能假设"打开=看过"。activeConversationTopic的追踪从push.ts挪到了topics.ts
（两边都要用，且topics.ts不能反向依赖push.ts）。
实机验证（systest04/systest05全新账号对，因为systest01/systest02当时正被
用户自己在真实浏览器里同时测试，避免互相顶号干扰）：会话保持打开、标签页
确认处于hidden状态时，对方发消息——未读数正确从0变成1，标题栏数字正确跟着
增加；随后模拟标签页重新变为可见——未读数正确清零、标题恢复正常，走完了
用户报告的完整场景闭环。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 20:57:55 +08:00
Your Name and Claude Sonnet 5
3d6ae089a1
修复今天新增的兜底同步会让已读会话的未读角标无故重新出现的回归
...
根因：tinode-sdk自己的合并工具mergeObj（utils.js）对Date类型字段有"保留更新
的值"的防护，但普通数字字段（seq/read/recv/unread）完全没有防护，谁的数据
后到就直接覆盖——读源码逐行确认。startMeReconciliation()新增的定时/切换焦点
触发的withLaterSub()增量拉取一旦命中"服务端返回的read游标还没跟上客户端刚
发出的已读回执"这种时序，就会把已经读过的会话悄悄改回未读：角标无缘无故重新
出现，且重新聚焦窗口也不会清除，因为对这个会话来说根本没有发生任何新事情去
重新触发标记已读。
修复：reconcileMeSubs()改成在发起这次增量拉取前，先给所有已知会话的
seq/read/recv/unread拍个快照；拉取完成后，对每个"拉取前就已经认识"的会话，
如果发现seq没变但unread反而变多了，直接把read/recv/unread改回快照里的值并
触发通知——只有真正全新的会话（拉取前不认识）才信任这次拉取回来的数据，这
本来就是这个兜底机制存在的唯一目的。
实机验证：monkey-patch me.getMeta，让它在真实网络请求返回后额外注入一条
过期的sub记录（模拟服务端读游标滞后），再用真实的focus事件触发
reconcileMeSubs()整条链路——确认最终状态仍然正确显示已读，而不是被污染。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 20:32:49 +08:00
Your Name and Claude Sonnet 5
cd6b7675d4
新消息提示：标签页标题滚动+未读数、favicon角标、桌面通知（含何时不弹的判断）
...
三件套，参照Slack/Telegram Web/WhatsApp Web等主流IM网页客户端的标准做法：
- lib/notifications/tabIndicator.ts：标签页被切到后台且有未读时，标题在
"📨 (N条新消息) <原标题>"上做左向滚动，用户切回来的瞬间（visibilitychange）
立即恢复原标题，不等下一次未读数变化才发现。favicon右上角画一个红色圆点+
白色数字角标（canvas绘制成PNG data URL，写回现有<link rel="icon">，不是
另加一个可能被浏览器忽略的竞争链接）。两者都由AppShell.tsx里已经算好的
同一个unreadMessages号驱动，不另起一套可能对不上的计数。
- lib/notifications/push.ts：真正的浏览器桌面通知（Notification API）。只
在标签页还开着（哪怕最小化/切到后台）时生效——做不到浏览器整个关掉也能收到，
那需要Service Worker+推送订阅+后端配合，是完全另一个量级的工程。
抑制规则（"什么时候不弹"）：
· 消息来自自己（比如另一个标签页/设备同步过来的回显）
· 正在看的就是这个会话本身（会话已打开且标签页确实可见——两者都要满足，
一个被切到后台的标签页哪怕挂载着这个会话也不算"正在看"）
· 该会话设置了"消息免打扰"（contact.private.mute_notifications）
· 浏览器未授予通知权限
同一会话的连续通知用tag合并显示为一条，不会叠加刷屏；点击通知会聚焦标签页
并跳转到对应会话（通过stores/notificationNav.ts中转，push.ts在React之外，
没有useNavigate可用，做法与stores/calls.ts、messageJump.ts是同一个模式）。
判断"是否是真的新消息"用的是防抖后的seq对比（防止刚打开一个从未见过的会话时，
历史消息分批到达被逐条误判成"新消息"）——第一次见到某个会话时记录基准而不是
照单全收。**这里踩到一个真实bug并当场修复**：最初版本把"第一次见到这个会话"
一律当成"历史消息，不通知"，结果全新好友的第一条消息（对这个会话来说seq=1，
同时也是"第一次见到"）被误判成历史消息静默吞掉——用两个全新互加好友的测试
账号实机复现后，改成额外看消息时间戳：一分钟以内的算真正新消息，无论是不是
第一次见到这个会话，否则才当历史记录处理。
实机验证（systest01/systest02两个全新互加好友的测试账号，全部通过mock
Notification类捕获+SDK本地状态直接读取的方式验证，因为这个自动化浏览器环境
本身把Notification.permission锁死成denied，没法测试真正弹出的系统通知）：
- 真实新消息：通知的title/body/tag均正确（对方昵称/消息预览文本/会话id）
- 免打扰会话：确认不弹
- 已打开且标签页可见：确认不弹
- 标题栏滚动+favicon角标：实机确认能正确开始/停止滚动、favicon生成的是
真实可解码的64×64 PNG
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 20:14:12 +08:00
Your Name and Claude Sonnet 5
8a593f50c3
系统消息：无跳转链接的通知永远停留在"新"，改为整张卡片可点击标记已读
...
readMutation.mutate()此前只挂在"查看XXX"跳转按钮的onClick上，而这个按钮只在
actionRoute()能解析出目标时才渲染——好友申请已通过/拒绝、多数群聊动态类通知
根本没有可跳转目标，导致整张卡片没有任何东西可点，无论过多久都停留在"新"。
改为整张卡片本身是点击目标：有action的card点击后标记已读+跳转，没有action的
只标记已读。原来的"查看…"跳转按钮改成纯文本span（它现在处于卡片自己的点击
区域内，再嵌一层可交互元素会构成非法的按钮嵌套/双重触发，与之前修过的收藏夹
语音播放器按钮嵌套是同一类问题）。
实机验证：一条"好友申请已处理"（无action）点击后"新"角标消失；一条"新的好友
申请"（有action）点击后正确标记已读且跳转到/contacts/requests，无回归。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 20:13:41 +08:00
Your Name and Claude Sonnet 5
ab3843dbdb
群聊生命周期事件对被动成员实时不可见——前端兜底同步（真正的根因在后端，无法单靠前端代码彻底解决）
...
读im_be的server/im_group_events.go确认：群聊创建/加人/踢人/解散/转让群主等全部事件都走
publishIMGroupRealtimeEvent，这个函数只会广播给"当前已订阅该群topic的会话"——对比P2P场景专门
有一条deliverIMConversationSystemMessageToP2PSessions，会无视订阅状态强制投递给双方的session，
群聊从未做过同等实现。实机验证：一个全新创建、成员从未打开过的群，即使对方账号完全在线、页面就
停留在/messages上，群条目和未读角标都不会出现，等多久都不会自愈，必须手动刷新页面。
由于这个topic客户端本来就不知道存在，没有任何东西可以"响应"，前端无法真正修复，只能缓解：复用
subscribeMeTopic()/onReauthenticated()已经在用的withLaterSub()增量语义，改用getMeta()（不像
subscribe()那样在_attached为true时直接短路）定时（30秒）+ 切回标签页时主动拉一次"me"话题的最新
订阅列表。
实机验证：创建一个全新群、只邀请一个从未见过这个群的被动成员，在其页面保持被动、不做任何操作/
刷新的情况下——模拟切换标签页触发的focus/visibilitychange事件后约十几秒内，群条目正确出现在
列表顶部；另一次未受干预的测试中，纯靠30秒定时器本身也确认能自愈。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 18:55:04 +08:00
Your Name and Claude Sonnet 5
d1f3aea26e
群聊消息记录中点击发送者头像/名字可跳转查看详情
...
isGroup且非本人消息、非多选态时，头像与名字改为Link跳转到/contacts/{msg.from}，
其余情况（含选中模式，避免中断正在进行的批量选择）保持原有纯展示span不变。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 18:03:25 +08:00
Your Name and Claude Sonnet 5
8431f83ede
修复从好友资料页"发消息"直接进入新P2P会话时名称/在线状态永久缺失的问题
...
根因比此前提交(ff69e454noreply@anthropic.com >
2026-09-16 18:03:18 +08:00
Your Name
c455644cca
NavRail左上角头像补充点击跳转个人资料页
...
此前是纯展示的Avatar，没有包任何可点击元素。包一层Link指向
/settings/profile，和设置页里"个人资料"入口是同一个目的地。
2026-09-16 16:58:21 +08:00
Your Name
823a47e182
修复群公告发布通知消息正文完全不显示、聊天列表预览显示"undefined"
...
群公告发布后自动生成的通知消息，真实content是{text:"群公告\n<内容>"}这种
扁平对象（不是纯字符串，也不是标准Drafty的{txt,fmt,ent}结构），且
head['x-im-type']是"text"而不是已处理的"system_notice"，落到Drafty处理
分支后既渲染不出气泡正文、列表预览也变成字面的"undefined"字符串。
抽出dispatch.ts里原本只服务system_notice的{text}扁平内容识别逻辑
（重命名为flatTextContentOf并导出），在renderDrafty和
formatMessagePreview的Drafty分支之前都接上——不改变已有的居中系统提示
样式（这条消息本来就该是普通气泡，发送者信息一直是正确的，只是正文
丢了），只是把"文本内容是扁平{text}对象"这一种情况也当作合法纯文本处理。
实测：真实发布一条群公告后，气泡正文和列表预览都正确显示"群公告
全功能测试公告内容"，不再是空白或"undefined"。
2026-09-16 16:37:48 +08:00
Your Name
92892e3e7b
修复两个严重崩溃：群管理页面查询键冲突导致整个会话崩溃、禁言列表读取
...
不存在的嵌套字段崩溃
- ConversationView.tsx和GroupAdminModal.tsx对群禁言列表用了完全相同的
React Query缓存键['group-mutes', topicId]，但分别调用getGroupMutes
（单页,{items:[]}包装对象）和getAllGroupMutes（全部页,展开后的纯数组）
两个返回形状不同的函数。两个组件同时挂载时后写入的一方会覆盖缓存，
另一方读到错误形状后对undefined取.length直接崩溃，导致只要打开某个
群的"群管理"面板整个会话界面就白屏。改成两处统一用getAllGroupMutes，
真正共享同一份、同一种形状的数据
- GroupMute类型声明的是嵌套的user:{user_id,display_name}，但真实响应
是扁平的{user_id,muted_by,muted_at,reason,status,version}，且完全没有
display_name字段。这个字段错配从来没被暴露过，因为此前从未有真实账号
真正禁言过人后去看这个列表——本轮实测"禁言→查看列表"时才第一次真正
用真实数据渲染，立刻崩溃。改成扁平字段+交叉查群成员列表解析真实姓名
（同一模式ConversationView.tsx的memberByUserId、GroupFilesModal的
uploader_id都已经在用）
用全新账号在全新群里完整实测：禁言成员1人正确显示头像+姓名"systester2"
（不再是原始uid或崩溃），解除禁言后列表正确清零，两处此前必崩的入口
（群管理面板本身、禁言列表渲染）全部验证通过。
2026-09-16 16:23:06 +08:00
Your Name
8013c1675f
修复禅道Bug清单中的前端问题：好友申请source校验、群解散二次验证缺失、
...
群解散事件未处理、错误码翻译缺失、恢复登录页误导性提示
- 好友申请首次必失败30000（P0）：AddFriendModal把手机号搜索单独标记为
source:"phone"上报，但后端serveIMFriendRequestCreate的source校验只认
search/qr/group，命中default分支返回"invalid friend request source"。
改为手机号搜索也统一上报source:"search"（后端本就不区分具体搜索渠道），
用两个全新、此前无任何关系的测试账号验证首次申请200成功
- 解散群聊需要短信二次验证但完整流程从未实现（P0）：新增
SecurityChallengeModal通用二次验证弹层（POST /security/challenges→
验证码→verify→action_token）+ requestActionToken()（stores/
securityChallenge.ts，与requestConfirm同一模式），接入解散群聊和转让
群主（后者此前也因缺X-Action-Token必然404/400）。同时发现并修复
imDelete对无body请求不显式传空对象体，导致携带Content-Type:
application/json但请求体真正为空时后端JSON解码失败返回400——实测确认
两个问题都解决后DELETE返回200
- 群聊被解散但当前正查看该群的用户界面不会跳转（P1）：新增
topics.ts的subscribeTopicGone()监听SDK自身的onDeleteTopic回调，
ConversationView据此在当前会话被解散时弹出提示并跳转回消息列表
- P2P会话发起方标题栏显示原始topic id、对方明明在线却显示离线：确认
为上一轮已修复的isCommType()根因问题的同一症状，本轮实测（新建从未
聊过天的账号对）已不再复现；群内消息发送者显示原始uid的关联描述同样
实测未复现
- 好友关系冲突（已是好友/申请正在处理中）报错英文原文透出：翻译表补充
FRIEND_REQUEST_CONFLICT
- 深链/刷新页面时的"改为重新登录"链接此前在任何恢复登录过程中都会
立即显示（不管是否超时），造成短暂白屏时的误导性提示：改为仅在真正
超时后才显示该链接，与其上方的提示文案保持一致的显示条件
2026-09-16 15:42:41 +08:00
Your Name
ff69e4548c
修复P2P会话完全不出现在聊天列表、标题栏显示原始ID+离线的根因
...
根因：tinode-sdk自带的Topic.topicType()前缀表只认'usr'为P2P类型前缀，没有
'p2p'这个条目，而本后端真实分配的P2P话题名是`p2p<hash>`形式——导致
isCommType()对每一个P2P会话都恒定返回false，MeTopic.contacts()因此把所有
单聊会话过滤掉。用真实账号实测确认这不是新会话/顶号账号特有的问题：任何
账号的任何P2P好友关系都受影响，只是群聊和"slf"自聊天不受影响所以此前一直
没被发现。
聊天列表改用Tinode#mapTopics()（不做类型过滤的原始遍历）+ 本项目自己正确
的前缀判断（p2p/grp/slf），不再依赖SDK自身的isCommType()。
实测（e2etester1/e2etester2真实新建好友关系，此前从未聊过天）：修复前
标题栏显示原始topic hash+"离线"（对方实际在线）、侧边栏"暂无会话"（消息
其实已正确送达，只是不可见）；修复后标题栏正确显示对方昵称+"在线"，侧边栏
正确出现该会话及消息预览。
2026-09-16 13:41:26 +08:00
Your Name
29a1f1c2fd
修复收藏/系统消息/通话记录批次的代码审查问题
...
- 通话结果"已拒绝"文案按视角区分(拒绝方看到"已拒绝"而非"对方已拒绝")
- 通话记录页补充移动端返回头部与加载失败重试态
- 挂断时按是否已接通传递正确的挂断原因(cancelled)
- 系统消息"全部标为已读"翻页加循环护栏,防止游标卡死;按钮可见性改用真实未读总数
- 收藏批量删除/转发在部分失败时保留失败项以便重试,而非无条件退出多选模式
- 收藏卡片边框/分类文字/侧栏图标颜色token修正
2026-09-16 12:54:40 +08:00
Your Name and Claude Sonnet 5
97e8d7144f
fix(web): 第9轮审查批次4——设置域一批问题
...
- 头像上传从未带purpose=user_avatar：之前是照抄一个已经修复的旧后端
bug(问题28)绕开的写法，现在确认接口早就支持这个purpose了，补上——
uploadFile()新增可选purpose参数，不影响其它已有调用点(聊天附件/群
文件继续用topic的chat_file路径)
- 桌面卡片行分隔线6处错用了移动端专属的border-list-item token，改成
桌面正确的border-row
- 退出登录按钮外边距/设置目录导航图标尺寸(18px→20px)与设计稿对齐
- 地区字段补上maxLength兜底
- 修改密码没有用<form>包裹，输入框按回车没反应——补上表单+onSubmit
- 记录一条此前没进清单的后端缺口："加我为好友时需要验证"这个隐私开关
设计稿画了，但响应体里根本没有对应字段
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 12:46:48 +08:00
Your Name and Claude Sonnet 5
18d21a03bb
fix(web): 第9轮审查批次3——通讯录域一批问题
...
- 手机号搜索加好友时来源永远上报"search"（账号搜索），NewFriendsView
早就有phone的文案映射但一直用不到——现在按searchType正确区分
- 添加好友弹层三个快捷按钮布局改成横向（原来是纵向堆叠，和设计稿方向
不一致），图标颜色改成强调色
- "已选择"状态标签的圆角从胶囊改成6px小圆角，和同弹层其它按钮风格一致
- 通讯录头部"加好友"按钮补上移动端尺寸（40px/桌面36px），之前和旁边
FIXED_ENTRIES的断点处理不一致
- 我的二维码/名片二维码生成失败没有重试入口，只能关掉弹层重开——补上
重试按钮，同时处理"铸造失败"和"canvas绘制失败"两种情况
- 通讯录域几乎所有列表（好友列表/新朋友/群聊列表/黑名单/好友主页/加
好友搜索）都把请求失败误判成"没有数据"，统一补上isError态+重试按
钮；好友主页额外区分403(资料保护)/404(真的不存在)/其它错误三种情况，
之前网络错误也会显示"未找到该用户"
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 12:41:20 +08:00
Your Name and Claude Sonnet 5
8f4b0de636
fix(web): 第9轮审查批次2——群聊域一批问题
...
- 建群留空群名字直接被后端拒绝：placeholder写的"未填写时默认为成员
昵称组合"从未真正实现，现在留空时用已选成员昵称拼接生成默认名，
按MAX_TITLE_LENGTH截断
- 群文件上传按钮不受"群文件上传权限"治理开关约束：新增canUpload
（和canInvite同一个算法），仅管理员时非管理员看不到上传入口
- 群管理弹层5个治理开关（进群验证/全员禁言/文件上传/私聊权限/邀请
权限）都没有读取后端返回的对应_editable字段，现在全部接上
- 禁言成员列表只拉第一页：新增getAllGroupMutes复用fetchAllPages，
和getAllGroupMembers同一个模式，人数多的群不会再静默截断
- 添加管理员没有前端数量上限校验：达到上限时按钮禁用并提示"已达
管理员人数上限"，不再让用户选完人才被后端拒绝
- 清空聊天记录没有错误处理，失败时静默无提示，现在补上
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 12:37:46 +08:00
Your Name and Claude Sonnet 5
ab96ae1fee
fix(web): 第9轮审查批次1——认证/图标CSS/顶号竞态/消息核心一批问题
...
认证域：
- 找回密码验证码请求存在竞态：请求发出后如果用户改了手机号，旧请求
返回时仍会用旧手机号的challenge�covers新手机号的输入框，现在按
发起请求时的手机号快照判断，作废过期响应
- 切换企业码时"退出登录"确认框可被绕过：判断依据只有内存里的
myUserId，直接刷新在/tenant页会让这个值变回null，导致确认框不弹
就静默销毁一个其实还有效的会话；现在同时检查sessionStorage里的
token
- 企业码不存在错误文案缺后半句"，请核实后重试"，和其它两处文案对齐
- 营业执照上传补上前端体积/类型校验（仿照问题反馈页截图校验的写法），
不再无条件发一次注定被拒的上传请求
- 找回密码页移动端"重置密码"标题重复渲染两次，桌面版标题补上
min-[900px]:block hidden
- 企业码输入框补maxLength=64
图标CSS：Material Icons的.im-icon规则漏抄了Google原始样式表的两行
（-webkit-font-feature-settings/-webkit-font-smoothing），补齐让
"1:1 copy"真正成立
顶号踢人 vs 已有401登出的竞态：两条路径会同时清空同一个token，如果
401先触发，用户会被直接甩回登录页看不到"账号已在其他设备登录"的
提示——forceReauth()现在先等一小段时间看kickedInfo是否被顶号流程
设置，设置了就让顶号流程自己的按钮触发跳转，避免抢跑
通话信令健壮性：sendCallRinging/Accept/Hangup底层用的{note}包没有id
字段，连接断开时会同步抛异常而不是走Promise reject——之前hangUp()
在这类异常后直接中断，导致后续的leaveCall()清理和UI收尾全部被跳过。
统一加了try/catch兜底
消息核心：
- 名片消息/通话结果消息（非Drafty的扁平自定义对象）之前可以被引用/
复制/转发，会把这些对象错误地喂给Drafty的解析函数，产生格式错误
的内容——现在这两类消息只保留收藏/撤回/删除/多选
- MessagesLayout.tsx自己独立计算的peerName没有对slf（自聊天）做
isSelf特殊处理，会显示裸topic id"slf"而不是昵称，和已经修过的
ConversationView头部不一致，现在补齐同样的处理
- 发送失败图标/文案错用了danger-text（撤回删除等破坏性操作的语义
token），改成语义正确的unread token；录音条文字被连带染红，只保留
指示点是红色
- 群成员数徽标形状(应为4px圆角矩形不是胶囊)和颜色(应为text-tertiary-4
不是text-tertiary-3)都和设计稿不符，已修正
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 12:33:23 +08:00
Your Name and Claude Sonnet 5
fb1fda689c
fix(web): 图标尺寸覆盖(text-[Npx])在任何地方都不生效——CSS层级冲突
...
根因：Material Icons的Google Fonts样式表(index.html的<link>)自己的
.material-icons规则完全没有@layer包裹（纯普通CSS），而Tailwind v4的
每一个工具类都在@layer utilities里——CSS Cascade Layers规范规定，任
何未分层的声明，不管选择器优先级多高、样式表加载顺序多晚，永远优先于
任何分层声明。实测坐实：<Icon className="text-[14px]">的计算样式恒
定是font-size:24px，不管试图覆盖成几px都没用，因为Google那条未分层
规则永远赢。这不是某一处的问题，是Icon组件全局的、此前从未被发现的
系统性bug——历史上多轮视觉审查用截图核对布局，没人具体去量过某个
图标的computed font-size。
修复：Icon.tsx改用自己的im-icon类名，不再用material-icons这个
Google样式表实际瞄准的类名，这样那条未分层规则从一开始就不会匹配到
这些元素。index.css里用@layer base原样照抄了Material Icons自己那条
规则的视觉默认值(24px/line-height:1等)，套上分层之后，Tailwind自己
的@layer utilities（在Tailwind的层注册顺序里排在base之后）就能正常
覆盖它了——和每一处写`text-[Npx]`时本来就该有的效果一致。
全局仓库搜索确认material-icons这个类名只有Icon.tsx一处引用，改动范围
可控、不涉及其它代码路径。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 11:51:16 +08:00
Your Name and Claude Sonnet 5
776131b1de
fix(web): 全新好友关系不会立即出现在会话列表/正确显示在线状态
...
上一条commit修的是"消息本身发不出去"，这条修的是同一个根因链条上更早
一环：SDK只对`me`话题的onMetaSub/onSubsUpdated两个回调做了这个"联系
人变化了"的通知（读tinode.dev.js确认：无论是哪个话题触发的订阅，SDK
永远只调用me.onMetaSub/me.onSubsUpdated，不是触发订阅的那个话题自己
的回调），但这个项目的wireTopicCallbacks只接了onSubsUpdated，漏了
onMetaSub——这正是brand-new P2P话题从usr别名被服务端改名成真实
p2p...哈希的那一刻，SDK唯一会触发的两个回调之一。
现在两个回调都接上、都指向同一个notify()，会话列表和ConversationView
自己的contact查找（决定头部显示真实昵称还是裸id、在线还是离线）应该
能在好友关系刚建立、还没有任何一方发过消息时就正确更新，不用等一次不
相关的全量重连才被动捡回正确状态。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 11:47:50 +08:00
Your Name and Claude Sonnet 5
0824502ddd
fix(web): 全新单聊(usr别名)会话消息收不到/在线状态错误——URL没跟上SDK重命名
...
真实两账号复现：好友刚加上、双方都还没发过消息的单聊，发消息表现为"发了
和没发一样"（无失败提示，但对方收不到），会话头部同时显示错误的裸ID和
"离线"（即使对方明明在线）。
根因（读tinode-sdk真实源码+原生协议脚本交叉验证，非猜测）：这类会话从
"对方user_id"（usr...）这个地址进入，服务端订阅成功后会返回一个不同的
真实内部话题名（p2p...哈希）。SDK的Topic#subscribe在topic对象处于
`_new`状态时（每个新建对象默认如此）会把本地缓存从usr...改名到这个真
实名字——但本组件的submit()/头部展示/MessageBubble的retry()全都各自
独立调用`tinode.getTopic(topicId)`，用的是URL里那个没变过的usr...字符
串。改名发生后再调用`getTopic('usr...')`是一次缓存未命中，会凭空造出
一个全新的、从未真正订阅过的"替身"对象——发送/已读/在线状态全部作用在
这个空对象上，而真正收到数据的是已经改名的那个对象，两者从此互不相干。
用一个独立的原生WS协议脚本验证了根因：直接订阅+发布到同一个usr别名，
服务端确认消息真的送达并持久化（用一次全新订阅的历史记录能拉到），证
明"消息发不出去"是假象，真正的问题在于客户端读的从来不是收到数据的那
个对象。
修复：openConversation()解析出的topic对象一旦.name和URL参数不一致
（即刚刚被服务端改名），立刻用real name替换当前URL（replace，不留历
史记录）。这样一来，本组件后续所有`getTopic(topicId)`都会读到同一个、
真正接了收数据的对象，而不是每次都对着URL里那个过期字符串重新变出一
个空壳。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 11:43:56 +08:00
Your Name and Claude Sonnet 5
9adadaa57d
feat(web): 实现强制下线通知与顶号互踢的客户端感知（Ctrl 205 evicted）
...
按docs/强制下线通知与顶号互踢-后端接口文档.md §2实现。该文档§2.4声称
"SDK侧已内置：收到后关闭autoreconnect并回调onKick(reason, ctrl)"——读
实际安装的tinode-sdk(0.25.3)真实源码确认这个说法不成立：SDK对
code:205/text:"evicted"只有topic级的内部处理(topic._resetSub())，账
号级(topic为空)完全没有特殊逻辑，也没有onKick这个回调。
改为用SDK真实存在、此前项目里完全没用过的onCtrlMessage钩子（每条
{ctrl}包都会触发，含账号级的）在connection.ts里自行判定
"code===205 && text==='evicted' && !topic"。检测到后立即：清空
sessionStorage的token、清空myUserId、调用resetTinode()——其内部的
disconnect()会把SDK自己的#boffClosed标记置真，这是唯一能真正阻止
backoff计时器安排下一次重连的方式（读真实bundle的Connection#init_ws
确认，不存在另外一个"关闭autoreconnect"的方法）。只有面向用户的弹窗
和跳转延后到用户点确定，逻辑上是"会话立刻终止，通知是补充说明"，不
是"通知完才终止"。
新增KickedNoticeRoot（挂载在App.tsx顶层，和ConfirmDialogRoot/
GlobalToastRoot同一层级，保证任意页面被踢都能弹出），文案原样照抄文
档§2.4的表格（reason→标题/正文），单一"确定"按钮（不是取消/确定二
选一——已经被踢了，没有"取消"这个选项，给出会误导）。确认后用
window.location.href硬跳转/login，和client.ts的forceReauth()同一个
理由：保证内存里的每一处状态(TanStack Query缓存等)都从头重置，不用
指望每个组件各自正确响应"你已经被登出了"。
topic非空的205（群内移出等topic级事件）不受影响，走原有的SDK内部
处理，不弹这个全局提示。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 11:13:28 +08:00
Your Name and Claude Sonnet 5
c3e8f91364
fix(web): 修复自聊天显示为原始topic id、主发送/重试路径未重新订阅话题
...
自聊天(slf)会话头部/侧边栏/聊天列表此前直接回退显示原始topic id "slf"
(而不是自己的昵称)，且会话头部还错误显示了通话/视频按钮和"离线"状态——
这三者都源自同一处：peerName的计算只查好友列表(不含自己)，没有对slf
做特殊处理。DetailColumn此前已经用isSelf正确处理了详情栏内部的各项操
作(commit 9271a0a9noreply@anthropic.com >
2026-09-16 10:44:19 +08:00
Your Name and Claude Sonnet 5
e78437cb2a
fix(web): upgrade http OSS URLs to https to fix mixed-content block
...
Aliyun OSS sometimes returns presigned URLs as http:// even though every
page here is served over https:// -- the browser silently blocks these
as mixed content, which is why images (e.g. avatar) failed to display
after upload. Added upgradeToHttps() and wired it into fileDownloadUrl()
(the single chokepoint every image/attachment fetch in the app resolves
through) plus the three chat-attachment send paths, so both freshly
fetched and newly-persisted URLs get the scheme fix.
Also fixed ProfileSettingsPage's avatar upload handler, which extracted
the file id by parsing the upload response's `url` with .split('/').pop()
instead of just reading the `file_id` field the response already
provides -- fragile against exactly this kind of full-URL response and
the most likely actual trigger for the reported bug.
vite.config.ts: dev server port now respects $PORT if set, falls back
to 8094 -- unrelated cleanup, needed it to run a second local dev
server for verification alongside another concurrent session's.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-16 00:18:31 +08:00
Your Name and Claude Sonnet 5
70cc977e16
fix(web): 左上角自己头像接入真实数据，会话订阅失败不再静默吞错
...
NavRail 的自己头像此前是硬编码的"我"字，AppShell 从没往下传过真实的
user_id/nickname/avatar_file_id，所以无论是谁登录、有没有上传头像都不会变；
现在改为拉取 /v1/im/me 并用 Avatar 组件渲染，和设置页/联系人等处一致。
ConversationView 打开会话失败时原来是 .catch(() => {}) 整个吞掉，用户会看到
空白的消息列表且没有任何提示；由于已读回执只在拿到消息后才会发，未读角标
也会因此永久卡住。现在失败会弹出错误提示，不再静默。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-15 23:28:53 +08:00
Your Name and Claude Sonnet 5
d5fc03db0e
ci: retarget deploy workflow at the k3s test cluster
...
Old VM's blue-green im-webapp is decommissioned; build+push now
targets the mutable :test tag the cluster's kustomize overlay
already tracks, then rolls the k3s deployment instead of running
/opt/apps/im-webapp/deploy.sh.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-14 05:40:03 +08:00
Your Name and Claude Sonnet 5
f9d4d48148
fix: kill zombie pre-rewrite service worker
...
The old service-worker.js (repo root, removed when web/ was rewritten)
cached every same-origin GET keyed only by frontend PACKAGE_VERSION, so
a backend-only change never invalidated it. Browsers that had visited
this origin before the rewrite kept getting stale cached API responses
(bootstrap/session calls) served instead of hitting the real backend --
looked like "login succeeds then immediately bounces back to login".
Adds a same-path kill-switch service-worker.js that purges all caches
and unregisters itself, plus an explicit update() check on app boot so
already-registered browsers don't have to wait for the browser's own
lazy update schedule.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-14 05:27:49 +08:00
Your Name and Claude Sonnet 5
37d08e8989
feat(web): 用符合系统风格的组件替换全部 window.alert/confirm
...
全项目搜出15处 window.confirm、9处 window.alert（其中3处是各文件
各自复制的 notImplemented() 辅助函数，文案还都一样）用在退出登录、
删除消息/收藏/好友、清空聊天记录、解散群聊、转让群主、危险链接
二次确认等场景——全是浏览器原生弹窗，样式和整个应用的设计语言完全
脱节。
新增两个全局UI基础设施（Zustand store + 挂载在App.tsx根节点的
渲染组件，参照stores/calls.ts/messageJump.ts已有的"任何组件都能调用"
惯例，不是每个弹窗各自管理一份本地状态）：
- stores/confirmDialog.ts + app/ConfirmDialogRoot.tsx：替换
window.confirm。requestConfirm()返回Promise<boolean>，和
window.confirm的返回值语义一致，所以原来"if (!window.confirm(...))
return"这一行改成"if (!(await requestConfirm({message:...})))
return"，外层函数标成async，不用大改周围逻辑。危险/不可恢复操作
（删除、解散群聊、注销账号等）传danger:true，确认按钮变红色，
弹窗视觉沿用转发弹窗已有的"描边取消+实心确认"按钮搭配。
- stores/globalToast.ts + app/GlobalToastRoot.tsx：替换window.alert，
复用应用里本来就有、每个页面各自本地状态管理的Toast组件。顺手把
3个文件里各自重复定义、文案完全一样的notImplemented()合并成
一个共享导出。
实机验证了非危险确认（清空缓存，蓝色确认按钮）、危险确认（删除
消息，红色确认按钮）、取消按钮、Escape键取消、全局提示（点"投诉
举报"）——均正常工作，且原有页面各自的Toast错误提示不受影响。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-11 00:08:15 +08:00
Your Name and Claude Sonnet 5
76156a1c75
fix(web): 点表情后光标不再跳出输入框，需要重新点击才能回车发送
...
点表情面板里的emoji这个操作本身没有做"点完之后把焦点还给输入框"
这件事——emoji按钮是个真实的<button>，点击后浏览器会把焦点停在
这个按钮上，导致输入框失焦，这时候按回车自然没反应（键盘事件根本
没送到输入框），要用户重新点一下输入框才能继续打字/发送。
参照"@"提及按钮已有的"点完之后把焦点和光标位置还给输入框"这套写法
（insertMentionTrigger/pickMention），给emoji选择也接上同一套逻辑，
并且改成插入到光标所在位置，而不是永远追加到文本末尾。
顺手把这三处（含原来的两处"@"相关逻辑）从 requestAnimationFrame
换成 setTimeout(fn, 0)：实测确认 requestAnimationFrame 在页面处于
后台/不可见状态时完全不会触发（浏览器的标准省电行为），而这个"点击
按钮后把焦点还给输入框"的操作没有理由依赖页面必须处于前台可见状态
才生效，setTimeout 不受这个限制。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-10 21:49:57 +08:00
Your Name and Claude Sonnet 5
4e1f1cbf0f
refactor(web): 提取共享的圆形多选勾选框组件，统一5处重复实现
...
创建群聊、消息多选、我的收藏多选、黑名单多选、转发选择器——这5个
地方各自手写了一份几乎一样的"圆形+选中变实心+里面check图标"勾选框
markup，样式上有细微且无意的差异（比如有的选中态多画了一圈边框、
用的灰色深浅不完全一致），上次只修了转发选择器一处，用户指出创建
群聊那里同样丑、而且问了"这种组件不该统一做吗"——確实该統一。
新增 `app/SelectionCheckbox.tsx`，把上次在转发选择器里验证过的
矢量勾选图标方案抽成共享组件，5处全部换成调用它。以后这个视觉样式
要再调整，改一个文件就够了，不会再出现"修好了一处，另外四处还是
老样子"的情况。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-10 19:47:08 +08:00
Your Name and Claude Sonnet 5
3280b92a09
fix(web): 转发选择器勾选样式改用矢量图标，好友/群聊可分别展开收起
...
原来的勾选图标是Material Icons字体里的"check"字形，在20px圆圈里塞
14px字体图标，字体本身没有针对这么小的尺寸做过精细调校，稍微放大
一点看就是个不规整的糊状图案。换成手绘SVG勾选路径（矢量、任何缩放
比例下都清晰），并去掉了选中态多余的一层border（原来选中时背景色
和边框色叠在一起，等于多画了一圈没必要的描边）。
好友、群聊两个分组标题现在都可以点击收起/展开（各自独立），列表长
的时候可以先收起不relevant的那一类，收起状态下已经选中的项不会被
清空，"全选"按钮无论展开收起都能点。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-10 19:25:36 +08:00
Your Name and Claude Sonnet 5
e3217a5de9
fix(web): 转发选择器好友/群聊分开全选
...
原来是列表整体一个全选按钮，选中后好友和群聊会一起被勾上。改成
好友、群聊两个分组各自独立的全选/取消全选，互不影响，方便只想
批量选中其中一类的场景（比如只发给所有群，不带上私聊好友）。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-10 19:15:29 +08:00
Your Name and Claude Sonnet 5
46b3288880
feat(web): 下线自主注册与协议勾选，修复转发消息报错，转发选择器分组+全选
...
按产品决定移除面向国内客户不适用的自主注册入口：删除 /register 路由
及 RegisterPage、登录页"马上注册"链接、登录/注册共用的协议勾选组件
Agreement，以及仅注册流程使用的 registerAccount/queueAccExtra 等
死代码；登录不再依赖勾选协议才能提交。
修复转发消息报错（真实高频bug，不限于个别场景）：`forwardMessage`/
`sendText` 发送前只是 `tinode.getTopic()` 取一个本地话题对象，从未
真正订阅——SDK 要求话题处于 attached 状态才允许发布，而只有当前正
打开的会话才满足这一点，一旦切换过/离开过某个会话（哪怕之前订阅过
预览），它就会变回未订阅状态。也就是说转发给"当前会话之外"几乎任何
一个联系人都会失败。新增 `ensureTopicAttached()`，在转发前按需临时
订阅目标话题，单条转发和多选批量转发两处都已接入，实机验证对未打开
过的好友/群转发均成功。
转发选择器（ForwardPickerModal）按好友/群聊分组显示（原来混在一个
列表里），并加了"全选/取消全选"，避免多个接收方时逐条点选。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-10 19:04:59 +08:00
Your Name and Claude Sonnet 5
1826d2906f
feat(web): 会话头像/名称可点击展开详情栏，移除"关于 MeetingIM"设置页
...
聊天窗口头部的头像和昵称此前只是静态展示，只有右侧"i"图标能展开
详情栏；现在点击头像或名称同样会触发 onToggleDetail，单聊群聊均
生效。
按产品决定移除设置里的"关于 MeetingIM"页面（桌面目录、移动端"我的"
二级设置列表两处入口一并去掉），该页面唯一内容是版本号和一个后端
本就不支持 platform=web 的检查更新按钮，删除后 AboutPage.tsx 和
仅被它使用的 lib/api/app.ts 一并清理为死代码。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-10 11:06:46 +08:00
Your Name and Claude Sonnet 5
9271a0a9c1
fix(web): 隐藏文件助手入口，修复自聊天详情栏错误操作
...
后端目前没有支持文件助手所需的配额/分类等能力，只是把它当作
普通话题处理；与其做一个功能不全的界面，先从导航栏、会话列表
置顶区、通讯录固定入口、设置页移动端快捷入口中移除该入口。slf
话题现在按普通会话行为处理（排序、未读计数均不再特殊处理）。
同时修复 DetailColumn 对自聊天（slf）显示语音/视频通话、备注、
拉黑、举报、删除好友等对自己无意义操作的问题，改为仅显示适用
的发消息/查找聊天记录/置顶/免打扰/清空聊天记录等项。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-09 23:35:58 +08:00
Your Name