Classic Editor: `postboxes.add_postbox_toggles()`'s jQuery UI `.sortable()` init hangs the main thread indefinitely in Safari 26.0.1 (WebKit 605.1.15)

[neochrome]

On a stock WordPress 7.1 install — default theme (Twenty Twenty-Five), zero plugins — opening any
post or page in the Classic Editor in Safari 26.0.1 on macOS hangs the browser tab's main thread
completely between DOMContentLoaded and window.load. The tab becomes fully unresponsive: no
scroll, no focus, no typing, no further script execution. Chrome and Firefox on the same machine
load the same screen normally. The block editor is unaffected in Safari.

This reproduces on the single default "Hello world!" post with no custom fields, no extra meta
boxes, and no plugins active, so it is not specific to any plugin, theme, or content type — it's in
WordPress core's own admin JS interacting with Safari 26.

Steps to reproduce

1. Fresh (or default-content) WordPress 7.1 install, default theme, no plugins active.
2. In Safari 26.0.1 on macOS, log in to wp-admin and open post.php?post=1&action=edit (or any post/page) — forced into the Classic Editor if the block editor is the default (e.g. via the Classic Editor plugin, or add_filter('use_block_editor_for_post', '__return_false')).
3. Watch the page: it paints, then the tab locks up before load fires. No user input registers.

Isolation / root cause

Bisected with an instrumented mu-plugin (PHP + browser lifecycle logging: heartbeat, rAF-gap and
main-thread-stall detection, per-request script/style dequeue and stub knobs) driving real Safari
via safaridriver for a deterministic HANG/OK verdict per trial (~20s/trial, ~40+ trials run).

• The hang sits in wp-admin/js/post.js's jQuery(document).ready handler, specifically the statement immediately after new ClipboardJS('.copy-attachment-url.edit-media') (wp-admin/js/post.js, around line 315): postboxes.add_postbox_toggles(pagenow); (line 319).
• Inside wp-admin/js/postbox.js, add_postbox_toggles() calls init(), which runs jQuery('.meta-box-sortables').sortable({ ..., forcePlaceholderSize: true, ... }) (jQuery UI Sortable).
• Decisive test: with the rest of add_postbox_toggles() left completely intact (its click-handler bindings for .hndle, .handlediv, .hide-postbox-tog, etc. all still run normally) and *only* jQuery.fn.sortable replaced with a no-op (function(){ return this; }) immediately before it would otherwise run, the hang disappears entirely — the page reaches readyState: complete and fires load normally. Every trial that leaves the real .sortable() call in place hangs; every trial that skips only that call does not. This isolates the loop to jQuery UI Sortable's own initialization (likely its internal geometry read/write for forcePlaceholderSize and per-item height calculation across .meta-box-sortables/.postbox), not to WordPress's own code around it.
• Removing all page CSS also prevents the hang, which rules out a pure logic loop (e.g. a bad while condition) and points at a layout-dependent loop: something in Sortable's init reads a geometry property (outerHeight()/offsetHeight), the browser performs a synchronous layout pass, and — specifically under Safari 26's WebKit engine — the loop never resolves. Google Chrome (Blink) does not reproduce it at all. An older Playwright WebKit build (2336) also does not reproduce it, suggesting this is a very recent WebKit/Safari 26 regression rather than a long-standing Sortable bug — though I have not identified a specific WebKit engine change or Bugzilla ticket to point to; I could not find one on a search of WebKit Bugzilla and would welcome a WebKit engineer's read on this from the WordPress side.
• This is unrelated to Advanced Custom Fields or any other plugin: initially observed on 4 ACF-driven pages and suspected to involve ACF's acf_after_title field-group position, but that hypothesis was tested and disproved (forcing the field group to a standard normal position did not fix it), and the hang was then reproduced on a completely stock post with all plugins deactivated and the default Twenty Twenty-Five theme active.

Environment

• WordPress 7.1
• Safari 26.0.1, AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0.1 Safari/605.1.15 (from the browser's own navigator.userAgent, captured during testing)
• macOS (Local by Flywheel dev environment); also reproduces on the same site in production
• Default theme (Twenty Twenty-Five) and separately the site's own theme; no plugins required

Workaround

Sites can avoid the Classic Editor for affected screens (the block editor does not hit this code
path and is unaffected in Safari 26) or supply their own admin_enqueue_scripts override that
prevents postbox.js's .sortable() call from running.

What I can provide on request

• The mu-plugin used for instrumentation/bisection (PHP + browser-side lifecycle logging with dequeue/stub/shim knobs) and the safaridriver-driven bisection script, if useful for others trying to reproduce or narrow this further.
• The full bisect trial ledger (~15 trials from initial symptom to this isolation).