On macOS, clicking a widget that sets linkurl (or contains a <link url="…">) brings ScriptWidget's window to the front, and the URL itself is never opened. On iOS the same package forwards the link: ScriptWidgetApp's onOpenURL hands anything that is not ScriptWidget's own scheme to DeepLinkManager.openDeepLink, which calls UIApplication.shared.open.
To reproduce
$render(
<vstack frame="max" linkurl="https://xnu.app/scriptwidget">
<text>Open the site</text>
</vstack>
);Add it to the macOS desktop or Notification Center and click it.
Expected: the URL opens with its default handler, as on iOS.
Actual: ScriptWidget's main window comes forward; nothing else happens.
Cause
WidgetKit delivers widgetURL / Link destinations to the containing app. The iOS app handles them; ScriptWidgetMacApp has no onOpenURL (or application(_:open:)) handler, so on macOS the URL is dropped.
Suggested fix
Mirror the iOS behaviour in macOS/ScriptWidgetMac/App/ScriptWidgetMacApp.swift, e.g.:
WindowGroup {
// … existing content …
}
.onOpenURL { url in
guard url.scheme != kDeepLinkDefaultScheme else { return }
NSWorkspace.shared.open(url)
}Ideally a forwarded link would not also raise ScriptWidget's window, so the click goes straight to its destination; an NSApplicationDelegate application(_:open:) implementation may suit that better than onOpenURL. (I have not built this — it is from reading the source.)
Related, on iOS
The iOS handler returns early when url.host() is nil, so a link with an empty host such as scriptable:///run/Name (the only form Scriptable accepts) is silently dropped rather than forwarded. Forwarding those too would let a widget open another app's URL scheme regardless of its host convention.
Use case
I render cards in a widget and want a click to open a detailed page for that card (an HTML file on macOS). On iOS the forwarding already works for URLs with a host; on macOS every click lands in the app.
Thanks for ScriptWidget!
On macOS, clicking a widget that sets
linkurl(or contains a<link url="…">) brings ScriptWidget's window to the front, and the URL itself is never opened. On iOS the same package forwards the link:ScriptWidgetApp'sonOpenURLhands anything that is not ScriptWidget's own scheme toDeepLinkManager.openDeepLink, which callsUIApplication.shared.open.To reproduce
Add it to the macOS desktop or Notification Center and click it.
Expected: the URL opens with its default handler, as on iOS.
Actual: ScriptWidget's main window comes forward; nothing else happens.
Cause
WidgetKit delivers
widgetURL/Linkdestinations to the containing app. The iOS app handles them;ScriptWidgetMacApphas noonOpenURL(orapplication(_:open:)) handler, so on macOS the URL is dropped.Suggested fix
Mirror the iOS behaviour in
macOS/ScriptWidgetMac/App/ScriptWidgetMacApp.swift, e.g.:Ideally a forwarded link would not also raise ScriptWidget's window, so the click goes straight to its destination; an
NSApplicationDelegateapplication(_:open:)implementation may suit that better thanonOpenURL. (I have not built this — it is from reading the source.)Related, on iOS
The iOS handler returns early when
url.host()is nil, so a link with an empty host such asscriptable:///run/Name(the only form Scriptable accepts) is silently dropped rather than forwarded. Forwarding those too would let a widget open another app's URL scheme regardless of its host convention.Use case
I render cards in a widget and want a click to open a detailed page for that card (an HTML file on macOS). On iOS the forwarding already works for URLs with a host; on macOS every click lands in the app.
Thanks for ScriptWidget!