OTP on Safari field focus issue

[ProgrammerZ]

Flux version

v2.14.1

Livewire version

v 4.3.1

Tailwind version

v 4.3.1

Browser and Operating System

Safari 26.5, iOS 26.5

What is the problem?

Bug when focusing on OTP Input component on iOS WebKit (tested on Safari, Chrome).
The only way you can type in is to tap the OTP very fast when components loads, tap and instantly start to type, otherwise it's impossible to even select it, but even then if deselected will not be able to select it again.

Code snippets to replicate the problem

Just a standard OTP component:
<flux:otp wire:model="code" length="6" />

tried with autofocus and without and different types, same issue.

Screenshots/ screen recordings of the problem

Flux.OTP.WebKit.bug.mp4

How do you expect it to work?

It should be selectable and editable

Please confirm (incomplete submissions will not be addressed)

• I have provided easy and step-by-step instructions to reproduce the bug.
• I have provided code samples as text and NOT images.
• I understand my bug report will be closed if I haven't met the criteria above.

[ProgrammerZ]

Several updates.
I have used the flux:otp inside the blade component for reusability, extracting it helped with the bug for some reason, but only partially, now the OTP code field accepts focus and shows the keyboard the first time it's focuses after appearing, but fails on second or third subsequent focus. If tapped not on the first item also does not focus. I have not found the cause of this inconsistency.

Also this solves the focus issues, but breaks the functionality, I believe the bug is something to do with blur() and focus() on iOS

x-data
x-on:pointerdown.capture="window.matchMedia('(pointer: coarse)').matches && $event.stopImmediatePropagation()"

[andyNuu]

We have the same issue and had to create our own OTP component. We are launching soon and would like to use the Flux version. Any update for this coming?

[joshhanley]

@ProgrammerZ and @andyNuu thanks for reporting! I don't have an iOS 26 device to test on at the moment, so planning to upgrade my phone soon, then will investigate this. @andyNuu can you confirm what Flux and Livewire versions and OS and browser you are using?

[andyNuu]

@joshhanley Thanks for getting back to us!
Flux version is 2.14.1
Livewire version is 4.2.4
When we tested the issue we had an iPhone 16 and an iPhone 17 Pro and both used Safari for the browser. I do not know what the OS version was.

[joshhanley]

@andyNuu thanks for that! Any chance you can find out? We've had this issue reported before, but we weren't able to replicate it. So narrowing down which iOS versions specifically would really help. No worries if don't have those devices available any more!

[andyNuu]

@joshhanley Sorry, we are all remote so it took a bit to get the versions. Both iPhones are on 26.5.1.

[joshhanley]

@andyNuu no worries! Thanks for following up. Yep looks like it's probably an iOS 26 issue. Will upgrade my phone and tested it out. Thanks again!

[calebporzio]

Big thanks @ProgrammerZ — your pointerdown.capture + stopImmediatePropagation finding was the clue that cracked this.

The OTP component handles pointerdown by programmatically focusing the right input and calling preventDefault(). On iOS 26, preventing the default on a touch pointerdown cancels the tap's native focus, and the programmatic focus() inside pointerdown doesn't survive the gesture — so the inputs end up unfocusable. That's exactly why killing the handler restored focus for you (while breaking the focus-redirect behavior it existed for).

I've reworked it so touch taps focus natively (the path iOS is happy with), and the focus-redirect/selection logic now runs on click instead — which also fixed a related bug where typing over an already-filled box on a touch device could wipe the whole code.

One honest caveat: I verified everything against WebKit 26.5 via Playwright (desktop + iPhone touch emulation) and the full test suite, but the original failure lives in iOS's keyboard/focus policy layer, which desktop WebKit doesn't exercise — that's why @joshhanley couldn't repro it either. So once this ships in the next release, I'd love it if you or @andyNuu could confirm on a real iOS 26 device.