fix(macos): prevent use-after-free in stop_task on macOS 11 during WKWebView dealloc

[x93008]

macOS 11 WebKit bug: during WKWebView dealloc, stopAllTasksForPage calls stop_task with already-freed task pointers. Any access (including the implicit objc_release from objc2 reference types) causes SIGSEGV.

Fix:

• stop_task: use raw pointers (*mut AnyObject) instead of objc2 references to skip automatic retain/release. Body is no-op since task is invalid.
• start_task response handler: explicit drop(webview) before drop(task) to ensure correct deallocation order.

closes #1733

Details

On macOS 11, WebKit's internal stopAllTasksForPage (triggered during [WKWebView dealloc]) passes already-freed WKURLSchemeTask pointers to the webView:stopURLSchemeTask: callback. Using objc2 reference types (&WryWebView, &ProtocolObject<dyn WKURLSchemeTask>) triggers implicit objc_retain on entry, which crashes on the freed pointer.

The explicit drop ordering (drop(webview) before drop(task)) prevents a scenario where dropping Retained<WryWebView> on a worker thread triggers dealloc → stopAllTasksForPage → stop_task, while the task reference is still alive in the closure.

This is the same class of race condition reported in tauri-apps/tauri#11516 (macOS 15) and #1730.

[x93008]

Tested Platforms

OS	Version	Result
macOS	11.7.10 (Big Sur)	✅
macOS	12.7.3 (Monterey)	✅
macOS	13.6 (Ventura)	✅
macOS	14.2.1 (Sonoma)	✅
macOS	15.7.2 (Sequoia)	✅
macOS	26.4.1 (Tahoe)	✅
Windows 10	22H2 (19045.5011)	✅
Windows 11	25H2 (26200.8457)	✅

All platforms pass without crash.

[sftse]

Without knowing a lot about the platform, it would be very odd for pointers passed from the platform to user code to be invalid.

The manual drop order looks really wrong as well, a mixture between manual memory management and refcounting.
Probably worth investigating those arguments of the function on which somebody put FIXME.

[github-actions]

Package Changes Through 9be1a6b

There are 1 changes which include wry with minor

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
wry	0.55.1	0.56.0

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[x93008]

Thanks for the feedback. Let me address both points:

Re: "it would be very odd for pointers passed from the platform to user code to be invalid"

You're right that this shouldn't happen, but it's a known WebKit bug that was fixed upstream. The specific issue is in WebURLSchemeHandlerCocoa::platformStopTask — prior to the fix in WebKit changeset 277235 (bug #225373):

"We weren't explicitly keeping a strong reference to the task given to the API client in startURLSchemeTask: and stopURLSchemeTask: which could cause all our internal maps to release their references to the task"

"We were keeping a HashSet of raw WebURLSchemeHandler pointers, then using each of them without keeping it alive."

The fix added auto strongTask = retainPtr(wrapper(task)) before calling into stopURLSchemeTask:. On macOS 11, which ships an older WebKit without this fix, the task pointer passed to stopURLSchemeTask: during dealloc can already be freed. This isn't theoretical — it's reproducible on macOS 11.7.10 and matches the crash in #1733.

See also #1484 which fixed a closely related issue on the start_task side: "The webview and task objects passed to start_task were not retained, leading to use-after-free issues in the responder." My PR addresses the same class of problem on the stop_task path — which #1484 did not cover.

Re: "The manual drop order looks really wrong"

I agree. The explicit drop ordering is a hack and I'm not confident it's the right approach. To be honest, I'm not deeply familiar with objc2's reference semantics in Rust or the idiomatic way to handle this kind of platform-level lifetime issue. My fix was pragmatic (it stops the crash across macOS 11–26) but clearly not elegant.

If someone more experienced with Rust + macOS/objc2 could suggest a cleaner solution, I'd be happy to rework the PR accordingly. The core constraint is: on macOS 11, stop_task will receive freed pointers — we need to handle that somehow without triggering implicit retain/release.

[Legend-Master]

Also thanks for the context,

FIXME: though we give it a static lifetime, it's not guaranteed to be valid.

is a leftover from #1484 and can be removed now

[Legend-Master]

Does this alone fix the problem?

[sftse]

Is this change still necessary once we figure out what to do with stop_task?

I'm reading the explanation as, dropping webview is necessary because we call stop_task on the freed task, which the other hunk is supposed to address.

[Legend-Master]

I don't think we can simply removing this?