[Init] Initial commit - NetMesh terminal manager

electron/autoLaunch.cjs

@@ -0,0 +1,195 @@
+/**
+ * Auto Launch - Registers Netcatty to start at system login, hidden to the
+ * tray. Thin wrapper around Electron's app.setLoginItemSettings/
+ * getLoginItemSettings so main.cjs and the settings IPC handlers share one
+ * source of truth.
+ *
+ * Development runs (`electron .`) are unsupported: process.execPath points
+ * at the transient electron.exe, so a login item registered there would
+ * break (or silently do nothing) after the dev process exits.
+ *
+ * Platform support is further limited to macOS and Windows: Electron's
+ * login-item API is a no-op on Linux, which ships as AppImage/deb/rpm/pacman
+ * with no first-party autostart hook, so reporting it as supported there
+ * would show an enabled toggle that does nothing.
+ */
+
+const HIDDEN_LAUNCH_ARG = "--hidden";
+
+function isAutoLaunchSupported({ defaultApp = process.defaultApp, platform = process.platform } = {}) {
+  if (defaultApp) return false;
+  return platform === "darwin" || platform === "win32";
+}
+
+function argsEqual(a, b) {
+  return Array.isArray(a) && Array.isArray(b) && a.length === b.length && a.every((value, index) => value === b[index]);
+}
+
+/**
+ * Find the specific Windows run-key entry our own writes create (path +
+ * --hidden args), not just any entry for this executable.
+ */
+function findMatchingLaunchItem(settings, execPath) {
+  if (!Array.isArray(settings?.launchItems)) return null;
+  return settings.launchItems.find(
+    (item) => item?.path === execPath && argsEqual(item?.args, [HIDDEN_LAUNCH_ARG]),
+  ) ?? null;
+}
+
+/**
+ * Resolve the OS's effective auto-launch state, not just whether a
+ * registration exists.
+ *
+ * Windows can retain the run-key entry while the user disables it via Task
+ * Manager's Startup Apps UI. Electron's executableWillLaunchAtLogin surfaces
+ * an effective state too, but it deliberately ignores the args option and
+ * reports true if the executable would launch with ANY arguments — so it
+ * can false-positive on an unrelated no-argument entry for the same exe.
+ * launchItems[].enabled is scoped to one specific path+args registration
+ * (the same combination buildLoginItemQueryOptions queries), so look up our
+ * own --hidden entry there instead and use its enabled flag.
+ */
+function resolveEffectiveLoginState(settings, platform, execPath) {
+  if (platform === "win32") {
+    const matchingItem = findMatchingLaunchItem(settings, execPath);
+    if (matchingItem) return Boolean(matchingItem.enabled);
+    // No matching --hidden entry: openAtLogin was queried with the same
+    // path+args (see buildLoginItemQueryOptions), so it is still correctly
+    // scoped to "is that exact entry registered" — false if absent.
+    return Boolean(settings?.openAtLogin);
+  }
+  if (platform === "darwin" && settings?.status === "requires-approval") {
+    // macOS 13+ (SMAppService): a freshly registered login item sits in
+    // "requires-approval" until the user approves it in System Settings,
+    // during which openAtLogin reports false even though registration
+    // itself succeeded. Reporting false here would make the renderer's
+    // push effect see a mismatch against what the user just requested and
+    // immediately fire an opposite write, unregistering the pending item
+    // before the user ever gets a chance to approve it. Treat pending
+    // approval as enabled; a later read naturally reflects the real state
+    // once the user approves it (or the OS drops the pending request).
+    return true;
+  }
+  return Boolean(settings?.openAtLogin);
+}
+
+/**
+ * Electron's getLoginItemSettings() only reports openAtLogin for the
+ * specific path+args combination you ask about — it does not mean "is
+ * anything registered for this app". Our code only ever registers a login
+ * item with args:[HIDDEN_LAUNCH_ARG], so every read must query that exact
+ * combination (matching what setAutoLaunchEnabled writes) or Windows
+ * reports a false negative.
+ */
+function buildLoginItemQueryOptions(execPath) {
+  return { path: execPath, args: [HIDDEN_LAUNCH_ARG] };
+}
+
+function getAutoLaunchEnabled({
+  app,
+  execPath = process.execPath,
+  defaultApp = process.defaultApp,
+  platform = process.platform,
+} = {}) {
+  if (!isAutoLaunchSupported({ defaultApp, platform })) {
+    return { success: true, enabled: false, supported: false };
+  }
+  try {
+    const settings = app.getLoginItemSettings(buildLoginItemQueryOptions(execPath));
+    return { success: true, enabled: resolveEffectiveLoginState(settings, platform, execPath), supported: true };
+  } catch (err) {
+    console.warn("[AutoLaunch] Failed to read login item settings:", err?.message || err);
+    // success:false signals "OS state unknown" (as opposed to a confirmed
+    // disabled state) so callers — notably the renderer's mount-time
+    // hydration — know not to trust `enabled` here. Blindly applying
+    // enabled:false on a transient read failure would overwrite the
+    // renderer's cached value and cascade into an unwanted disable write.
+    return { success: false, enabled: false, supported: true };
+  }
+}
+
+function setAutoLaunchEnabled(enabled, {
+  app,
+  execPath = process.execPath,
+  defaultApp = process.defaultApp,
+  platform = process.platform,
+} = {}) {
+  if (!isAutoLaunchSupported({ defaultApp, platform })) {
+    // enabled:false is a confirmed fact here (the feature genuinely isn't
+    // available), not an unknown state — matches getAutoLaunchEnabled's
+    // equivalent branch so both functions agree on what `success` means.
+    return { success: true, enabled: false, supported: false };
+  }
+  const wantEnabled = Boolean(enabled);
+  try {
+    app.setLoginItemSettings({
+      openAtLogin: wantEnabled,
+      // openAsHidden only applies on macOS App Store builds; Windows relies
+      // on the --hidden arg below, which main.cjs checks on cold start.
+      openAsHidden: wantEnabled,
+      path: execPath,
+      args: wantEnabled ? [HIDDEN_LAUNCH_ARG] : [],
+    });
+    const settings = app.getLoginItemSettings(buildLoginItemQueryOptions(execPath));
+    return { success: true, enabled: resolveEffectiveLoginState(settings, platform, execPath), supported: true };
+  } catch (err) {
+    console.warn("[AutoLaunch] Failed to update login item settings:", err?.message || err);
+    // `success` means "is `enabled` trustworthy", not "did the write
+    // succeed" — the write itself failing does not make a subsequent,
+    // independent read failing too. Surface whatever the fallback read
+    // determines: if it succeeds, `enabled` reflects the real (unwritten)
+    // state and the renderer's push effect correctly rolls the optimistic
+    // toggle back instead of leaving it stuck on a change that never
+    // actually happened. Only a genuine double failure (write AND fallback
+    // read both throw) reports success:false, so the renderer preserves its
+    // last-known state instead of guessing.
+    const fallback = getAutoLaunchEnabled({ app, execPath, defaultApp, platform });
+    return { success: fallback.success, enabled: fallback.enabled, supported: true };
+  }
+}
+
+/**
+ * True when this process was launched by the OS login item (cold start
+ * only). Windows relies on the --hidden arg (macOS never puts args from
+ * setLoginItemSettings() into argv for a login launch, so it needs a
+ * different signal).
+ *
+ * macOS's own hidden-launch flags (openAsHidden/wasOpenedAsHidden) are
+ * deprecated and stop working on macOS 13+ per Electron's docs, so they
+ * cannot be trusted to detect an actual hidden launch there. wasOpenedAtLogin
+ * still works on 13+ and is not deprecated; since Netcatty only ever
+ * registers a macOS login item to satisfy this "launch hidden" feature (there
+ * is no scenario where it registers one for a normal, visible startup), any
+ * automatic login launch should apply our own hidden-window behavior.
+ */
+function wasLaunchedHidden({ argv = process.argv, app, platform = process.platform } = {}) {
+  if (Array.isArray(argv) && argv.includes(HIDDEN_LAUNCH_ARG)) return true;
+  if (platform !== "darwin" || typeof app?.getLoginItemSettings !== "function") return false;
+  try {
+    return Boolean(app.getLoginItemSettings().wasOpenedAtLogin);
+  } catch (err) {
+    console.warn("[AutoLaunch] Failed to read macOS login-item launch state:", err?.message || err);
+    return false;
+  }
+}
+
+function registerHandlers(ipcMain, { app, platform = process.platform }) {
+  ipcMain.handle("netcatty:autoLaunch:get", async () => {
+    return getAutoLaunchEnabled({ app, platform });
+  });
+
+  ipcMain.handle("netcatty:autoLaunch:set", async (_event, { enabled }) => {
+    return setAutoLaunchEnabled(enabled, { app, platform });
+  });
+}
+
+module.exports = {
+  HIDDEN_LAUNCH_ARG,
+  isAutoLaunchSupported,
+  resolveEffectiveLoginState,
+  buildLoginItemQueryOptions,
+  getAutoLaunchEnabled,
+  setAutoLaunchEnabled,
+  wasLaunchedHidden,
+  registerHandlers,
+};