fix(extension): reconnect via chrome.idle on OS resume / screen unlock#1737
Open
Benjamin-eecs wants to merge 1 commit into
Open
fix(extension): reconnect via chrome.idle on OS resume / screen unlock#1737Benjamin-eecs wants to merge 1 commit into
Benjamin-eecs wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR improves the reliability of the OpenCLI Browser Bridge extension by ensuring it reconnects to the daemon after OS resume and screen unlock, addressing cases where MV3 service worker suspension can cause the existing keepalive alarm-based reconnect to be skipped.
Changes:
- Add a
chrome.idle.onStateChangedlistener to triggerconnect()when the browser transitions to theactivestate. - Add the
"idle"permission to the extension manifest to enable the idle API. - Update the built service worker output (
dist/background.js) to include the new reconnect hook.
Reviewed changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
extension/src/background.ts |
Registers an idle.onStateChanged listener to reconnect on active after resume/unlock. |
extension/manifest.json |
Adds the required "idle" permission for the idle API. |
extension/dist/background.js |
Built output updated to reflect the new idle-based reconnect logic. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
dc20ed3 to
1a716ee
Compare
0b48f61 to
0e13776
Compare
b9aadbf to
368ae69
Compare
d59d819 to
082a91f
Compare
e39c595 to
a410667
Compare
The 24-second keepalive alarm is the only reconnect trigger today, but Chrome may suspend the MV3 service worker across deep sleep so an alarm tick can be skipped past system resume. Add chrome.idle.onStateChanged to wake the worker on the first active signal after lock or sleep. Fixes jackwener#1735
a410667 to
ad3073d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
The Browser Bridge extension can stay disconnected after Chrome resumes from long sleep. The 24-second
keepalivealarm is the only reconnect trigger today, and Chrome may suspend the MV3 service worker across deep sleep so that alarm tick is skipped past system resume. The extension then stays idle until the user manually toggles it off/on inchrome://extensions.Add a
chrome.idle.onStateChangedlistener that callsconnect()when the state transitions toactive. This is the documented wake signal Chrome delivers on screen unlock and OS resume, and it wakes the suspended service worker directly rather than relying on the next alarm tick.Related issue: fixes #1735
Type of Change
Checklist
Screenshots / Output
Verified locally on Chrome for Testing 149 (macOS 15) with the patched extension loaded next to the unpatched release in a separate profile.
chrome.idle.onStateChangedfired on real OS idle transition and the service worker's listener received the event; the existingconnect()path then re-established the daemon WebSocket.