Add touch-screen dragging support for touch-screen devices

[dhruvDev23]

Documentation Update

Related Feature:

This PR addresses a significant accessibility problem. The floating chatbot assistant widget was movable on desktop devices with mouse interactions. However, it was completely still and non-interactive on mobile, tablet, and touch-screen laptop screens.

Changes:

• Modular Drag Handlers: Refactored the core dragging math inside static/js/chatbot.js into reusable helper functions (handleStart, handleMove, and handleEnd) to support unified mouse and touch input.
• Touch Event Listeners: Registered standard mobile touch events (touchstart, touchmove, touchend, and touchcancel) on the chatbot header.
• Interruption Prevention: Added e.preventDefault() inside the touchstart listener to block default browser touch actions (such as standard scrolling or cursor focus) when dragging is initiated.
• CSS Touch Action Bypass: Added touch-action: none; to the .krkn-chat-header class in static/css/chatbot.css. This prevents modern mobile browsers from panning/scrolling the underlying page and prematurely canceling the swipe gestures.

[netlify]

✅ Deploy Preview for krkn-chaos ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	77fa85a
🔍 Latest deploy log	https://app.netlify.com/projects/krkn-chaos/deploys/6a0f3e3b235e910008f095cc
😎 Deploy Preview	https://deploy-preview-497--krkn-chaos.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[qodo-code-review]

Review Summary by Qodo

Add touch-screen dragging support for chatbot widget

✨ Enhancement

Walkthroughs

Description

• Refactored drag handlers into reusable functions for unified mouse and touch support
• Added touch event listeners for mobile and tablet device compatibility
• Implemented touch-action: none CSS to prevent browser interference with dragging
• Added passive: false option to enable preventDefault() on touch events

Diagram

flowchart LR
  A["Mouse Events"] --> B["Unified Handlers"]
  C["Touch Events"] --> B
  B --> D["handleStart"]
  B --> E["handleMove"]
  B --> F["handleEnd"]
  D --> G["Drag Logic"]
  E --> G
  F --> G
  H["CSS touch-action: none"] --> I["Prevent Browser Interference"]

Loading

File Changes

1. static/js/chatbot.js ✨ Enhancement +35/-11

Refactor drag handlers and add touch support

• Extracted drag logic into three reusable handler functions (handleStart, handleMove,
 handleEnd) that accept normalized coordinates
• Registered touch event listeners (touchstart, touchmove, touchend, touchcancel) on chatbot
 header with passive: false option
• Refactored mouse event listeners to use the new handler functions for code reuse
• Moved preventDefault() calls to appropriate handlers to prevent default browser behaviors

static/js/chatbot.js

---

2. static/css/chatbot.css ✨ Enhancement +1/-0

Add touch-action CSS property

• Added touch-action: none property to .krkn-chat-header class to prevent browser panning and
 scrolling during touch dragging

static/css/chatbot.css

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Close tap prevented ✓ Resolved 🐞 Bug ≡ Correctness

Description

In setupBasicDragging(), the header’s touchstart/mousedown handlers call e.preventDefault()
unconditionally, even when handleStart() early-returns for .krkn-chat-close. On touch devices this
can cancel the subsequent click event, breaking the close button’s click handler (toggleChat).

Code

static/js/chatbot.js[R476-488]

Evidence

The close button is a <button> with a click handler, but the new touchstart handler prevents default
even when handleStart() returns early for that button; this can suppress the click and stop
toggleChat from firing on touch devices.

static/js/chatbot.js[312-377]
static/js/chatbot.js[428-441]
static/js/chatbot.js[483-488]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The chat header listeners always call `e.preventDefault()` even when the event target is the close button, because the close-button guard lives inside `handleStart()` but `preventDefault()` is invoked outside it. On touch devices, preventing default on `touchstart` commonly suppresses the synthetic `click`, so the close button may stop working.

## Issue Context
- `handleStart()` returns early for `.krkn-chat-close`, but the wrappers still prevent default.
- The close button relies on a `click` listener to call `toggleChat()`.

## Fix Focus Areas
- static/js/chatbot.js[428-441]
- static/js/chatbot.js[475-488]
- static/js/chatbot.js[329-377]

## Suggested fix
- Make `handleStart(...)` return a boolean like `didStartDragging`.
- Only call `e.preventDefault()` in the `mousedown`/`touchstart` handlers when `didStartDragging` is true.
- Alternatively, perform the `.closest('.krkn-chat-close')` check in the wrapper before calling `preventDefault()`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Untracked touch identifier ✓ Resolved 🐞 Bug ≡ Correctness

Description

Touch dragging always reads e.touches[0] and never tracks the initiating touch identifier, so
adding/removing a second finger can swap which touch is index 0. This can cause incorrect deltas and
visible “jumping” of the chat window during a drag.

Code

static/js/chatbot.js[R484-494]

Evidence

Both touchstart and touchmove explicitly use e.touches[0], and there is no stored touch identifier
to ensure subsequent moves use the same finger that initiated the drag.

static/js/chatbot.js[483-495]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The drag logic uses `e.touches[0]` for both `touchstart` and `touchmove` without remembering which touch began the drag. In multi-touch scenarios, `touches[0]` can change, producing wrong drag deltas.

## Issue Context
`dragStart` is set once on start, but subsequent moves may use a different touch point if multiple touches exist.

## Fix Focus Areas
- static/js/chatbot.js[424-450]
- static/js/chatbot.js[483-495]

## Suggested fix
- On `touchstart`, store `activeTouchId = e.touches[0].identifier` (only if `touches.length === 1`, or pick the first touch intentionally).
- On `touchmove`, locate the touch with that identifier (search `e.touches`), and ignore the move if not found.
- On `touchend/touchcancel`, clear `activeTouchId` and end dragging when the active touch ends.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Non-passive touchmove on document ✓ Resolved 🐞 Bug ➹ Performance

Description

A non-passive touchmove listener is attached to document for the lifetime of the page, so every
touchmove must synchronously run JS before the browser can scroll. Even though it returns quickly
when not dragging, this pattern can still degrade scroll responsiveness and prevents the browser’s
passive scroll optimizations.

Code

static/js/chatbot.js[R490-494]

Evidence

The code installs a document-level touchmove handler with { passive: false }; even with an early
return when not dragging, the browser must still dispatch every touchmove through this non-passive
listener.

static/js/chatbot.js[490-497]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`document.addEventListener('touchmove', ..., { passive: false })` is registered permanently. This forces the browser to treat document touchmove as potentially cancelable, impacting scroll performance.

## Issue Context
The handler returns early when `!isDragging`, but the listener still runs for all touchmove events and still disables passive optimizations.

## Fix Focus Areas
- static/js/chatbot.js[490-497]
- static/js/chatbot.js[467-473]

## Suggested fix
- Register the non-passive `touchmove` listener only after a successful drag start, and remove it in `handleEnd()`.
- Alternatively, keep a passive listener by default and swap to a non-passive listener during drag (start) only.
- Keep `touchend/touchcancel` to reliably clean up and remove the listener.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---