Skip to content

0.9.6

Choose a tag to compare

View all tags
@Proxify Proxify released this 21 Aug 06:04
· 2 commits to main since this release
v0.9.6
4b1cc04

CCC 0.9.6 — desktop installers.

What changed since 0.9.5

fix(login): a denied window.open in the desktop shell is not a blocked popup (#2170)

On Windows, "Continue with Discord" failed with "Enable pop-ups to sign in with this provider" on machines with no popup blocker involved. 0.9.5 correctly routed the desktop shell to the handoff flow; the failure simply moved one line further down. Handoff opens the cloud callback with window.open and treated a null return as a blocked popup. Inside the shell null means something else: the link policy opens the URL in your system browser and then denies the in-app window, so the renderer gets null even though the browser tab opened correctly. The popup worked — the check misread it.

popupWasBlocked() now only treats null as a block outside the shell, and the notice tells shell users to finish signing in in their browser rather than pointing at a tab that isn't in the app.

How far this is verified

The popup check itself is unit-tested in both directions: a genuinely blocked popup in a normal browser still reports as blocked, and a null from the shell's deny-after-open policy does not — invert the guard and the tests fail.

The full Discord sign-in round-trip is still unverified end-to-end. Proving it needs a real Electron shell plus a live provider login, which no CI gate covers. In particular, whether pollHandoff completes after you sign in has not been observed by anyone yet. This is the third fix on this path (0.9.5 fixed the redirect branch, 0.9.6 fixes the popup check). Treat cloud sign-in as improved, not as known-good — and please report what you see.

Known issues — stated up front, not surprises

  • macOS is arm64-only. No Intel build.
  • Windows installers will likely trip SmartScreen. No Authenticode certificate is wired through electron-builder.yml. The Windows build host does invoke signtool.exe, but that certificate has not been identified, so treat these installers as unsigned and expect the "Windows protected your PC" prompt (More info → Run anyway).
  • .deb installs do not auto-update — the app detects a package install and defers to your package manager. The AppImage does auto-update.
  • Linux ships without a QA gate. macOS has a signed-and-notarized smoke gate on the shipped bytes; Windows and Linux have no equivalent, so those lanes are less verified.
  • 0.9.0 installs cannot auto-update to anything — they shipped before the updater was unblocked. Those users need one manual reinstall.
  • LICENSE.md links a private repo that 404s for the public.

macOS is signed, notarized and stapled (app, zip, and dmg), and auto-updates via the .zip. Windows and the Linux AppImage self-update.

Assets

CCC-Setup-0.9.6.exe / CCC-0.9.6.msi (Windows) · CCC-0.9.6-arm64.dmg (macOS, Apple silicon) · CCC-0.9.6-x86_64.AppImage / CCC-0.9.6-amd64.deb (Linux). The -mac.zip and latest*.yml files are the auto-update payloads.

Assets 14
Loading