Skip to content

v1.3.3 - Sign-in Windows Stay In Notihub

Choose a tag to compare

View all tags
@Thuong180702 Thuong180702 released this 09 Aug 08:42
· 6 commits to main since this release
v1.3.3
3bbc247

🚀 Notihub v1.3.3

Release Title: v1.3.3 - Sign-in Windows Stay In Notihub

🎯 What this fixes

Signing in to a service no longer throws you out to your default browser. If clicking sign-in on Gmail, Outlook or anything else opened Safari or Chrome instead of staying in Notihub, this release is the fix.

🔍 Correcting what v1.3.2 claimed

v1.3.2's notes said Google sign-in broke because v1.3.1 leaked the app's name into the User-Agent. That explanation was wrong, and this release corrects it.

The User-Agent leak was real and is genuinely fixed — but it was never what sent you to the browser. Loading Google's sign-in page under both the broken v1.3.1 User-Agent and the fixed one produces the same normal sign-in form, with a password field and no "browser may not be secure" block. The UA was not the cause.

The actual cause is older than all of this:

// src/main.js — unchanged since before v1.2.0
wc.setWindowOpenHandler(({ url }) => {
  shell.openExternal(url);   // *every* popup, including sign-in windows
  return { action: 'deny' };
});

Every popup a service opened was handed to the default browser — sign-in windows included. A sign-in popup sent to your browser can never work: the cookie it sets lands in Safari or Chrome, not in that service's session inside Notihub, so you end up signed in everywhere except the app you were trying to fix.

This was never a v1.3.1 regression. It has been there the whole time, in v1.2.0 and v1.3.0 too — those versions felt fine because you were already signed in and never hit a sign-in popup. My apologies for the wrong diagnosis in v1.3.2.

🛠️ How it works now

A popup opens inside Notihub, on that service's own session, when either:

  • The URL is part of an auth flow — a known provider (Google, Apple, Microsoft/Entra, Okta, Auth0, OneLogin, Duo, Yahoo, Telegram), an auth-shaped path (/oauth, /login, /signin, /sso, /saml, /authorize, /2fa, …), or the service's own site; or
  • It is a real popup — window.open with window features, which is measurably how auth popups arrive. This catches identity providers not on any list.

Everything else still opens in your real browser: a target="_blank" link, or a featureless window.open to an unrelated site — which is exactly where a link a colleague sent you belongs. A popup to a non-web scheme (javascript:, file:) opens nothing at all.

Two smaller things that follow from it:

  • The menubar panel no longer hides itself mid-login. It hides on blur, which was right until a sign-in window it opened took focus and made the panel vanish underneath you.
  • Multi-hop flows stay in-app the whole way (service → provider → the provider's own consent page), instead of escaping on the second hop.

✅ How this was verified

Measured, not assumed — the same method that caught the wrong v1.3.2 diagnosis:

  • The disproof: Google's sign-in page loaded under the v1.3.1 UA and the fixed UA returns byte-for-byte the same result — blocked: false, password field present, no popup. The UA was not the cause.
  • The real handler, driven through five cases: a listed provider's popup opens in-app; an unlisted provider's popup opens in-app via the window-features rule; a target="_blank" link goes to the browser; a featureless window.open to an unrelated site goes to the browser; a javascript: popup opens nothing.
  • The part that actually matters: the in-app popup runs on the same session object as its service view and can read a cookie set on that session — so the sign-in it completes lands where the service tab will find it.
  • npm test: 66 checks, including new coverage for the popup routing rule.

📦 Download Assets & Checksums

Asset File Format SHA-256 Checksum
notihub-v1.3.3-mac.dmg Native macOS DMG Installer b836752215dedd2c1e8109ff08c26f14d292ccd83f7559951506770e6257cc6c
notihub-v1.3.3-mac.zip Portable Zip Archive a93fe5b0841b7c80290a88b6100833149dfe6343e7fdb9bccdad6b2333164e75

These match what GitHub publishes as the digest field on each asset — the same value src/updater.js verifies the download against before installing.

📥 Installation Options

Method 1: Homebrew (Recommended)

brew tap thuong180702/notihub
brew install --cask notihub

Method 2: npm (CLI companion)

npm install -g @thuong180702/notihub

Method 3: DMG Installer

  1. Download notihub-v1.3.3-mac.dmg below.
  2. Double click to open the DMG, then drag notihub.app into Applications.

Method 4: Direct Zip Download

  1. Download notihub-v1.3.3-mac.zip.
  2. Unzip and move notihub.app into /Applications.

⬆️ Upgrading

Use Settings → Download & Install. No bundle identifier or data-directory change, so existing logins and notification permissions stay intact.

If a sign-in still escapes to your browser, the URL your browser opened identifies the provider that needs adding — paste it into an issue and it is a one-line fix.

⚠️ Gatekeeper Notice

Notihub is signed ad-hoc, not notarized by Apple, so macOS will refuse a manual install with "notihub is damaged and can't be opened". This isn't corruption — it's Gatekeeper rejecting an unnotarized app. Clear the quarantine flag once:

xattr -dr com.apple.quarantine /Applications/notihub.app

Updates Notihub installs itself are never quarantined, so this is only needed for a fresh manual install.

Assets 4
Loading