Repository navigation
Conversation
The task strip had no way to shrink a busy queue: the rows kept the official shape, but thirty jobs filled the whole strip and the last ones were only reachable by scrolling inside it. The rows stay the ones the official build draws, in its order. What is new is a layer on top: the first five rows stay in the open, the rest fold into one line that says how many jobs are left, and a click brings them back. The button sits below the rows' own scroll area, so it stays reachable however long the queue is, and the strip keeps the height budget the official one had.
Three matches the number the folded reply bubbles keep, and it leaves the transcript more room when a queue is long.
The task strip fold is a build of its own on top of the merged 0.7.5.
The fold took a long reply's earlier bubbles behind a summary line. The queue of background jobs was the thing that needed folding, so the bubbles go back to the flat layout the official build draws: one bubble per recorded part, in the order it records them. What was missing there was a gap between them. One reply with many parts drew its bubbles flush against each other, so they read as one block of text; a small gap, the one the task rows use, tells them apart.
MyPrototypeWhat
left a comment
There was a problem hiding this comment.
Thanks for the update. I re-reviewed b6a192c..a720941 and the full diff against main (0c187f3).
What a720941 does
It removes the long-reply bubble fold that #48 shipped (merged as 0c187f3) and puts the flat layout back: one bubble per recorded part, in recorded order. The only new piece is a gap: 4px on .bubble-wrap, so the bubbles of one reply no longer sit flush against each other.
Removed from #48:
FOLD_AFTER_PARTS,hintOf(),foldView()and the folding branch inpartViews();- the hover
titleon bubbles (both inside the fold and on the open bubbles of a folded reply); - all
.bubble-fold*CSS; - the
fold.show/fold.hide/fold.hintstrings, in both zh and en; - three tests (fold + newest three, hover titles, short reply without fold) and the fixed-height CSS test. They are replaced by "a long reply keeps every bubble in the open" (13 bubbles, reaction chip on the last one) and a CSS test for the 4px gap;
- the README bullet "Folded working messages", rewritten as "Working messages of one reply".
Kept from #48: the reply actions at the bottom-left and the reaction indicator above them are untouched (updateBubbleControls is called exactly as before, and the "multi-line reply keeps its actions below the text…" test still runs and passes).
The revert is clean. A grep for bubble-fold, hintOf, FOLD_AFTER_PARTS, foldView and fold.* finds only the new test's querySelector('.bubble-fold') === null assertion, which is intentional. There is no dead CSS, no orphaned strings and no stale tests. The icon('down') that the fold used is still used elsewhere.
Task strip (unchanged since my last pass)
The task strip still keeps the official rows: 3 rows stay in the open and the rest fold into "N more tasks", which expands and collapses; heights 166px folded / 280px opened, per your description. The non-blocking nits from my last pass still apply: the duplicated fold condition, helpersExpanded not resetting when the queue shrinks, and the missing trailing newline in the test file.
Scope / title: please clarify before merge
The description does mention that the fold "is gone", but the title still reads only "fold a long queue of background jobs behind one line". Someone scanning the history won't see that this PR reverses a feature merged earlier today, and the description never names #48. Could you:
- update the title to cover both changes, e.g.
fix(minimax-bot): fold the background job queue, drop the long-reply bubble fold from #48; - add one line to the description saying that this reverts the bubble fold from #48 (
0c187f3) and why (the job queue was the part that needed folding; the bubble fold changed the official reply layout).
Alternatively, split the bubble change into its own PR, so the job-queue fold can land on its own.
The code itself looks fine to me. This is about making the reversal explicit, not about the implementation.
Results
npm run checkat repo root (Node 22.14.0): pass;plugins/minimax-ai/minimax-bot: OK, contract tests 69/69.node --test testsinplugins/minimax-ai/minimax-bot(Node 20.19.2, Linux): 205/205 pass. That includes the two new bubble tests and the task-strip fold test; the Windows timeouts you mention don't reproduce here.
Happy to approve once the title/description are updated.
What changed / 改动内容
Two things about how the page shows what a Bot is doing.
The background task strip above the composer draws one line per background job: who is doing what, the elapsed time, and a stop button at the end of the row. A busy chat therefore fills the strip with rows, and the jobs at the end of it are only reachable by scrolling inside a 280 px box. The rows stay exactly as the official build draws them, in the order it draws them. What is new is a layer on top of them: the first three rows stay in the open, the rest fold into one line that says how many jobs are left, and a click brings them back. The button sits below the rows' own scroll area rather than inside it, so it stays reachable however long the queue is, and the strip keeps the height budget the official one had: 166 px folded, 280 px opened, with the rows scrolling on their own.
The bubbles of a reply go back to the flat layout the official build draws: one bubble per recorded part, in the order it records them. The fold that used to take the earlier bubbles of a long reply behind a summary line is gone; the queue of background jobs was the thing that needed folding. What the flat layout was missing is a gap between the bubbles. One reply with many parts drew them flush against each other, so they read as one block of text; a small gap, the one the task rows use, tells them apart.
The package version is bumped to 0.7.6.
两件事,都是页面怎么展示 Bot 在做的事。
输入框上方的后台任务条是每个后台任务一行:谁在做什么、用了多久,行尾一个停止按钮。聊天一忙,这条就被任务行占满,靠后的任务只能在 280 px 的框里滚动才看得到。任务行保持官方的画法和顺序。新加的是加在上面的一层:前三行留在外面,其余折成一行,写明还剩多少个任务,点一下就展开。按钮放在任务行自己的滚动区下面而不是里面,所以队列再长也点得到,整条的高度预算也还是官方的那个:收起 166 px,展开 280 px,行在里面自己滚。
回复里的气泡回到官方的平铺形态:每个记录的 part 一个气泡,顺序照旧。此前把长回复的前几个气泡收进摘要行的那层折叠撤掉了,要折叠的是后台任务队列。平坦形态缺的是气泡之间的间隔:一条回复带很多 part 时,气泡一个挨一个连成一片,看起来像一整块文字;补一点间隔(跟任务行用的同一种)就分得开了。
包版本升到 0.7.6。
Test environment and results / 测试环境与结果
Windows 11, Chrome 156, MiniMax Code 3.1.2.
npm run checkreportsplugins/minimax-ai/minimax-bot: OKwith 0 errors and the root contract tests pass 69/69; the package suitenode --test testsgives 203 passed and 2 failed out of 205.The behaviour was measured in a real Chrome over the DevTools protocol against a build seeded with thirty background jobs: folded, the task strip is 166 px high and shows three rows plus one line that says twenty-seven jobs are left; opened, it shows all thirty rows inside the 280 px budget, the rows scrolling on their own, with the fold button below them. A group chat with six jobs folds to the same three rows plus one line that says three jobs are left.
The bubbles were measured the same way: a reply with thirteen recorded parts draws thirteen bubbles, the gap between every two of them is 4 px, and no summary line is left in the message. The group chat with the 119 part reply draws its 119 bubbles with the same 4 px between them.
The tests pin both: the task strip keeps the official rows, the first three stay in the open while the rest of the queue folds into one line that can be expanded, and the strip stays empty when no job is running; a long reply keeps every bubble in the open, one per recorded part, and the bubbles of one reply keep a small gap between them.
The two failing package tests are pre-existing on this machine and reproduce on the unmodified base commit:
restart after questionnaire …andrestart after dependency verification …both time out after 12 s on Windows. Two more,avatar library persists imports …andHTTP task snapshot and stop endpoint …, fail intermittently when the machine is busy and pass in a quiet run; the avatar one also reproduces on the unmodified base commit.Windows 11、Chrome 156、MiniMax Code 3.1.2。
npm run check报plugins/minimax-ai/minimax-bot: OK,0 error,根契约测试 69/69 通过;包内node --test tests是 205 条里 203 通过、2 失败。行为是用真实 Chrome 跑 DevTools 协议量出来的,对象是塞了三十个后台任务的那份数据:收起时任务条 166 px 高,三行任务加一行"还有 27 个任务";展开时三十行都在 280 px 预算里,任务行自己滚,折叠按钮在下面。六个任务的群聊收成同样三行加一行"还有 3 个任务"。
气泡也是同样量的:一条带 13 个 part 的回复画 13 个气泡,每两个之间的间隔是 4 px,消息里不再有摘要行。群里那条 119 个 part 的回复,119 个气泡之间也是 4 px。
用例把两件事都钉住:任务条保持官方的行,前三行留在外面、其余队列折成一行可展开,没有后台任务时任务条是空的;长回复的每个 part 一个气泡全部留在外面,一条回复的气泡之间留一点间隔。
那两条失败的包内用例是本机 Windows 上既有的问题,在未改动的基线提交上同样复现:
restart after questionnaire …与restart after dependency verification …在 Windows 上 12 秒超时。另有两条(avatar library persists imports …与HTTP task snapshot and stop endpoint …)在本机忙时偶发失败,安静时能过;头像那条在未改动的基线提交上同样复现。Unverified / 未验证
The package tests were not run on macOS or Linux; only Windows was available here. Both changes were checked by hand in a locally installed copy seeded with thirty background jobs and a 119 part reply, and over the DevTools protocol in a real Chrome; the official install was not replaced, so the official MiniMax Bot still shows the old rendering until this is merged and released. The rest of the package is unchanged.
包内测试没在 macOS / Linux 上跑过,本机只有 Windows。两处改动都在本地副本里手测过(数据是塞了三十个后台任务和一条 119 个 part 的回复),也在真实 Chrome 里用 DevTools 协议量过;官方安装没有被覆盖,所以官方 MiniMax Bot 在合并发布之前仍是旧的渲染。包内其它部分没有改动。