macOS startup can hang while reading Wi-Fi SSID without location permission

[liewstar]

Summary

On macOS, FLClash can get stuck on the dashboard in the "connecting" state during startup because the app tries to read the current Wi-Fi SSID before the Wi-Fi/location permission flow is settled.

Observed behavior

• The FLClash UI process stays alive.
• The core process is not started, and the usual local proxy/controller ports are not listening.
• Sampling the macOS process shows the main thread blocked in the Wi-Fi SSID path:
  • WifiSsidPlugin.handle
  • WifiSsidPlugin.getSsid
  • CWFInterface.networkName / CWFInterface.SSID
  • CoreLocation

Expected behavior

Startup should not block on Wi-Fi SSID lookup. If location permission is missing, denied, unavailable, or the native Wi-Fi API stalls, the app should treat the SSID as unavailable and continue startup.

Root cause

The connectivity manager calls WifiSsidManager.getSsid() directly when Wi-Fi is detected. On macOS, SSID access is permission-gated through location services, and the native plugin calls CWWiFiClient.shared().interface()?.ssid() synchronously. In some permission/system states, that call can block long enough to freeze the app startup path.

Suggested fix

• Check location permission before reading the SSID.
• Treat missing/denied permission as a recoverable "no SSID" state.
• Avoid completing stale concurrent SSID refreshes out of order.
• Add native and Dart timeouts/fallbacks so the startup path cannot hang indefinitely.