-
Notifications
You must be signed in to change notification settings - Fork 3k
fix(web-shell): stabilize mobile composer after resume #8263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Suggestion] The positive branch of this wiring — animated placeholder ON in the welcome/empty state — has no test at the App integration level; only the negative branch (off in-session) is pinned, by the new mobile e2e assertion. — Failure scenario: the mutation
animatePlaceholder={isChatEmptyState}→animatePlaceholder={false}survives every test in this diff: the ChatEditor unit tests render the component directly and never exercise App's prop wiring, and the mobile e2e visits/session/<id>whereisChatEmptyStateis alreadyfalse, sotoHaveCount(0)passes either way. The welcome page could silently lose its animated placeholder and CI would ship green. Suggested fix: add an e2e (or App-level render test) that loads the pre-session welcome state and asserts the typewriter is present, pairing the mobile spec's in-session count-0 assertion so both sides of the wiring are pinned.中文说明
这段接线的正向分支——在欢迎/空状态下开启动画占位文本——在 App 集成层面没有测试;只有负向分支(会话内关闭)被新的移动 e2e 断言固定。— 失败场景:将
animatePlaceholder={isChatEmptyState}突变为animatePlaceholder={false}后,本 diff 中的所有测试仍能通过:ChatEditor 单元测试直接渲染组件,从不验证 App 的 prop 接线;而移动 e2e 访问的是/session/<id>,此时isChatEmptyState已为false,因此toHaveCount(0)无论如何都会通过。欢迎页可能会悄无声息地失去动画占位文本,而 CI 仍会绿灯通过。建议修复:增加一个 e2e(或 App 层渲染测试),加载会话前的欢迎状态并断言打字机存在,与移动 spec 中会话内 count-0 的断言配对,从而固定接线的两侧。— qwen3.8-max-preview via Qwen Code /review
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Declined — not worth the diff-growth/flakiness tradeoff. The component-level default (
animatePlaceholder=true) is already pinned: the pre-existing ChatEditor typewriter test renders the component with the prop omitted and asserts the typewriter mounts and plays. The remaining gap you correctly identify is the App-level wiring's positive branch (welcome state → typewriter present). Pinning that needs a welcome-state (/) e2e or an App-render test; every existing web-shell e2e visits/session/<id>against the mock daemon, so a welcome-state spec would add new scaffolding and flakiness risk disproportionate to the risk of a single-line, review-visible prop pass-through mutating tofalse. Happy to add a welcome-state e2e if a maintainer wants both sides of the wiring pinned.中文说明
已拒绝——不值得以 diff 膨胀/不稳定性为代价。组件层默认值(
animatePlaceholder=true)已被固定:已有的 ChatEditor 打字机测试在不传该 prop 的情况下渲染组件,并断言打字机挂载并播放。你正确指出的剩余缺口是 App 层接线的正向分支(欢迎状态 → 打字机存在)。要固定它需要一个欢迎状态(/)e2e 或 App 渲染测试;而现有所有 web-shell e2e 都在 mock daemon 下访问/session/<id>,因此一个欢迎状态的用例会引入新的脚手架,且其不稳定性风险与“单行、审查可见的 prop 透传被改为false”这一低风险不相称。如果维护者希望固定接线的两侧,我很乐意补充一个欢迎状态的 e2e。