Native Messaging hub exiting issue , Manifest V3 chrome extension

[Praveen K K]

Since I listen on empty message from native messaging hub ( like to handle browser unexpected unload), everything was working fine in manifest V2.

After the introduction of V3, since the service worker are getting inactive after 5+ minutes of idle activity, the framework sends empty message to messaginghub and its gets unloaded.

so is there any workarounds? 

any ways to kept the serviceworker active all time ?

how we can manage the persistent port connection ? like how will manage with

port handle variable ?

Any suggestion will be appreciated!

Thank you

[Praveen K K]

Got one workaround using chrome.alaram

add this code to the background script

chrome.alarms.create({ inMinutes: 3 });
chrome.alarms.onAlarm.addListener(() => {
    console.log("Re-activating service worker");
});

[Ryan Guilbault]

I have a similar concern. I found that even if I'm piping messages from my web application to the native messaging host, as long as the user hasn't interacted with the web page in 5 minutes the service worker is unloaded/disconnected from the native messaging host.

when you receive the alarm, are you doing anything specific or is the fact that the alarm was triggered enough to keep the service worker from becoming unloaded?

does anybody know if this is a sanctioned workaround or might it cease working in some future update?

because of the aforementioned shortcoming of postMessage not being enough to keep the connection(s) alive, I ended up tackling a redesign that uses message acknowledgment between the web application and the native messaging host so that I can re-establish a connection and replay any lost/unacknowledged messages -- while a bit of a pain to pull off, it does insulate me from any disruption that knocks out the extension/native messaging host communication channel (extension gets reloaded due to update; someone performs a taskkill indiscriminately). a hurdle I need to overcome with this, however, is that Chrome does not reactivate the service worker consistently. I need to perform an action in the web application that significantly alters the DOM to reactivate the service worker (haven't diagnosed the specifics, but clicking around the page/causing minor cosmetic changes like row highlight changes are not enough to bring things back to life. only when I perform an operation that completely rebuilds one of the primary elements of the page (causing the whole page to be re-rendered) has consistently worked for me thus far. so I am very interested to know if relying on alarms is a viable method to keep the service worker alive during inactivity.

[Praveen]

There was a twist in the tail :-(, my bad, I realized it later after I posted here

It was working only because I kept my devtool open for the extension's script. 

                

Subscribe to receive emails from MEDITECH or to change email preferences.

COVID-19 Customer Resources

[wOxxOm]

The 5-minute limit is lifted for nativeMessaging in MV3 since Chrome 100, currently the Canary channel:
https://chromiumdash.appspot.com/commit/fbeff9fb7e04dbd50abeb39ca894683889a97472