Summary
On iPadOS 27.0 (build 24A435), MobileSafari crashes with SIGABRT the first time the software keyboard is brought up by focusing a form field inside a web page. It happens on any website that has a text input: we reproduced it on our own web app, amazon.co.jp, Yahoo! Mail, Gmail, Rakuten, X, and two Japanese public-sector sites. No login is required to reproduce.
Environment
- Devices: iPad mini (A17 Pro / iPad16,2) x2, plus a third iPad (reproduced on 3 devices)
- OS: iPadOS 27.0 build 24A435 — both the public beta and the RC build (releaseType "User"). Also reproduces after a full erase + clean install, so it is not device-state related.
- NOT reproducible on: iPhone (iOS 27, same build 24A435), Chrome on the same iPads, or the Xcode 27 Simulator.
Steps to reproduce (no login required)
- Launch Safari and open any page with a login form (e.g. the amazon.co.jp sign-in page).
- Without logging in, kill Safari from the app switcher (or background it and go to the Home Screen).
- Launch Safari again; the same page is shown.
- Tap any text field (ID / email / password) to focus it.
- Safari crashes immediately.
The essential condition appears to be: the FIRST keyboard activation in a freshly launched MobileSafari process is driven by focusing a form field inside WKWebView. If the keyboard has already been built once in that process (see Workaround below), the crash never happens.
Crash details
We collected five .ips crash reports from three devices and two unrelated websites (our web app and amazon.co.jp). lastExceptionBacktrace is identical across all five, down to the instruction offsets, so page content is not a factor. Key frames:
- The exception is thrown by NSISEngine (CoreAutoLayout) while -[TUIKeyplaneView prepareForSplitTransition] removes layout constraints in an inconsistent state (this split-keyplane path is iPad-only, which explains why iPhone is unaffected).
- The re-entrancy: Safari's AutoFill metadata round trip (WBSAutoFillJavaScriptInjectionController -> _SFFormAutoFillController beforeStartInputSession: -> TabDocument _beginAutomaticPasswordInteraction:) calls -[UIResponder reloadInputViews] from -[WKContentView _continueElementDidFocus:requiresStrongPasswordAssistance:] while -[UIKeyboard activate] is still on the stack.
- In all five reports, a com.apple.root.utility-qos thread is blocked in DISPATCH_WAIT_FOR_QUEUE doing dispatch_sync onto the main queue from -[UITextChecker initGlobalsWithAsynchronousLoading:] (a once-per-process initialization). Four of the five crashes occurred 1–6 seconds after process launch.
- After the crash, Safari itself sometimes fails to launch until you do Settings > Safari > Clear History and Website Data.
Already ruled out (all verified on device)
- Settings > Passwords > AutoFill turned OFF: still crashes
- Split keyboard setting turned OFF: still crashes
- Full device reset + clean install of the RC build: still crashes
- Site-side causes: reproduces on completely unrelated sites; the crash fires before any login/auth JavaScript runs, and no page code appears in the stack
Workaround (reliable, verified)
Focus Safari's own address bar FIRST, so the keyboard is constructed through a native text field without the asynchronous AutoFill round trip. After that, focusing web form fields works normally for the lifetime of the process. This workaround is unavailable in SFSafariViewController / in-app browsers, where the crash also reproduces.
Questions
- Can anyone else reproduce this on iPadOS 27.0 (24A435)? Confirmations/boosts appreciated — we want to know how widespread this is before the public rollout.
- Is there any site-side mitigation (markup, autocomplete attributes, JS) that prevents Safari's AutoFill round trip from re-entering keyboard construction? Standard autocomplete attributes did not help in our tests.
- Is this a known regression being tracked for an iPadOS 27.x update?
- Is there any mitigation for SFSafariViewController-based in-app browsers, where the address-bar workaround cannot be used?
Filed via Feedback Assistant: FBxxxxxxxx (five .ips crash reports attached there).