Selecting a pen color leaves Example drawing in eraser mode
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 78/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- javascript
- Área
- frontend
Línea de trabajo
Empieza por el controlador del botón de color y el controlador de puntero en web/example-board.js; después, compara su comportamiento con selectPen() en web/interview.js. Añade o actualiza la prueba de regresión en example-board.test.js para cubrir el cambio de Eraser a un color de lápiz y la selección explícita de Eraser. El trabajo estará terminado cuando el color seleccionado dibuje un trazo de lápiz con el ancho esperado, los estados de la barra de herramientas coincidan con la herramienta activa y Eraser siga produciendo trazos de borrador.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Problem and motivation
In the coding interview's Example drawing panel, selecting a pen color after using the eraser does not switch back to the pen. The color button becomes selected, but subsequent strokes still erase existing content. A candidate trying to annotate a diagram in another color can therefore erase it instead.
The color buttons have labels such as Pen Red, which suggest that selecting one activates that pen. The full whiteboard already follows this behavior, so the two drawing surfaces respond differently to the same action.
Steps to reproduce
- Select Editor mode and enable Example drawing in the lobby.
- Start an interview and enter the live coding phase.
- Expand Example drawing and draw a black line.
- Select Eraser.
- Select the red pen color.
- Draw across the black line.
Expected:
Selecting the red pen color activates the pen, and the next stroke draws a red line.
Actual:
The red color is selected, but Eraser remains active and the next stroke erases the black line.
Initial analysis
In web/example-board.js, the color-button handler updates color and the color buttons' aria-pressed states, but leaves tool unchanged. The pointer handler later passes that unchanged tool to model.begin(), so the board continues producing eraser strokes.
The full whiteboard handles this through selectPen() in web/interview.js, which sets both the color and board.tool = "pen" before updating the toolbar. Applying the same interaction rule to Example drawing would make the selected color and the active drawing tool agree.
Proposed implementation
Keep the change within the Example drawing toolbar. Selecting a color should activate the pen and update both the pen/eraser buttons and the color buttons to reflect the resulting state. Eraser behavior should remain available through its explicit control.
Add a regression test that selects Eraser, selects a pen color, and draws a stroke. Assert that the stroke uses the selected color and pen width, that Pen is active, and that Eraser is inactive. Also verify that explicitly selecting Eraser still produces an eraser stroke.
Verification so far
At checkout revision fd7c23c, a module-level reproduction using the actual mountExampleBoard() implementation with simulated DOM and canvas objects produced a white, width-24 eraser stroke after selecting Eraser and then Pen Red. The red color button and Eraser both remained pressed.
The existing example-board.test.js suite passed all eight tests. The interaction above has not yet been manually verified in a real browser; the steps listed above are the browser verification procedure.
- Lenguaje dominante
- Rust
- Estrellas
- 177
- Forks
- 100
- Merge medio
- 1 d 8 h
- PR fusionados (30 d)
- 168
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de sysprog21/codetrial
-
Python tests lose every result when the solution returns inf or NaNPosiblemente ocupada @shensyuan la tomó hace 1 día. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
sysprog21/codetrial#419 · 3 comentarios · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Allow deselecting a chosen problem card by clicking it againPosiblemente ocupada @woohsin la tomó hace 1 día. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
sysprog21/codetrial#392 · 4 comentarios · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Audio output can be confirmed without playing a test soundPosiblemente ocupada @ChenYingHan1121 la tomó hace 3 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
sysprog21/codetrial#359 · 5 comentarios · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Add a Copy code button to the final reportPosiblemente ocupada @yansawu la tomó hace 4 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 80/100
sysprog21/codetrial#318 · 5 comentarios · 2 reacciones · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
Todos los issues de sysprog21/codetrial
Issues similares
-
state:triage-needed
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
bug P2
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
pedrovgs/UseCaseCoverage#23 ·
-
area: library data-loss tier: p0 type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
llm translation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día