Keep Gmail actions when hiding or switching services

[jpagh]

Gmail's hover buttons sometimes did nothing when you hid Chorus or switched services right after clicking: mark read, mark unread, archive, delete. Two things caused it.

Hide and switch both cleared the page's hover state too early. Clearing hover fires mouseout, and when that exit arrived before the click's request left the page, Gmail dropped the queued write. Chorus now lets the click finish first, then clears hover, and leaves a short window afterwards for the saves that mouseout itself starts.

Switching had a second problem. It showed the new service and tore the old page down in the same step, taking any request still in flight with it. The old page now stays attached underneath until its work has finished, and comes off once it goes quiet. The same holds when you switch to a Mac-app service, where the page used to be dropped before it could finish.

Hiding does the same work in the background. The window disappears at once, and a task keeps the app awake just long enough to settle before clearing hover.

Chorus also tells Gmail it is Safari 27 rather than 26.

What this does not fix

Quitting. A live check on the clean build failed twice: the phone never showed the change while Chorus was closed, so Gmail's servers never got it. Gmail holds the request back while the page has no focus, and nothing in Chorus changes that. Reloading in the same instant can lose the change for the same reason. The changelog says both.

Tests

Fifteen tests drive a real WKWebView through the hide, switch, reload, quit and native-panel paths, and cover quirks mode, a cancelled reload, focus, resize, quick return and empty selection. One more pins the two web-view construction paths together, and one covers the settle arithmetic. The suite is 333 tests, green on macOS 14 and 15 at e82cf65.

[nicojan]

Thanks, Jack. You found the Gmail cause, and the hover timing makes sense to me. The trouble is that the fix now runs on every switch, reload and quit for every service, and that brings some regressions. I'd like it narrowed before it goes in.

Needs fixing

1. The tab strip covers the page. In WebContentCard, WebViewContainer now fills the whole ZStack, and the VStack with ServiceTabStrip sits on top of it. On main the strip pushed the page down. Open a window.open tab (Canva or Figma) and the strip, which has no background, hides the top 32pt of the page and takes its clicks. Every new test passes tabs: nil, so none of them catch it. Please keep the strip above the host, and add a test with tabs open that checks the page's frame.
2. Reload waits about two seconds. Clicking the toolbar button counts as input, so reload waits out the whole 2.2s settle window, though the pointer sits on the button and the page has no hover to clear. The spinner doesn't start during the wait, a second click queues a second reload, and the webView.url == originalURL guard drops the reload if the page rewrites its own URL meanwhile, which Gmail does. Please reload at once unless the pointer is over the page, and drop the URL guard.
3. Please check fullscreen video by hand. WebViewContainer now re-attaches the page whenever webView.superview !== self. As far as I know, WebKit moves the WKWebView into its own window for element fullscreen, so a re-render during YouTube or Meet fullscreen may pull it back. I haven't confirmed this. Re-attaching only when the page has no superview, or belongs to another host, would avoid it.

Worth changing

4. A click on the rail has already taken the pointer off the page, so WebKit has sent its own exit and there is nothing to wait for. Yet the old page stays attached for about 2.9s on every switch, and it still gets mouse moves and cursor updates in that time, because tracking areas don't care what's on top. Holding the page only when the pointer is over it would cut the change down to the case Gmail needs.
5. If someone hides, comes back within 2.2s and clicks a Gmail action, the delayed exit from the hide task lands on that click. Skipping endHover when NSApp.isHidden is false fixes it.
6. Quit now waits out the settle window first, so a click-driven quit (Sparkle's "Install and Relaunch") takes about three seconds longer. .userInitiatedAllowingIdleSystemSleep is enough for the activity.
7. The CHANGELOG says Chorus tells Gmail it is Safari 27. safariDefault goes to every service without its own agent. Please put the user agent change in its own commit, say what it applies to, and drop the comment claiming Gmail treats 27 better unless you have measured it.
8. Tests: none of them drive the wait-for-click path, since synthetic events skip the NSEvent monitor. InputSettle.shared carries state from one test to the next, and the time budgets are tight for the macOS 14 VM. I'll approve the CI run once you push.

[jpagh]

Thanks. I agree. I'm definitely not thrilled with this current state either. I did actually test the Safari 27 user agent and Gmail responded differently with it, but I can't recall what improved now. Gmail is very poorly behaved and quite frustrating to even be able to reliably test or measure. I'll see what I can do.