fix(ios): keep the dependency fetch running when the editor is covered

[jkmassel]

Stacked on #637. Independent of the media-handler teardown work in #649 — either can land first.

Summary

• viewDidDisappear cancelled the async dependency fetch. It fires when the editor is merely covered, not only when it is torn down.
• The fetch has one starting point — the "no dependencies" branch of viewDidLoad — and no restart path, so that cancellation was terminal.
• Deletes the override and the dependencyTaskHandle it existed to hold. deinit is unchanged.

Why?

Present a full-screen modal over a still-loading editor — or push another controller onto the navigation stack above it — and the load is over. Measured in the iOS Simulator against the unfixed code, with the dependency fetch parked mid-flight and viewDidDisappear delivered:

	before viewDidDisappear	after
editor.view.subviews	["GBWebView", "UIEditorProgressView"]	["GBWebView", "_UIHostingView<AnyView>"]
didFailToLoad	—	cancellation error
editorDidLoad	not called	not called
webView.alpha	0.0	0.0

The progress view is swapped for the load-error screen and the host is told didFailToLoad. Returning to the editor does nothing — the symptom is a permanent error screen rather than a hung spinner, but either way the editor never loads again.

Note the qualifier. UIKit delivers this pair when the editor's view leaves the window. .pageSheet, .formSheet, .popover and the .over* styles keep the presenter's view in place and never delivered it, so this editor's own block inserter was never a trigger. The incident that produced the fast path's fix was a full-screen modal; the async path never got the same treatment.

What We Explored

1. Stop cancelling ✅

Consistent with the fast path's reasoning. The fetch is short and self-limiting, so there is nothing to reclaim by aborting it early.

2. Cancel, but restart on re-appearance ❌

Preserves the original intent — don't burn network on an off-screen editor — at the cost of a restart path that has to be idempotent and must not race a fetch already in flight. viewDidAppear fires on every uncovering, not just the one after a cancellation. That complexity has nothing to buy here.

3. Move the cancellation to deinit ❌

The obvious replacement, and it does not work. deinit is a genuine teardown signal — it is where uploadServer?.stop() already lives — but it is unreachable while the fetch is running. The task body is await self?.prepareEditor(), and optional-chaining a weak self into an async call holds a strong self for the duration of that call, across every suspension inside it. The editor always outlives its own load, so deinit runs only after the task has finished, where cancel() is a no-op.

Confirmed rather than reasoned: in theInFlightFetchKeepsTheEditorAlive, dropping the last external reference while the fetch is parked leaves the editor alive; releasing the parked request frees it. A deinit cancel would have been dead code, so the handle goes away with the override instead of moving there.

4. Gate viewDidDisappear on isBeingDismissed / isMovingFromParent ❌

Hosts install this controller as a child, so UIKit sets those flags on an ancestor and they read false here. Walking up to that ancestor does work — #649 measured a probe across fourteen hosting shapes that separates detaching from being covered without a single false positive — but that only pays off once the action is recoverable. Cancelling here is terminal: nothing restarts the fetch and displayError offers no retry, so a wrong guess costs the session. Same conclusion as #649, and the same reason.

How?

ios/Sources/GutenbergKit/Sources/EditorViewController.swift: delete the viewDidDisappear override and the dependencyTaskHandle property. The fast path's 22-line comment collapses to two lines stating the claim — the reasoning lives in this description instead. deinit is unchanged.

ios/Tests/GutenbergKitTests/EditorViewControllerLifecycleTests.swift: new. ParkedURLSession is a URLSessionProtocol whose requests park until the test releases them and record whether the surrounding task was cancelled, injected through the existing EditorViewController(httpClient:) seam — so the editor runs its real viewDidLoad → EditorService → EditorHTTPClient path and only the socket is stubbed. Each test uses a UUID site host so no earlier run's cache can serve the fetch, and removes the two roots it creates on the way out: EditorViewController builds its EditorService through the public init and exposes no seam to redirect storage the way MakesTestFixtures.makeService does.

Both tests are #if canImport(UIKit), like the existing EditorViewController test — a host swift build compiles this file away.

Test Plan

• coveringTheEditorDoesNotCancelTheDependencyFetch fails against the unfixed code with the real symptom: Expectation failed: !cancelled — 3/3 runs, 72–118ms
• iOS Simulator xcodebuild test -scheme GutenbergKit-Package — 591 tests green
• The suite leaves no on-disk residue: directory count under both roots flat across three consecutive runs, previously +2 per root per run
• Each commit builds standalone, so the history bisects
• make lint-swift clean
• Not covered: driving the covering presentation through real UIKit. The tests deliver viewWillDisappear/viewDidDisappear directly, which guards the regression — re-adding a cancel to either fails the test — but does not re-derive that UIKit sends them for a covering presentation. beginAppearanceTransition is deliberately not used in their place: it delivers nothing to a controller with no window and no parent, so swapping it in makes the test pass against the very regression it exists to catch.

Related

• fix(ios)!: add stopMediaHandling() so hosts can break the media cycle #649 — why nothing in UIKit except deinit reliably signals teardown, written up on EditorViewController.stopMediaHandling(). Not depended on here.
• The cancellation dates to Add iOS Preload List #250, where dependencyTaskHandle was introduced.

Accessibility Testing Instructions

No UI changes. The paths this touches are the editor's own progress and error screens, which are unchanged.

[wpmobilebot]

XCFramework Build

This PR's XCFramework is available for testing. Add the following to your Package.swift:

.package(url: "https://github.com/wordpress-mobile/GutenbergKit", branch: "pr-build/651")

_{Built from 809f751}