Repository navigation
Conversation
This was referenced Sep 27, 2026
Closed
Switch the mobile platform and the example from Zed git dependencies to the matching `gpui-pre` / `gpui-pre-wgpu` 0.3.4 crates.io packages (imported as `gpui` / `gpui_wgpu`, so no `use` changes are needed). This removes the `[patch.crates-io]` async-task fork and every git dependency, which makes the crate publishable to crates.io and lets consumers depend on it without reproducing Zed's patches. Adapt to the platform and styling API differences, fix the "wpgu" typo in the crate description, and update the publish workflow to check the iOS backends before publishing and to treat the `dry-run` input as the boolean it is. Test plan: - cargo check --all-targets - cargo check --target aarch64-apple-ios / aarch64-apple-ios-sim - cargo test --lib
Embed GPUI Kit's Markdown TextView in a Swift-owned UIKit window instead of letting GPUI create the iOS example's window. A child controller renders into `GPUITextView: UIView`; native Compact / Expanded controls exercise layout changes. The light English sample puts emphasis, quotes, nested lists, code, tables, and tasks on the first screen. Fix two startup failures exposed by the simulator: supply the UIKit display handle to wgpu 29, and retain the `run_embedded` application handle so native callbacks cannot outlive the GPUI app. Synchronize layout and redraw without implicit animations during size changes. Correct the Xcode static-library paths and build directory. Pins GPUI Kit to commit `7d9efcd2069f9eaa6eb3ba6345aac4aa7d87c9f7` from longbridge/gpui-kit#3045, so a sibling local checkout is not required. No crates are published. The embedding example supports one GPUI view for the application lifetime; independent destruction and multiple instances are not implemented. - Passed `cargo check --manifest-path example/Cargo.toml --target aarch64-apple-ios-sim` with the pinned Git dependency. - Built the Swift app with Xcode for the iOS simulator and ran it on iPhone 17 Pro / iOS 26.5 using the same GPUI Kit source revision locally. - Verified light Markdown rendering, native controls, and Compact / Expanded resizing. - Passed `git diff --check` and `bash -n example/build.sh`. - Embedded scrolling needs manual verification: the automation tool emitted touch begin/end without move events. Transient resize jitter also needs visual confirmation. - No Android, physical-device, or performance testing performed. --------- Co-authored-by: Codex <codex@openai.com>
A released iOS touch currently leaves GPUI's synthetic mouse over the last control, keeping hover feedback active. Clear the pointer hit test and emit MouseExited after touch end/cancellation and momentum frames, while preserving the original position for click and scroll dispatch. Handle UIKit cancellation separately so it never commits a deferred tap or starts a momentum fling. Cancel an active scroll with TouchPhase::Cancelled. Update the example's GPUI Kit revision to include mobile tooltip suppression, tap-triggered HoverCard behavior, and the inline is_mobile helper from longbridge/gpui-kit#3045. - Built the Swift-hosted iOS example for aarch64-apple-ios-sim. - Used a temporary simulator smoke view to check HoverCard opens on tap, remains open when its content is tapped, and closes on outside tap. - Checked a normal ghost button with a configured tooltip: no lingering hover background or tooltip after release. - Restored the original chat example and rebuilt it with the final Kit revision. - GPUI Kit regression tests cover desktop hover and mobile tap interaction. - UIKit cancellation was reviewed in code; no system-cancellation gesture was injected. Android was not changed or tested. No crates published. Co-authored-by: Codex <codex@openai.com>
## Summary Apply the iOS touch cleanup from #3 to Android. After touch release/cancellation and every momentum frame, move the synthetic pointer outside the window and emit MouseExited so hover does not remain on the last control. Preserve original coordinates for click and scroll dispatch. Handle ACTION_CANCEL independently: discard queued coalesced scroll, reset velocity, stop inertia, and emit ScrollWheel(Cancelled) for an active scroll. Never turn cancellation into a tap or fling, and ignore stray moves with no active touch. Add regression tests and update an existing test to use the renamed gpu_specs API. ## Test Plan - Android arm64/API 31 cargo-ndk library check passed. - Built the Android unit-test executable and ran touch tests on an Android API 34 arm64 emulator: 5 passed. - Tests cover tap coordinates, pending-tap cancellation, coalesced-scroll cancellation, and post-momentum hover cleanup. - This verification covers platform event dispatch; Android app UI testing is ongoing separately. Co-authored-by: Codex <codex@openai.com>
iOS and Android Chinese keyboards could not reliably compose text, Add files returned an error or no result, and converting every drag to scroll prevented controls from claiming touch gestures. - Use a native UITextView composition buffer to provide UITextInput support and forward plain and attributed marked text, UTF-16 selection, commits, and deletion to GPUI. - Present an asynchronous UIDocumentPicker, returning sandbox copies of selected files (including images in Files), with multi-selection and cancellation support. - Forward UIKit contacts as GPUI TouchEvents with stable IDs. GPUI's existing recognizer handles taps, long presses, control drags, scrolling, and inertia, replacing the duplicate iOS mouse/scroll synthesis. - Add an Android InputConnection bridge with native-thread composition delivery, UTF-16 selection, Unicode-safe deletion, and session checks for stale callbacks. Keep legacy TextInput commit/backspace callbacks working. Custom hosts use GpuiInputActivity; the example inherits it. - Connect Android file prompts to SAF and copy content URIs into app cache on a worker before returning readable paths. Register the picker Activity in the example. - Forward Android contacts as TouchEvents, preserve multiple pointer identities, and distinguish cancellation from release. Remove duplicate mouse/momentum synthesis, desktop Fontconfig loading on Android, and unconditional frame presentation (matching the existing ai-chat host workarounds). - Fix two simulator Debug crashes: UIKit dynamically forwards public keyboard trait setters, and NSString byte initializers require `const void *` rather than byte-pointer encoding. Correct the matching URL/maps initializer calls too. This uses existing GPUI 0.3.4 APIs; no GPUI core changes. TextView selection and scrollbar thumb dragging also require the companion gpui-kit handlers. The file pickers accept images accessible through Files/Documents; they do not add a separate Photos library entry point. Touch-driven focus changes finish the current composition before dispatch. On iOS, programmatic focus switches without a touch or keyboard hide still need a platform focus identity signal; clearing the previous GPUI field's marked state on programmatic blur remains a follow-up. - Passed: `cargo check --target aarch64-apple-ios --lib --offline --no-default-features --features camera,video_player`. - Passed: `cargo check --target aarch64-apple-ios-sim --lib --offline --no-default-features --features camera,video_player`. - Passed: Android backend library/test cross-compilation with NDK 27, and the complete ai-chat Android host's `cargo ndk -t arm64-v8a --platform 26 check --locked --offline` using these local changes. - Passed: Android API 34 Java compilation, including the host's `:app:compileDebugJavaWithJavac` task. - Passed: 2 host-run regression tests for the actual Unicode deletion and legacy callback helpers; Android touch regression tests compile but were not run on a device. - Passed: Rust formatting and `git diff --check`. - Passed on iOS 26.5 simulator Debug: input focus and English input; software Pinyin `ni` followed by selecting `你` inserts Chinese into the GPUI input; explicit keyboard dismissal; Files picker opens and cancels twice without crashing or reopening the keyboard. - Passed: native objc2 Debug probe reproduces the old NSString signature rejection and verifies corrected English, Chinese/emoji, Chinese URL and empty-string roundtrips. Keyboard-trait forwarding was also checked against this UIKit runtime. - Passed: attributed-marked-text runtime probe reaches the override once, preserves ni composition and UTF-16 selection, then commits Chinese. Requester confirmed Chinese input and subsequent iOS/Android device testing complete. - Passed: full ai-chat Android Debug and optimized Release builds, installation and startup on Samsung Android 12 ARM64; Release package verified non-debuggable. - Not addressed by a dedicated fix: the reported held-key repeat case (discrete 256 insert/delete callbacks pass), or the separately identified insertText:alternatives:style: entry point. No system autorepeat validation is claimed by those discrete-callback tests. --------- Co-authored-by: Codex <codex@openai.com>
## Description The iOS window implemented neither `PlatformWindow::frame_waker` nor `schedule_frame`, so a host had to tick GPUI on every vsync and let it discover there was nothing to draw — ~2% of a core at 60 Hz (4% at 120 Hz) on an idle screen. `IosWindow` now carries a `FrameDemand` (new platform-neutral module, unit-tested) shared with the FFI layer: - `frame_waker` / `schedule_frame` raise demand and call a host-registered waker on the first demand since the last tick. - `gpui_ios_request_frame` clears demand before the frame and returns whether GPUI wants another (demand re-raised mid-frame, or text input waiting). - New `gpui_ios_set_frame_waker(window, waker, context)` registers the host callback. - Software-keyboard text and keyboard-height changes go through `mark_text_input_dirty()`, which also wakes every window. A host pauses its `CADisplayLink` when `gpui_ios_request_frame` returns `false` and resumes it from the waker (`example/ios/main.m`). Hosts that tick unconditionally keep working. Measured on the Longbridge AI chat (iPhone 17 Pro simulator, Release): idle CPU 2% → 0.0%; scrolling, fling, focus and caret unchanged. ## Breaking Changes - `gpui_ios_request_frame` now returns `bool` instead of `void`. Update the header your host compiles against; Swift callers must consume the result. ```diff - void gpui_ios_request_frame(void *window_ptr); + bool gpui_ios_request_frame(void *window_ptr); ``` ```diff - gpui_ios_request_frame(window) + _ = gpui_ios_request_frame(window) ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Codex <codex@openai.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
## Description Holding Backspace on the iOS software keyboard deleted exactly one character; Android keeps deleting while the key is held. UIKit drives the repeat from a timer, `-[_UIKeyboardStateManager handleAutoDeleteWithExecutionContext:]`, which asks the first responder `_selectionAtDocumentStart` before every repeat and calls `_stopAutoDeleteAtDocumentStart` (releases the key, clears the timer) the moment the answer is YES. `-[UIResponder(UITextInput_Internal) _selectionAtDocumentStart]` compares `selectedTextRange.start` with `beginningOfDocument`. `GPUITextInputView` is a `UITextView` whose document only holds the current composition and is empty between keystrokes, so the caret always sat at the document start and the timer gave up after the first delete. The existing `hasText` → YES override does not help: UIKit only consults `hasText` for the first delete (`canHandleDelete` → `noContent`), never for the repeat. (All of the above verified by disassembling UIKitCore from the iOS 26.5 simulator runtime.) The fix overrides `_selectionAtDocumentStart` on `GPUITextInputView` to answer for the GPUI document whenever the scratch document has nothing UIKit could delete natively: - with a `PlatformInputHandler` installed (gpui-component `Input`), `selected_text_range().range.start == 0` decides, so the repeat still stops once the field is empty; - with only a legacy `set_text_input_callback` (which cannot report its content) the repeat keeps going; each extra Backspace on an empty field is a no-op there; - while a composition lives in the native view (marked text or non-empty scratch document) `UITextView`'s own answer stands, so IME behaviour is unchanged. The selector is private UIKit; `objc2`'s `sel!` registers it at runtime from a plain C string, so it does not appear in `__objc_selrefs`. Hardware keyboards are not affected either way: their repeats arrive as key events that go through `handleDeleteAsRepeat:` directly, without the timer. ## How to Test 1. Build the example (or any consumer) for a device or simulator with the software keyboard shown (Simulator: I/O › Keyboard › Toggle Software Keyboard, ⌘K). 2. Focus a text input, type a few words, then press and hold the keyboard's Backspace key. 3. Before: one character is removed and the key releases. After: characters keep deleting while held (UIKit switches to faster deletion after ~20 repeats), and the repeat stops once the field is empty. 4. Type with a Chinese/Japanese IME and delete inside the composition: unchanged. Checks run: `cargo check --target aarch64-apple-ios-sim --no-default-features --features camera,video_player`, `cargo check --target aarch64-apple-ios`, `cargo check --all-targets`, `cargo fmt --all -- --check`, clippy on the iOS target; the ai-chat iOS example built against this branch launches on the iOS 26.5 simulator. The held-key behaviour itself still needs a device (the simulator here is headless, so no touch could be injected). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01HY6KNBpkTcKkW2PpjrFhji Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
## Summary Recreating an Activity in-process left a black screen: `android_main` runs each Activity on a fresh native thread, but `AndroidDispatcher` had captured the old thread's `ALooper`, so `App::new_app` hit `assert!(is_main_thread())`. This adds `android::host`, an additive entry point where the host owns a plain `Activity` + `SurfaceView` and GPUI runs on one process-lived render thread. `host::start(|cx| ..)` builds the app with `run_embedded` and keeps it alive; the host registers each Activity with `jni::set_host_activity`, hands surfaces over via `surface_created` / `surface_destroyed`, and forwards input through `motion_event` / `key` / `ime_event`. The `android-activity` path is untouched. `window.rs` fixes needed to keep one `App` across surfaces: force a full repaint after a surface swap, notify GPUI when a re-attached surface has a new size, and rebuild the surface in place when the same `ANativeWindow` comes back. Tested on Huawei P40 and an API 35 emulator: 40+ recreations, no black screen. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: 涂阳川 <yangchuan.tu@longbridge-inc.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Jason Lee <huacnlee@gmail.com>
## Description Both Android loops (`jni::run_event_loop` over android-activity and the `host` render thread) ticked GPUI on every iteration and paced themselves with a 500 µs / 8 ms sleep, leaving the frame rate to the swapchain. With `Mailbox` presentation a scrolling window was drawn as fast as the CPU could lay it out, most of those frames were dropped by the compositor, and an idle window still woke up 2000 times a second. This is the Android counterpart of #8. The loops now draw only when GPUI asked for a frame **and** a vsync has passed since: - **`frame_pacer`** (platform-neutral, unit-tested) folds demand into one pending frame: the first demand since the last frame posts a vsync callback, the callback marks a frame due, the loop draws it once. Demand that arrives an interval or more after the last frame began (the loop is behind, or was idle) is due at once — waiting for the next vsync there only delays the frame and the input batched behind it, and GPUI stamps touches at dispatch time (a gap over 40 ms between samples kills a fling). - **`android::frame_source`** runs `AChoreographer` on its own `gpui-vsync` thread and wakes the loop's `ALooper` on each frame callback. It cannot live on the loop's looper: android-activity logs every looper source it did not register as `Spurious ALOOPER_POLL_CALLBACK`, once per delivery (60 lines/s while scrolling). - `AndroidPlatformWindow` implements `frame_waker` / `schedule_frame`; a surface swap and a resume re-post the callback (one posted before the app went to the background may never fire); software-keyboard text wakes the loop from the UI thread. - The loops block on the looper between events. `AndroidDispatcher` exposes the next delayed task's due time and wakes the looper when a delayed task is posted, so GPUI timers keep firing without a spin. A 1 s cap bounds any missed wakeup. Hosts need no changes: both entry points install the pacer themselves. ## Measurements API 34 emulator (lavapipe), gpui-mobile example, Release Rust: | | main | this PR | |---|---|---| | idle CPU | spin (500 µs sleep) | 0.0 %, 5 loop iterations / 5 s | | backgrounded | spin | asleep (heartbeat every 1 s) | | scripted swipe → fling | 0 / 8 | 4 / 8 | | `Spurious ALOOPER_POLL_CALLBACK` while scrolling | – | none from frames (only the pre-existing dispatcher pipe ones) | The fling row is the emulator's 40 ms frames sitting on GPUI's 40 ms stopped-gap threshold either way; a phone with ≤ 16 ms frames is not affected. The real test is the Huawei P40 that showed the scroll jank this is for — please measure there before merging. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
## Problem When the keyboard appears (or on any other UIKit-animated bounds change — split view, rotation), the whole GPUI view visibly deforms for the length of the animation: text and controls grow ~15 % taller frame by frame, then snap back. UIKit animates the view's bounds, but `viewDidLayoutSubviews` reports only the final size, so `handle_layout_change` reconfigures the drawable and GPUI renders at the final size immediately, while Core Animation is still interpolating the presented bounds. The `CAMetalLayer`'s default `contentsGravity` is `resize`, which stretches that last drawable to every intermediate size. ## Fix Set the layer's `contentsGravity` to `kCAGravityBottomLeft` when the Metal view is created — Core Animation's y-up name for the visual top-left of a UIKit view (`kCAGravityTopLeft` pins to the visual bottom, verified). The drawable keeps its true scale pinned to the top-left; the strip the animation has not reached yet stays blank behind the keyboard. ## Verification iPhone 17 Pro simulator, Longbridge AI chat, screen recording of the keyboard-show animation frame by frame: before — the content stretched over ~10 frames; after — no deformation, the composer moves straight to its final position and the keyboard slides up under it. `cargo check --target aarch64-apple-ios-sim` clean. Follow-up (not in this PR): to have the composer glide with the keyboard instead of jumping, the host would lay GPUI out at the layer's presentation bounds on each display-link tick during the animation. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
…Source Two gaps a host app hits on the `android::host` path. Both are Android-only: everything here lives under `src/android/`, which `lib.rs` gates behind `#[cfg(target_os = "android")]`, so iOS does not compile it. Verified by building the crate for `aarch64-apple-ios` with these changes applied. ## Flings used iOS physics `AndroidPlatform` never implemented `Platform::gestures`, so GPUI fell back to `GestureTuning::default()` — whose `scroll_physics` is `UIScrollView`'s exponential decay. Every Android app built on gpui-mobile has therefore been flinging with iOS physics: the content coasts much further than the platform's own scroll views, which reads as the list not stopping where you expect. This returns `ScrollPhysics::android()` instead, the AOSP `OverScroller` friction spline that already lives in `gestures.rs`. GPUI flings in logical pixels and a window's scale factor is Android's display density, so logical pixels are density-independent pixels and the constructor's nominal 160 dpi pairing is the right one. Measured on a Huawei P40 (1080x2340 @3x), same conversation and gesture script, counting frames for 2.5s after release: | fling | iOS physics | Android physics | |---|---|---| | swipe 80ms | 71 frames | 58 frames | | swipe 300ms | 60 frames | 41 frames | Fewer frames because the spline sheds speed faster and the fling travels a shorter distance — the point of the change, not a regression. Frame pacing is unchanged: 16ms intervals throughout, `droppedFrames = 0` in both. The rest of `ViewConfiguration` (touch slop, tap timeouts) stays on GPUI's defaults; reading the real values over JNI is a separate change. ## A host could not install an asset source `host::start` hands the launch closure a `&mut App`, which is one step too late to install an asset source: `Application::with_assets` consumes the builder, and the builder is created inside `on_surface_created` where the host cannot reach it. The failure is silent. `AssetSource::load` returning `None` is a valid answer, so nothing logs and anything resolved through the asset source — icons, SVGs — simply does not appear. `start_with_assets` stores the configuration step in a static that `on_surface_created` consumes when it builds the `Application`, right before `run_embedded`. `start` keeps its current shape for hosts that do not need one. ## Testing - Huawei P40, `android::host` path, release build: flings and scrolling as above, no panics, `droppedFrames`/`lateAcquireFrames` both 0. - `cargo check --target aarch64-linux-android` and `cargo check --target aarch64-apple-ios` both clean. Co-authored-by: 涂阳川 <yangchuan.tu@longbridge-inc.com>
## Problem GPUI's touch recognizer (gpui-pre 0.3.5) treats a contact that lands during scroll momentum as a pan from its first pixel — and locks it to **the axis of the fling it stopped**. A quick sideways swipe (across a wide table, or just across text: momentum starts on any fast release) followed by a swipe up produced only horizontal deltas, so the page looked frozen until the finger lifted. Reproduced on an iPhone 17 Pro in the AI chat. The same catch also swallows control drags: a contact that catches a fling is never offered as a touch drag (the recognizer enters `Panning` straight from `Started`; only a pending contact is offered). A scrollbar thumb is visible only while its content scrolls and coasts, so in practice it could not be grabbed until an earlier touch had stopped the coasting — which read as needing a long press on the thumb. The fix belongs in the recognizer (zed-industries/zed#64239 for the axis; offering a drag to a catching contact is a second upstream gap); this is what the platform can do until that reaches a gpui-pre release. ## Change `src/fling_guard.rs`, relayed through on both platforms (`handle_touch` on iOS, the `on_touch` bridge on Android): - The recognizer takes its momentum on **every** `Started`, and a contact that is cancelled while still pending emits nothing. So before a real contact that may land on momentum, the guard relays a synthetic contact that begins and is cancelled at the same point: it stops the momentum (a zero-delta `Started`/`Cancelled` scroll pair the consumers treat as a no-op), and the real contact then begins on an idle recognizer, which offers it as a drag and otherwise lets it pick its own axis at the slop. - Momentum is not visible from the platform, so the guard estimates it: it runs for any contact that begins within 4 s (longer than any fling either physics runs) of a release that had panned past the slop. When no momentum is left, the synthetic pair is a no-op. - Synthetic contact IDs come from the same sequence as the real ones. What the guard cannot restore is the catching contact's no-tap rule: a contact that stops a fling and lifts without moving is an ordinary tap here. ## Test 5 host-side unit tests on `FlingGuard` (armed after a pan release, once per release, not after the window, not after a tap, not after a cancelled pan), plus one end-to-end test that drives GPUI's real recognizer (`gpui-pre` `test-support`, dev-dependency only) through the guard against an element that claims touch drags in a strip along the right edge, the way a scrollbar thumb does: after a swipe with velocity, an unguarded contact on the thumb is swallowed by the fling, a guarded one is claimed as a drag. `cargo check --target aarch64-apple-ios` and `cargo ndk -t arm64-v8a check` both build. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
## Problem The iOS FFI window list (`IOS_WINDOW_LIST`) is append-only: `register_window` pushes on creation but nothing removes entries, and `IosWindow` has no `Drop`. That is fine for a single permanent window, but a **multi-window host that opens/closes windows at runtime** leaves dangling raw pointers in the list. This bites in two places: - `gpui_ios_get_window` returns `windows.last()` — can hand back a freed window. - The app-lifecycle handlers (`gpui_ios_did_become_active`, `gpui_ios_did_enter_background`, `gpui_ios_will_enter_foreground`, `gpui_ios_will_resign_active`) **iterate the list and dereference every entry**. The `!is_null()` guard does not catch freed non-null pointers → use-after-free / crash on the next background/foreground after any window closes. ## Fix - Add `ffi::deregister_window` (retain-out the pointer). - Add `impl Drop for IosWindow` that deregisters itself. The pointer matches the one passed to `register_with_ffi` (the window lives at a stable Box address for its whole lifetime, per the existing comment there). Closing a GPUI window now cleans up the FFI list automatically — no dangling pointers. No behavior change for single-window hosts. ## Context Needed by the ai-chat iOS embed to support multiple concurrent AI chat panels (each its own GPUI window); closing a chat must free its window without crashing on the next lifecycle event. Co-authored-by: yuanzhuang-svg <273899003+yuanzhuang-svg@users.noreply.github.com>
huacnlee
force-pushed
the
upstream/16-deregister-ioswindow-from-the-ffi-window
branch
from
September 27, 2026 12:06
b56355b to
2ce11e6
Compare
huacnlee
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note
Stack 13/13, ported from longbridge/gpui-mobile, where each layer was reviewed and merged as its own PR.
This PR is based on #61. Cross-fork PRs can't use GitHub's stacked PRs or target another PR's branch, so this diff includes every layer below it. Please review only the top commit (2ce11e6), and merge the stack bottom-up.
Problem
The iOS FFI window list (
IOS_WINDOW_LIST) is append-only:register_windowpushes on creation but nothing removes entries, andIosWindowhas noDrop. That is fine for a single permanent window, but a multi-window host that opens/closes windows at runtime leaves dangling raw pointers in the list.This bites in two places:
gpui_ios_get_windowreturnswindows.last()— can hand back a freed window.gpui_ios_did_become_active,gpui_ios_did_enter_background,gpui_ios_will_enter_foreground,gpui_ios_will_resign_active) iterate the list and dereference every entry. The!is_null()guard does not catch freed non-null pointers → use-after-free / crash on the next background/foreground after any window closes.Fix
ffi::deregister_window(retain-out the pointer).impl Drop for IosWindowthat deregisters itself. The pointer matches the one passed toregister_with_ffi(the window lives at a stable Box address for its whole lifetime, per the existing comment there).Closing a GPUI window now cleans up the FFI list automatically — no dangling pointers. No behavior change for single-window hosts.
Context
Needed by the ai-chat iOS embed to support multiple concurrent AI chat panels (each its own GPUI window); closing a chat must free its window without crashing on the next lifecycle event.
🤖 Generated with Claude Code