Problem
The case timeline view mounts the timeline_view Vue component from app/templates/case/case_view.html and loads the bundled TimelineJS implementation from app/static/js/vendor/timelinejs.js.
app/static/js/case/timeline_view.js renders existing timeline events with a date input bound to edit_date_text and a description textarea bound to edit_description. The same component also creates a TL.Timeline instance.
The bundled TimelineJS constructor registers a keydown listener on document. It handles ArrowLeft and ArrowRight without checking whether the event originated from an editable control. Its previous/next navigation then focuses the timeline container.
As a result, pressing the right arrow while editing a date or description advances the graphical timeline and removes focus from the field instead of preserving normal caret navigation. The left arrow is subject to the same global handler.
This prevents reliable keyboard editing. No equivalent issue or pull request was found in this repository.
Proposed approach
Modify app/static/js/case/timeline_view.js so left/right arrow events originating from timeline text inputs and textareas do not propagate to the document-level TimelineJS handler. Keep the browser default action enabled so the caret and text selection still behave normally.
Prefer a local reusable handler or Vue event modifiers over editing the vendored app/static/js/vendor/timelinejs.js. Apply the protection consistently to editable timeline event fields, including the add form where the same global conflict can occur.
This requires frontend code changes and automated regression tests. It does not require backend, API, database, configuration, deployment, or migration changes. No documentation change is expected because this restores standard text-field behavior.
Scope
- Protect the date input and description textarea used to edit an existing event.
- Protect equivalent date and description controls in the add-event form for consistent keyboard behavior.
- Preserve native caret movement and selection behavior inside these controls.
- Preserve TimelineJS left/right navigation when focus is outside an editable control.
- Add automated frontend regression coverage for event propagation, focus retention, caret movement, and timeline navigation.
- Keep save, cancel, validation, sorting, import, rendering, and API behavior unchanged.
- Do not modify the bundled TimelineJS vendor file or upgrade TimelineJS as part of this issue.
- Backend routes, schemas, migrations, and deployment changes are outside scope.
Acceptance criteria
- With an existing timeline event in edit mode, pressing
ArrowRight in the date input keeps focus in that input and performs native caret or selection movement without changing the displayed TimelineJS slide.
- The same behavior is verified for
ArrowLeft.
- Both arrow keys preserve native editing behavior in the description textarea without changing the displayed TimelineJS slide.
- Equivalent add-event date and description controls do not trigger TimelineJS navigation.
- Left/right arrow navigation still changes TimelineJS slides when focus is on the timeline or another non-editable target where timeline keyboard navigation is expected.
- Saving and cancelling an edit continue to work unchanged.
- Automated regression tests cover editable and non-editable targets and pass in CI.
- Unrelated case timeline behavior remains unchanged.
Dependencies
None identified.
Problem
The case timeline view mounts the
timeline_viewVue component fromapp/templates/case/case_view.htmland loads the bundled TimelineJS implementation fromapp/static/js/vendor/timelinejs.js.app/static/js/case/timeline_view.jsrenders existing timeline events with a date input bound toedit_date_textand a description textarea bound toedit_description. The same component also creates aTL.Timelineinstance.The bundled TimelineJS constructor registers a
keydownlistener ondocument. It handlesArrowLeftandArrowRightwithout checking whether the event originated from an editable control. Its previous/next navigation then focuses the timeline container.As a result, pressing the right arrow while editing a date or description advances the graphical timeline and removes focus from the field instead of preserving normal caret navigation. The left arrow is subject to the same global handler.
This prevents reliable keyboard editing. No equivalent issue or pull request was found in this repository.
Proposed approach
Modify
app/static/js/case/timeline_view.jsso left/right arrow events originating from timeline text inputs and textareas do not propagate to the document-level TimelineJS handler. Keep the browser default action enabled so the caret and text selection still behave normally.Prefer a local reusable handler or Vue event modifiers over editing the vendored
app/static/js/vendor/timelinejs.js. Apply the protection consistently to editable timeline event fields, including the add form where the same global conflict can occur.This requires frontend code changes and automated regression tests. It does not require backend, API, database, configuration, deployment, or migration changes. No documentation change is expected because this restores standard text-field behavior.
Scope
Acceptance criteria
ArrowRightin the date input keeps focus in that input and performs native caret or selection movement without changing the displayed TimelineJS slide.ArrowLeft.Dependencies
None identified.