Highlights
🐛 serve-web / serve-vnc: clipboard sync no longer stalls for a minute
With clipboard sync on, text copied in Notes reached the host about a minute late, and everything else sent to the device pasteboard service — a copy from the host, Get from device — hung for that minute.
The device's pasteboard daemon loads the representations of a copy one by one, and Notes advertises one (public.rtf) that fails only after ~64 s. Subscribing to the daemon's own change notifications makes it load all of them on every copy before it says anything; Apple's devicectl device pasteboard monitor reports a Notes copy after 64 s for the same reason. The monitor no longer subscribes: it watches the com.apple.pasteboard.notify.changed Darwin notification and reads only the primary type of the copy, which the daemon answers at once. A Notes text copy now arrives immediately.
- A copy from the host no longer fails with
HTTP 500while the daemon is busy; it lands as soon as the daemon is free. - A picture copied out of a rich-text app such as Notes is not shared anymore: it only exists inside the app's rich representations, and reading those is what blocks the daemon. Copy it from Photos, or take a screenshot, instead. Text and plain images are unaffected.
allow_full_pull=TrueonPasteboardMonitor/read_pasteboard()brings the old behaviour back for library users. policy_threshold()used the wrong wire key and was rejected by the daemon; fixed.
What's Changed
- 3146d1a pasteboard: Never make the device pasteboard daemon stall (#1961) (@doronz88)
- e6802f7 pasteboard: Don't fail a copy to the device while the daemon is busy (#1961) (@doronz88)
- e949523 pasteboard: Stop clipboard sync stalling for a minute on rich copies (#1961) (@doronz88)
Full Changelog: v11.15.1...v11.15.2