## QA PASSED See QA report document: a99d3d9b-9cd0-4362-abf5-e351f433c117 **Test Results:** - Test 1 (Baseline): PASS - 'n' hotkey works without input focus - Test 2 (Main bug fix): PASS - 'n' hotkey works after clicking away from search input ✓ - Test 3 (Guard clause): PASS - 'n' does not open modal while typing in input - Test 5 (Regressions): PASS - No console errors, modal closes properly **Key Findings:** The blur handler successfully resolves the issue. When a user clicks in the search input and then clicks elsewhere on the page, the input is automatically blurred, allowing the 'n' keyboard shortcut to function properly. **Evidence:** - Verified focus transitions: INPUT → BODY (after clicking away) - Confirmed modal opens after blur - Confirmed guard clause still prevents modal while typing - Screenshots saved to /tmp/TRCKR-269-*.png All hypotheses tested. No issues found. Fix verified working.

## Fix Applied - Click Handler to Blur Inputs **Problem identified:** The root cause was that clicking on non-focusable elements (like the "556 issues" div) did NOT automatically blur the focused input element. The `document.activeElement` would still be the INPUT, causing the keyboard shortcut guard at line 2042-2044 to prevent the 'n' key from triggering. **Why previous fixes didn't work:** - The previous fixes correctly implemented the `htmx.ajax()` call for the 'n' shortcut - The issue wasn't with the HTMX trigger mechanism - The issue was that the keyboard event's target was still INPUT even after clicking elsewhere **Fix applied:** Added a document-level click handler in `server/templates/base.html` (lines 1990-2010) that: 1. Checks if an INPUT, TEXTAREA, or SELECT is currently focused 2. Checks if the click was outside of any input element 3. Blurs the focused input if the click was elsewhere **Expected behavior after fix:** 1. User clicks on search input (focuses it) 2. User clicks anywhere else on the page (like "556 issues" text) 3. The search input is automatically blurred 4. User presses 'n' 5. The Create Issue modal opens **Verification:** - All 1286 tests passed - Deployed to https://trckr.roboalch.com - Ready for QA verification

## QA FAILED See QA report document: 320b9aa2-8345-4a93-9be1-60a688076f92 **Root cause identified**: The 'n' hotkey does NOT work because keyboard events are being captured by an INPUT element instead of the document body. **Key findings**: - Manual execution of `htmx.ajax()` successfully opens the modal (the code works) - Pressing 'n' when an input is focused does NOT open the modal - Pressing 'n' after blurring the focused input DOES open the modal - The keyboard event shows `target: 'INPUT'` instead of `target: 'BODY'` **Evidence**: - Screenshots saved to /tmp/TRCKR-269-*.png (6 screenshots) - Detailed hypothesis testing shows the htmx.ajax() implementation is correct - The issue is that the keyboard handler either: 1. Has a guard clause preventing shortcuts when input is focused (expected behavior) 2. Is not being registered at all 3. The event is being swallowed by the input element **Next steps**: 1. Manually test with real browser to confirm this is not just a test artifact 2. Check keyboard handler code for input/textarea guards 3. If guards exist: This might be expected UX (user must click outside input first) 4. If no guards: Add explicit check to ignore shortcuts when typing in inputs Returning to todo for further investigation and fixes.

## Fix Applied - htmx.ajax() instead of .click() **Problem identified:** The previous fix attempted to use `newButton.click()` to programmatically trigger the HTMX request when pressing 'n'. However, HTMX may not process programmatic click events in the same way it processes native user interactions. The `.click()` method fires a click event, but HTMX's event handlers may not be triggered reliably for programmatic clicks. **Fix applied:** Changed the approach in `server/templates/base.html` (lines 2064-2073) to use HTMX's JavaScript API directly: ```javascript const newButton = document.querySelector('.toolbar .btn-primary'); if (newButton) { // Use htmx.ajax() to programmatically trigger the HTMX request // This is more reliable than .click() which may not trigger HTMX handlers const url = newButton.getAttribute('hx-get') || newButton.getAttribute('hx-post'); const target = newButton.getAttribute('hx-target') || '#modal-container'; const swap = newButton.getAttribute('hx-swap') || 'innerHTML'; if (url) { htmx.ajax('GET', url, {target: target, swap: swap}); } } ``` Instead of simulating a click, we now: 1. Read the HTMX attributes from the button (hx-get, hx-target, hx-swap) 2. Call `htmx.ajax()` directly to issue the request 3. This ensures the request goes through HTMX's proper request handling **Verification:** - All 1325 tests passed - Deployed to https://trckr.roboalch.com - Ready for QA verification

