Resizing a text box by one edge handle incorrectly locks both Max Width and Max Height, silently clipping text
I maintainer di solito rispondono entro 1 giorno
@GuTS805 ci sta già lavorando.
Dal 10/8/2026.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 78/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Tranquilla
- Stack tecnologico
- rust
- Ambito
- computer-graphics
Direzione di ricerca
Inizia in editor/src/messages/tool/tool_messages/text_tool.rs, nell’handler ResizingBounds → PointerMove intorno alle righe 851-920, e leggi il TODO vicino. Poi esamina SelectedEdges in transformation_cage.rs e il modo in cui new_size() gestisce i trascinamenti di un singolo bordo. Il lavoro è completato quando un trascinamento del bordo sinistro/destro attiva solo i vincoli di larghezza, un trascinamento del bordo superiore/inferiore attiva solo i vincoli di altezza e un trascinamento di un angolo attiva entrambi senza ritagliare il testo riavvolto.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Dragging a single edge handle to resize a text layer's bounding box incorrectly enables and locks both the Max Width and Max Height constraints together, even when only one axis was actually resized. Since Max Height causes any text beyond it to not be drawn, this can silently clip text that should still be auto-growing.
Steps to reproduce:
- Select the Text tool and click (don't drag) to create point text, then type several lines — this creates auto-sized text with neither Max Width nor Max Height enabled
- Switch to resizing and drag only the right-edge handle of the bounding box to set a width (so the text wraps)
- Expected: only Max Width becomes active; height keeps auto-growing to fit the rewrapped text
- Actual: Max Height also gets switched on and frozen to whatever the box's height happened to be before the rewrap — any lines that end up pushed past that frozen height are silently not drawn
Cause:
In editor/src/messages/tool/tool_messages/text_tool.rs, the ResizingBounds → PointerMove handler (around lines 851-920) unconditionally sets both HasMaxWidthInput/MaxWidthInput and HasMaxHeightInput/MaxHeightInput, regardless of which edge is being dragged. There's actually a TODO comment already sitting right above this code:
// TODO: Don't set both max_width and max_height to true at the same time, only do one based on which edge is being dragged (or both if a corner is being dragged)
The information needed to fix it is already available and just unused: SelectedEdges { top, bottom, left, right } in transformation_cage.rs records exactly which edge(s) are being dragged, and new_size() already leaves size.y untouched (equal to the pre-drag height) when only a left/right edge is dragged — that stale value is what's getting wrongly frozen into MaxHeightInput.
Suggested fix:
Gate the two pairs of SetInput calls on which axis was actually touched, per the existing TODO:
let (touches_width, touches_height) = (movement.left || movement.right, movement.top || movement.bottom);
if touches_width {
// set HasMaxWidthInput / MaxWidthInput
}
if touches_height {
// set HasMaxHeightInput / MaxHeightInput
}
A corner-handle drag naturally sets both pairs of edges, so both branches fire together there, matching the "(or both if a corner is being dragged)" note in the TODO.
- Lingua principale
- Rust
- Stelle
- 27.4k
- Fork
- 1.3k
- Merge medio
- 15h 15m
- PR unite (30g)
- 91
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di GraphiteEditor/Graphite
-
Type hint is selected in node graph viewForse già presa @sahilsahni18 l’ha presa 89 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
GraphiteEditor/Graphite#4311 ·
I maintainer di solito rispondono entro 1 giorno
-
`cargo run` fails on WebAssembly target due to `CARGO_BUILD_TARGET` leaking into `rustc_codegen_spirv` buildForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
GraphiteEditor/Graphite#3939 · 2 commenti · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
GraphiteEditor/Graphite#4650 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 45/100
GraphiteEditor/Graphite#4649 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
GraphiteEditor/Graphite#4632 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di GraphiteEditor/Graphite
Issue simili
-
feature request good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
TabularisDB/tabularis#853 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
andrewdavidmackenzie/jonesy#267 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 4 giorni
-
`future_into_py` loses the original panic messageForse già presa @Danipulok l’ha presa oggi. Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
PyO3/pyo3-async-runtimes#91 ·
-
Signals (Failure Detector): a tool call and its own execution are reported as a repeated callAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno