Mac proof: carets blink and the inspector's thread lands in different places from run to run
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 72/100
Research direction
Start with tools/ci/proof_mac.sh and proof.yml, then inspect how the mac-new-session, mac-question, and mac-inspector screenshots are captured. Disable the focused field’s caret for the shot and make the inspector thread settle at its end after the inspector is shown. Done means repeated Mac proof runs produce matching screenshots for these screens.
Written by the indexing model from the issue text.
Description
The Mac part of the proof (proof.yml, tools/ci/proof_mac.sh, since #241) isn't yet the same pixels from run to run, so a release proof can show changes no code made. Two sources, found by comparing two runs of nearly the same tree: run 42140814167 on #241's branch and run 42142991174 on #242's.
- A blinking caret.
mac-new-sessionandmac-questiondiffer by 32 pixels, a 2 by 16 rectangle where a text field's caret is: (369, 563) and (804, 432). The iPhone's screens don't, all 22 unchanged. - The inspector's thread. On
mac-inspector, the chat lands at a different scroll position once the inspector narrows it: 81,127 pixels between the two runs. Two launches of one build already differ by 104,939 (scratch run 42139594585, attempts 1 and 2), so this is not #242's change. The thread re-wraps for the narrower column, and where it settles is down to timing.
To fix
- Hide the caret on the screenshot fixture, as
~/Developer/AGENTS.mdasks ("no caret blinking in the shot"). Or take the screen with no field focused. - On the
inspectorscreen, scroll the thread to its end again once the inspector is in, before the picture. Or open the inspector before the rows settle, so they lay out once at the narrower width.
🤖 Generated with Claude Code
- Dominant language
- Swift
- Stars
- 1
- Forks
- 0
- Avg merge
- 7h 43m
- Merged PRs (30d)
- 131
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from AttilaTheFun/visor
-
Mac: opening the inspector on a narrow screen loops the split view's layout, then crashesPossibly taken @logan-shire-claude claimed this today. Open
Difficulty 4/5 3-5 days Newbie friendliness 25/100
AttilaTheFun/visor#240 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
AttilaTheFun/visor#227 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 Half a day Newbie friendliness 35/100
AttilaTheFun/visor#210 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 12/100
AttilaTheFun/visor#164 ·
Maintainers usually reply within 1 day
All issues in AttilaTheFun/visor
Similar issues
-
feat: 앱 정보에 개인정보처리방침과 고객지원 연결Possibly taken @xrpjwk8 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
DeveloperAcademy-POSTECH/2026-C6-A13-Hear-I-am#120 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
swiftlang/swift-java#955 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
michaelnisi/hanstholm#246 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
deepsealabs/libdc-swift#110 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
jaywcjlove/quick-rss#448 ·