## QA FAILED See QA report document: a9c61579-356d-4973-a10c-8c2e4f0fa93a **Issues found:** - The 'n' hotkey does NOT open the Create Issue modal - After pressing 'n', the page remains on the issues list (no modal appears) - No JavaScript errors in console related to keyboard handling - The fix (changing from `htmx.trigger()` to `.click()`) is not working **Evidence:** - Screenshot: /tmp/TRCKR-165-after-n-key.png **Recommended investigation:** 1. Verify the selector `.toolbar .btn-primary` finds the correct button 2. Add console logging to confirm keyboard event fires and button click is attempted 3. Verify HTMX attributes on the button are correct 4. Test manual button click to ensure it works before automation Returning to todo for fixes.

## Fix Applied **Problem identified:** In `server/templates/base.html` at line 2063, the keyboard shortcut handler was using: ```javascript htmx.trigger(newButton, 'click'); ``` The `htmx.trigger()` function fires a custom DOM event, but HTMX responds to native DOM events triggered by actual user interaction or the native `.click()` method. Using `htmx.trigger()` with 'click' as the event name creates a custom event that HTMX doesn't recognize for triggering its request handlers. **Fix applied:** Changed the handler to use native `.click()` method: ```javascript // Don't open new item modal if one is already open if (isModalOpen) { return; } e.preventDefault(); const newButton = document.querySelector('.toolbar .btn-primary'); if (newButton) { // Use native click() to trigger HTMX request newButton.click(); } ``` **Changes:** 1. Use `newButton.click()` instead of `htmx.trigger(newButton, 'click')` - the native click method properly triggers the HTMX request handling 2. Added guard to prevent opening new item modal when one is already open **Verification:** - All 1325 tests passed - Deployed to https://trckr.roboalch.com - Ready for QA verification

## QA Verification FAILED **Test performed:** 2025-12-16 ### Steps Executed: 1. Navigated to https://trckr.roboalch.com/web/issues 2. Clicked on non-input element ('556 issues' text) to ensure no input was focused 3. Pressed the 'n' key 4. Verified result by taking page snapshot ### Result: FAILED The modal did NOT open. After pressing 'n', the page snapshot showed the same issues list with no modal visible. ### Console Check: - No JavaScript errors directly related to the keyboard handler - Found general warnings (Tailwind CDN warning, form field ID warnings) - Found one 404 error for an unrelated resource ### Previous Fix Applied: Changed selector in base.html line 1881 from: ```javascript const newButton = document.querySelector('.btn-primary'); ``` to: ```javascript const newButton = document.querySelector('.toolbar .btn-primary'); ``` This fix did NOT resolve the issue. The keyboard shortcut is still not triggering the modal. ### Evidence: Screenshot saved to /tmp/TRCKR-269-after-n-key.png ### Recommendation: Debug the keyboard event handler to determine why the 'n' key is not triggering the modal. Possible causes: 1. The selector still not finding the correct button 2. Event listener not being registered 3. Modal trigger mechanism not working as expected

Fixed the 'n' hotkey issue. **Problem found:** In /tmp/trckr-TRCKR-269/server/templates/base.html line 1881, the keyboard shortcut handler was using `document.querySelector('.btn-primary')` which returns the FIRST matching element on the page. After TRCKR-266 added the project sidebar, the issues page now has TWO .btn-primary buttons: 1. Line 50 in issues.html: A button in the bulk action toolbar (hidden by default) 2. Line 56 in issues.html: The actual 'New Issue' button in the main toolbar The selector was matching the bulk action button first, which doesn't have the HTMX attributes needed to open the issue creation modal. **Fix applied:** Changed line 1881 from: `const newButton = document.querySelector('.btn-primary');` To: `const newButton = document.querySelector('.toolbar .btn-primary');` This makes the selector more specific, targeting only buttons inside the .toolbar element, which correctly finds the New Issue button on all pages. **Verification:** - All 1165 tests passed - Deployed to trckr.roboalch.com - Will verify with chrome-devtools next