🐛 Bug Fixes
Authentication failed to start on slow hosts (#32)
Starting authentication wipes the browser profile, so the first page load is always fully cold (no DNS/JS/CDN cache). On slower hardware it regularly exceeded the hardcoded 30-second navigation timeout, making every authentication attempt fail with "Failed to start authentication" - while the browser was still visible (but unmonitored) in noVNC.
- The initial navigation now waits for
domcontentloadedinstead of the fullloadevent, with a 120-second budget. - Verified on a cold start: navigation completes in seconds instead of timing out.
Sign-in page kept reloading during authentication
With a freshly wiped profile, Microsoft bounces account.microsoft.com/family to a marketing page. The auth monitor kept re-navigating there every ~3 seconds, reloading the sign-in page under the user's fingers and making login impossible. The monitor now redirects once to the account portal (which forces a real sign-in) and then waits quietly - cookie-based detection picks up the session as soon as you complete the login over noVNC.
HACS installed a stale integration version
The release workflow bumps manifest.json after the tag is created, so the tag's source archive always shipped the previous version number (HACS reported v1.1.1 while manifest.json said 1.1.0). The integration is now distributed through the release-built zip (zip_release), which always carries the correct version.
⚙️ Under the hood
hacs.json: enabledzip_release+filenameso HACS downloads the workflow-built asset instead of the tag's source archive.- Release workflow: the zip now contains the integration files at its root, matching how HACS extracts it.
📦 Update
- Integration (HACS): update to v1.1.2, then restart Home Assistant.
- Add-on: update Microsoft Family Safety Auth to 1.1.2 from the add-on store (refresh the store if it doesn't appear).
- If your status was Degraded: open the add-on Web UI → Start Authentication → sign in over noVNC. The login page now stays stable.