1949358 - m.buycarparts.co.uk - Unable to fill in the postcode correctly

Status: NEW

(Web Compatibility :: Site Reports, defect, P1)

Description

[railioaie]

Environment:
Operating system: Android 14
Firefox version: Firefox Mobile 127.0

Preconditions:
Clean profile

Steps to reproduce:

1. Navigate to: https://m.buycarparts.co.uk/basket/address
2. Complete the fields with the delivery address details
3. Observe

Expected Behavior:
All the fields are filled correctly

Actual Behavior:
The postcode field is unable to be filled in correctly

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/148586

Comment 1

[railioaie]

Attachment: 20.02.2025_08.28.27_REC.mp4

Comment 2

[Sean Feng [:sefeng211]]

Attachment: extra event handler

(removed)

Comment 3

[Sean Feng [:sefeng211]]

By comparing the execution between Firefox and Chrome, I see the following jQuery code executes differently.

while ((i = a[t++]) && !u.isPropagationStopped()) {
  u.currentTarget = i.elem,
  n = 0;
  while ((o = i.handlers[n++]) && !u.isImmediatePropagationStopped())
    u.rnamespace &&
    !1 !== o.namespace &&
    !u.rnamespace.test(o.namespace) ||
    (
      u.handleObj = o,
      u.data = o.data,
      void 0 !== (r = ((S.event.special[o.origType] || {}).handle || o.handler).apply(i.elem, s)) &&
      !1 === (u.result = r) &&
      (u.preventDefault(), u.stopPropagation())
    )
}

i.handlers is the event handlers for keydown events for this <input> element, it was only one event handler in Chrome, but two event handlers in Firefox.

The attachment, extra event handler is the extra handler that gets to run in Firefox. Though I think this is still probably fine because it has this code:
return p.ignorable = d.ignorables.includes(k), f.keypressEvent.call(this, e, t, i, c, u)

ignorables contains KEY_229, which matches the keydown event that we dispatch. However the site doesn't seem to do the comparison correctly, so the "keydown" event isn't ignored.

Eventually, the site just renders whatever the "event.key" value is. I think this depends on IME, it could be "Process" which matches the screen recording in comment 1.

Overall, this looks like a site-bug.