Incident IQ search inputs intermittently drop leading characters from fast HID barcode scanners (confirmed across multiple vendors)

Summary of Issue

We are encountering an issue where barcode scans intermittently lose the first 1–3 characters when scanning into Incident IQ web search fields (asset search, ticket search, etc.).

This behavior occurs across multiple barcode scanner vendors and models when used with Incident IQ only. The issue is not observed in native applications or on other websites.

Environment

• Application: Incident IQ (web)
• Browsers affected:
  • Google Chrome
  • Microsoft Edge
• Browsers not affected:
  • Native Windows applications (e.g., Notepad)
• Operating System: Windows (managed device)
• Scanner types tested (with issues):
  • Netum NSL8 (2.4 GHz RF HID, no speed adjustment)
  • Tera 1D scanner (HID, no transmission speed adjustment)
  • Tera 2D scanner (HID, no transmission speed adjustment)
• Scanner types tested (no issues when configured):
  • Nadamoo scanners with adjustable transmission speed / inter‑key delay
• Input Method: USB / RF HID keyboard emulation
• Barcode Types: Standard asset barcodes (1D and 2D)

Observed Behavior

• Scanning into Incident IQ search fields intermittently removes the leading characters from the scan.
• Example:
  • Expected: A123456789
  • Actual: 3456789
• Characteristics:
  • Does not occur on every scan
  • Affects only the beginning of the scan
  • Occurs only on Incident IQ
• Using the same scanners, scanning into:
  • Notepad → 100% reliable
  • Other websites → normal behavior
• The issue began recently; these same scanners previously worked reliably with Incident IQ.

Troubleshooting Performed

We performed controlled testing to isolate the cause:

• ✅ Tested multiple scanner vendors and models
• ✅ Tested multiple Chromium browsers (Chrome & Edge)
• ✅ Verified native applications never lose characters
• ✅ Verified other websites do not exhibit this behavior
• ✅ Confirmed behavior can vary by timing and machine
• ✅ Tested Incognito mode
• ✅ Disabled user‑controllable browser extensions
• ✅ Tested scanner terminators (CR vs CR + LF)

The issue remains isolated to Incident IQ.

Conclusive Finding (Critical Evidence)

We tested multiple Nadamoo scanners that support true transmission speed / inter‑key delay adjustment.

Results

All testing was performed on the same computer, browser, and network.
The only variable changed was scanner output speed.

Root Cause Analysis (High Confidence)

This behavior is consistent with a front‑end input timing race condition in Incident IQ’s search fields.

Specifically:

• Search input values appear to be:
  • Cleared, re‑rendered, or replaced
  • During early focus, keydown, or input lifecycle events
• High‑speed HID keyboard input arrives before the field stabilizes
• Early keystrokes are intermittently dropped

Scanners that emit characters too quickly (Netum, Tera) expose this timing issue.
Scanners that insert a small inter‑key delay do not.

Steps to Reproduce

1. Open Incident IQ in Chrome or Edge
2. Click into a search field
3. Scan a barcode using a fast HID scanner (Netum or Tera)
4. Repeat across several scans

Observed: Intermittent loss of leading characters
Confirmed mitigation: Reduce scanner inter‑key transmission speed → issue disappears

Expected Behavior

Incident IQ search fields should reliably accept full barcode scans regardless of scanner speed, vendor, or model.

Request to Incident IQ Engineering

We respectfully request a front‑end engineering review of:

• Search input handling under rapid keyboard input
• Whether input values are cleared or inputs are re‑rendered during typing
• Interaction between live filtering / debounce logic and fast input
• Preserving input state during search initialization
• Deferring search execution until input completion (Enter or debounce end)

If Incident IQ has recommended scanner requirements or minimum input timing expectations, we would appreciate documentation so we can align deployments.

Impact

• Slows asset and ticket workflows
• Causes repeated scanning or manual correction
• Forces organizations to avoid certain scanner models
• Creates inconsistent user experience across environments

Additional Information Available Upon Request

• Video recordings of failed vs successful scans
• Detailed scanner models and firmware
• Exact transmission delay settings used on Nadamoo scanners
• Timing comparison data

✅ Why This Should Escalate

• Issue is reproducible
• Issue is isolated to Incident IQ
• Issue affects multiple scanner vendors
• Issue has a validated mitigation
• Root cause aligns with known front‑end input timing patterns