fix(runtime-wry): reapply custom traffic light position on macOS

[tenderdeve]

Closes #15451
Closes #13044

macOS resets a window's custom traffic light inset back to the system default in two cases, and it stays wrong until the window is resized:

• exiting fullscreen from a maximized window ([bug] [macOS] Custom traffic light position reset after quitting fullscreen of maximized window #15451)
• changing the window title from JS/Rust ([bug] Setting window title resets traffic light position #13044)

Both come down to the same thing — AppKit re-lays-out the title bar buttons and tao doesn't reapply our inset. @FabianLars flagged these should be fixed together.

Fix: keep the configured position on the window and reapply it right after a title change, and on resize — a resize is the only event tao emits for a green-button fullscreen exit, and it matches the existing resize the window and it comes back workaround. set_traffic_light_position also updates the stored value so later reapplies use the latest.

All of it is macOS-gated. Raw windows (CreateRawWindow) don't carry the config so there's nothing to reapply for them.

[FabianLars]

this pr also contains #15604 - i think that will resolve itself when the other one is merged but just blocking the merge on that to not do an oopsie

[FabianLars]

In general i am not sure if this should be fixed in tauri. For similar cases i added the workarounds into tao and wry directly and hoped we could do the same here.

[tenderdeve]

@FabianLars rebased onto dev — the #15604 commits are gone, so this PR now only touches crates/tauri-runtime-wry/src/lib.rs + its change file. Merge order no longer matters.

On whether it belongs in tauri vs tao/wry: fair point. The reapply itself is just window.set_traffic_light_inset(pos) (already a tao API), so tao could own this by caching the last inset and re-applying it internally after set_title and on fullscreen-exit — that'd fix it for non-tauri tao users too. The only reason it's here is that tauri-runtime-wry is where the configured position currently lives; tao's setter is one-shot and doesn't persist.

Happy to move it upstream instead — close this and open a tao PR making the inset sticky across those events. Your call on which layer you'd prefer; if you'd rather keep the fix tauri-side for now I'll leave it as is.

[FabianLars]

The only reason it's here is that tauri-runtime-wry is where the configured position currently lives; tao's setter is one-shot and doesn't persist.

This isn't the case actually, we store it in an objc Ivar as well https://github.com/tauri-apps/tao/blob/14a6dec20897904c9041c52cb92111b81db20e13/src/platform_impl/macos/view.rs#L343-L349

But i just remembered i had a tao branch related to one of the 2 github issues https://github.com/tauri-apps/tao/tree/refresh-lights (that's a bad way to do it i think - and its not using the ivar state as well)

Let me go through things, i'll get back to you.

[tenderdeve]

@FabianLars opened the tao-side version: tauri-apps/tao#1254. It reapplies the inset from the existing taoState ivar after setTitle: and after leaving fullscreen, so it covers both #13044 and #15451 with no new state (addresses the "not using the ivar" point on your refresh-lights branch).

Happy to close this PR (#15628) once #1254 lands and the tao bump flows through, or keep this one as the interim runtime-wry fix if you would rather not wait on a tao release — your call.

[tenderdeve]

@FabianLars #15604 merged, so I rebased on dev — the overlapping commits dropped out and this PR is now just the traffic-light change (crates/tauri-runtime-wry/src/lib.rs + changefile). Commit 4a857199c, signed/Verified. Should be safe to merge now.

[FabianLars]

i'll test the tao PR and if it works we'll go with that instead :) kinda forgot about this, sry