Android diff viewer draws word-diff highlights at the wrong position when "monospace" resolves to a proportional font
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 78/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- android, typescript
Hướng nghiên cứu
Đọc ReviewDiffCanvasDrawing.kt, đặc biệt là drawWordDiffRanges, và so sánh vị trí đánh dấu với độ tiến đã đo mà drawCode sử dụng. Báo cáo xác định asciiFixedPitch là tín hiệu hiện có cho các phông chữ dự phòng có độ rộng ký tự tỷ lệ. Tái hiện bằng một diff Android sử dụng phông chữ đơn cách dự phòng có độ rộng ký tự tỷ lệ; hoàn thành khi phần đánh dấu các từ đã thay đổi khớp với các ký tự đã thay đổi mà không che phủ văn bản liền kề.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
What happened
In the Android app's diff viewer (the Changes screen for a PR/turn), the red/green word-level highlights on changed lines are drawn in the wrong place. They are shifted to the right and are wider than the text they should mark, often covering unchanged characters or empty space after the line.
Example from the screenshot (to be attached below):
go.mod:go 1.25→go 1.27.3. On the deleted line the red highlight is an empty box after the end ofgo 1.25, not over the5.runbook.md:- `go ≥ 1.25` (builds `factory/cmd/role-assigner` …→- `go ≥ 1.27.3` …. The highlights land over`fa/s `fa(inside the path) instead of over the version number.
The code text in the diff is visibly rendered in a proportional font on this device, not a monospace one.
Diagnosis
ReviewDiffCanvasDrawing.drawWordDiffRanges positions every highlight by character index times the width of "M":
val characterWidth = textPaint.measureText("M")
...
val left = codeX + (start - lineStart) * characterWidth
val right = max(left + 2f * density, left + (end - start) * characterWidth)
This assumes the code typeface is fixed-pitch. The typeface is Typeface.create("monospace", …) (L524-L533), and on this device (OPPO Find X9 Pro, stock settings, no custom font chosen) that family resolves to a proportional font. The text itself is drawn with real measured advances (measureText per run in drawCode), so text and highlights drift apart. The error grows with the column, and highlights are too wide because "M" is wider than the average proportional glyph.
The same class already detects this case. asciiFixedPitch (L223, L274-L278, with the comment "Some system font weights resolve to proportional fallbacks even for "monospace"") is used for row width measurement (L316), but drawWordDiffRanges does not consult it. Measuring the prefix and range with textPaint.measureText(content, start, end) (or using asciiFixedPitch to choose that path) would align the highlights with the rendered text.
This code was introduced in #3967 and is unchanged on main (dd14848) and in Android beta 2.2.0 (735).
Steps to reproduce
- Use an Android device where the system
monospacefamily is not fixed-pitch (seen on an OPPO Find X9 Pro with default settings). - In the Android app, open a thread's Changes / PR diff view containing an edited line where the change is mid-line, e.g.
go 1.25→go 1.27.3in ago.mod. - Look at the red/green word-diff highlights on the deleted and added lines: they are offset to the right of the changed characters and too wide.
On a device whose monospace is genuinely fixed-pitch, the highlights line up (expected behavior).
Version
Android app 2.0.0 (code path unchanged through 2.2.0 beta and current main)
Environment
OPPO Find X9 Pro, Android (ColorOS, stock fonts), T3 Code Android app 2.0.0, connected to a T3 Code server on Linux
Evidence
# Screenshot attached separately: go.mod and runbook.md hunks in the Android Changes view
# showing word-diff boxes offset from the changed characters.
Related issues
#4582: monospace fell back to a proportional font on Android, but for React Native font-mono text surfaces (Uniwind font-family list). This report is the native review-diff canvas, which already requests monospace correctly but positions highlights as if it were fixed-pitch.
Fix applied or workaround
None. Nothing user-side changes the font resolution without a custom system font.
Filed by
Claude Code (Claude Opus 5.5, claude-opus-5-5) via t3 triage
- Ngôn ngữ chính
- TypeScript
- Star
- 24.8k
- Fork
- 6.4k
- Merge trung bình
- 14 giờ 40 phút
- Pull request đã merge (30 ngày)
- 193
Chuẩn bị môi trường
Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của pingdotgg/t3code
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
pingdotgg/t3code#27767 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: Dragging a sidebar thread from the lower part of the list auto-scrolls the sidebar to the bottomCó thể đã có người làm @juliusmarminge đã nhận 1 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
pingdotgg/t3code#27445 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
pingdotgg/t3code#27022 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của pingdotgg/t3code
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Northeastern-Electric-Racing/FinishLine#4660 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
excaliburjs/Excalibur#3895 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
infer_audio_type only recognises one MPEG Layer III frame header, so most MP3 files are rejectedCó thể đã có người làm @Steve-20-ai đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Earn report crashes with "RangeError: Invalid time value" when a report row has an unparsable timestampCó thể đã có người làm @Gurkaran18 đã nhận hôm nay. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
joinmarket-webui/jam#1588 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
BeOS .json missingĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
mihaip/infinite-mac#475 ·