Regression: Plan tab reading-column cap is back (fixed in v1.1.12 via #2888, broken again in v1.1.22)
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 55/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- markdown
- Lĩnh vực
- desktop
Hướng nghiên cứu
Start at the workspace Plan tab's rendered markdown view and compare its behavior with the #2888 fix from v1.1.12. Reproduce with the provided column ruler while widening or maximizing the panel. Done means rendered text uses the available width and a regression test covers the reflow behavior.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
This is a regression of #2888 (fixed in v1.1.12). The Plan tab's rendered markdown view again caps prose to a fixed reading column (~95-100 characters) instead of using the available panel width. Reproduced on v1.1.22.
The original bug (#2888) was closed as fixed in v1.1.12; the reflow behavior has since regressed. This is distinct from the chat/conversation-view width issues (#3195, #3795) - it is specifically the workspace Plan tab.
What happens
Widening the panel or the whole window - including Maximize Panel - does not reflow the rendered text; it stays in the same narrow column with dead space on the right. The <> code view of the same plan has no such cap and runs edge-to-edge.
Steps to reproduce
- Open a session so the Plan tab is visible (close and re-open the tab to force a fresh render).
- Use a plan whose body contains this column ruler (each label sits at its true character column):
--------10--------20--------30--------40--------50--------60--------70--------80--------90-------100-------110-------120-------130-------140-------150-------160
- View the rendered Plan tab, then widen the panel / click Maximize Panel.
Expected
The rendered text reflows to use the available panel width, as it did after the #2888 fix in v1.1.12.
Actual
Text wraps at ~column 96 regardless of panel or window width - the ruler breaks right after the 90 label even in a maximized panel. The <> code view is unaffected (full width).
Environment
- App version: 1.1.22 (regressed; last known good: v1.1.12)
- OS: Windows
- Surface: workspace Plan tab (rendered markdown view)
Related
- #2888 - original report, fixed in v1.1.12, now regressed (this issue)
- #2608 - same class of reflow bug in the MD Editor, fixed in v1.1.6
- #3195, #3795 - chat/conversation-view horizontal-space issues (different surface)
Suggested fix
Restore the #2888 reflow fix for the Plan tab's rendered view, and consider a regression test so this surface's reflow doesn't break again. A width preference (e.g. 120 / 140 / full-width) for rendered markdown surfaces would also help.
- Ngôn ngữ chính
- Không có dữ liệu ngôn ngữ
- Star
- 2.1k
- Fork
- 157
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
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 github/app
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Issue tương tự
-
[Super Editor][Chat] - Floating editor scaffold does not reset panel height after closing panel Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
bug channel: beta feature: preferences feature: ui/ux
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
bug editor script-component smart items
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
decentraland/creator-hub#1654 ·
-
awaiting triage bug Causes friction Hop Gui P1 P2 Transforms
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100