Share my new tab groups extension

[Jackie Han]

New tab group api is available from Chrome 89.

I spent two weeks trying to make an extension to use this feature, which was also my first MV3 extension. Welcome to try it: https://chrome.google.com/webstore/detail/nplimhmoanghlebhdiboeellhgmgommi

[hrg...@gmail.com]

A terrible decision from the Chrome developers to disallow that API in Manifest V2.

MV3 is far from being production-ready and the tab-groups feature has been available to users since last year. So extensions developers need access to the API now in MV2, not next year when MV3 is finally usable (hopefully).

[Jackie Han]

Yes, MV3 has a little/some flaw(s). So I only use MV3 when I try to make new things.

[Simeon Vincent]

The Chrome team views MV3 as the current extensions platform and MV2 as deprecated. We will continue to support the MV2 platform, but all new feature development will be limited to MV3.

hrg, what do you feel keeps MV3 from being production-ready? To be clear, I am familiar with a number of bugs and gaps in the platform; I'm specifically asking what aspects of the experience you feel are lacking.

Simeon - @dotproto

Chrome Extensions DevRel

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAAgdh1KiNHRr3_6adcnJBZHKUu0xOcx%2B9DE0SgKeLEo2JFrC6Q%40mail.gmail.com.

[Cuyler Stuwe]

Serious question, not necessarily meant to be snippy or anything, but:

Does the Chrome team spend any time actually creating extensions of any consequence for the public (“dogfooding” the platform)?

I’m in Upwork’s top 1% program as a freelance dev who exclusively builds out browser extensions, and for most of my clients, I’ve advised them that although MV3 seems to be the future, it’s incredibly unstable with some huge gaps and that it would probably be best to stick with MV2 until it’s literally impossible to use.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAFY0HLM17d21s29YBD4QCxa90F1VtuaGq-23i2XKZci1j%2BxS%3DA%40mail.gmail.com.

[Cuyler Stuwe]

IOW, the chef and the patrons have opposite views of the food coming out of the kitchen.

[Cuyler Stuwe]

... and MV3 in particular seems like it was cooked up by security ideologues who are attached emotionally to the idea of eliminating browser extensions altogether.

But they recognize that "Pandora's Box" has already been opened, and so the next-best thing is to gimp the platform so severely that nobody bothers to built out significant extensions that do anything meaningful on behalf of the user.

[hrg...@gmail.com]

On Wednesday, April 14, 2021 at 1:21:06 PM UTC-4 Simeon Vincent wrote:

what aspects of the experience you feel are lacking.

 Nothing about the experience. It's just that MV3 is still incomplete.

For example, we were promised a way to run user scripts and remotely hosted code. Without this feature, many extensions cannot be ported to MV3.

Also, what happened to the favicon API? Is that feature implemented yet?

Another example:

How can we avoid saving the extension state to permanent storage every few seconds?

I thought there was going to be a way to save the extension state to memory so that we don't need to mix the extension's permanent storage (which must persist when the browser is closed) with the extension's temporal state (which must persist when the service worker is closed).

I haven't seen a word about this yet either.

So, to answer the question:

On Wednesday, April 14, 2021 at 1:21:06 PM UTC-4 Simeon Vincent wrote:

what do you feel keeps MV3 from being production-ready?

The fact that there are a number of important features still missing, and we have no clue when (or if) these features will be available.

I won't even look at MV3 until it has the features I need to port my extensions to it.

[Simeon Vincent]

Does the Chrome team spend any time actually creating extensions of any consequence for the public (“dogfooding” the platform)? - Cuyler

A few members of the platform and CWS teams maintain public extensions and have migrated (or at least tried to migrate) to MV3. I'd be willing to bet none of them are on the scale of what you and your clients maintain, though. We do try to eat our own dog food, but there are inherent limitations there.

Part of my role here is to understand and communicate the extension development community's concerns. To that end, I'm keenly interested in gathering more detailed information about the instability and gaps you mentioned. 

IOW, the chef and the patrons have opposite views of the food coming out of the kitchen. - Cuyler

FWIW I suspect that our views are more closely aligned than you might think. At the moment I think the disconnect is around expectations of what kind of dining experience is being served. I suspect that a lot of developers assumed that MV3 support landing in Chrome Stable would be like iOS or Android distributing a new OS. Even when those releases have hitches, they're generally pretty well baked. 

To pivot the analogy, I think many developers assumed MV3 would be like moving into a new home that just hit the market while the extensions team viewed it more like opening up leasing space in a high rise currently being built. The foundation is solid, the ground floor is almost fully furnished, but at the same time we're still pouring concrete for the top floor and everything in between is at various stages between these extremes. MV3 as a work in progress. Our goal with landing support in Stable was to provide a foundation on which we can iterate and developers can build extensions. 

For example, we were promised a way to run user scripts and remotely hosted code - hrg

Support for user script extensions is still planned. Based on the feedback we've seen so far there are other features that are more important to a broader range of extensions, so we're prioritizing that work. 

I cannot recall any promises or even vague assurances around allowing remotely hosted code. In fact, we called out disallowing remotely hosted code in the MV3 design document and we've introduced CWS policies that prevent its use. Do you have a specific quote or resource in mind? I may be able to get to the bottom of the confusion.

Also, what happened to the favicon API? Is that feature implemented yet? - hrg

Not yet. How important is this feature for your extensions? Can you share more about the use case and impact not having this API has on your extension?

How can we avoid saving the extension state to permanent storage every few seconds? - hrg

Why do you want to avoid using chrome.storage or IndexedDB? Is there a specific impact you're trying to avoid, is it an ideological concern, or something else?

I thought there was going to be a way to save the extension state to memory so that we don't need to mix the extension's permanent storage (which must persist when the browser is closed) with the extension's temporal state (which must persist when the service worker is closed). - hrg

It sounds like there may be a misunderstanding here.

We are working on a new API (chrome.storage.session, crbug.com/1185226) to store small amounts of data in memory. The primary motivating use case of this API is storing user-provided values that are needed beyond a SW's life span but are too sensitive to write to disk. For example, a master password for a password vault. I anticipate that some extensions will also explore using this as a caching layer or for other performance optimizations, but we are not designing for that use case. We haven't shared any updates on this because work on this API is just kicking off now (or will be shortly).

Can you share more about your concerns with storing temporal state alongside your permanent storage? I'm also curious where you draw the line between these concepts in your extensions.

I won't even look at MV3 until it has the features I need to port my extensions to it.

That makes sense to me. Are the items you listed in your last email all of the capabilities you're blocked on? If not, what other gaps are blocking you? Of the items blocking you, is everything on that list a hard requirement?

Simeon - @dotproto

Chrome Extensions DevRel

[Darbid Darbid]

I have to chime in on the "Dining Experience". It appears to me that the inflicted diet that Chrome developers have put Extension developers on is impracticable and further more the Chrome Developers are still sitting back eating Chocolate and ice cream.  Do as we say not as we do.

You ask about stability. Does Native Messaging work with MV3? Is it stable? If it is stable where is the simple Github example? It is often communicated here that a change from MV2 to MV3 is not much work so why have you not simply changed the manifest of your examples from MV2 to MV3?

My quick search found https://bugs.chromium.org/p/chromium/issues/detail?id=1192458&q=native%20host&can=2 and https://bugs.chromium.org/p/chromium/issues/detail?id=1189678&q=native%20host&can=2 which indicate MV3 is not stable for native hots implementations.  Further I cannot find the issue I have previously read that Services workers do not wake up on Native Host Messages at all and that multiple instances of Native Hosts are created by Chrome service workers.

Further please have a read of the person testing the example in 1189678. It gives me little confidence that things will get better when the person testing cannot even get a NativeHost running.

Similarly with 1192458 - the Chrome dev/tester asks " is there any way I can make this extension workable in < M89 builds" ?????? and the response ".... if the problem on < M89 is the lack of MV3 support I would say no, there is no way to make it work on it. "

Both of the people raising these issues need a medal for their patience and spoon feeding abilities.

[Jackie Han]

(The current discussion seems to be far away from my original content.)

About favicon API
How important is this feature for your extensions? Can you share more about the use case and impact not having this API has on your extension? - Simeon

For Tab manager, History manager and Bookmarks manager extensions, the favicon API api is indispensable. They need to display favicons for users.

[hrg...@gmail.com]

I cannot recall any promises or even vague assurances around allowing remotely hosted code. In fact, we called out disallowing remotely hosted code in the MV3 design document and we've introduced CWS policies that prevent its use. Do you have a specific quote or resource in mind? I may be able to get to the bottom of the confusion.

That was a mix up of terms from my part. I meant "remotely-hosted code" in the original sense given in the MV3 proposal document. i.e. code that's not inside the extension package.

However, it's now clear that this definition is too broad.

There's also the concept of "user-provided code". i.e. code that's also not in the extension package but is provided manually by the user either as a URL or as string of JS code.

There are many extensions that need to do this. The so called user-script managers are only one kind of extension that require this functionality. There's also the family of extensions that allow the user to perform an action in response to a user-triggered event, such as a hotkey or button click. i.e. the equivalent of a bookmarklet but without the messy user experience of having to paste a huge amount of code in a one-line text field meant for a URL.

Not yet. How important is this feature for your extensions? Can you share more about the use case and impact not having this API has on your extension?

favicons access is needed whenever you need to show the user a list of bookmarks. So, virtually all extensions using the "bookmarks" permission also need the "chrome://favicons" permission.

You probably have access to those statistics. Have a look at how those two permissions occur together.

Additionally, "chrome://favicons" also gives you the favicon of open and closed tabs.

You don't strictly need "chrome://favicons" to get those favicons because we have chrome.tabs.Tab.favIconUrl. But "chrome://favicons" is much faster that downloading the favicons from their original source, so everybody is probably doing it this way instead of using chrome.tabs.Tab.favIconUrl.

"chrome://favicons"  is guaranteed to work, whereas Tab.favIconUrl may fail.

Hopefully, the new favicons API has this same benefits, otherwise it will be another source of pain and enragement.

Why do you want to avoid using chrome.storage or IndexedDB? Is there a specific impact you're trying to avoid, is it an ideological concern, or something else?

Mixing things that have a different purpose is always bad and brings you nothing but headaches.

If we have to store the extension's temporal state in the same place we store the extension's settings, then we have to review the entire code base looking for places where we assumed that chrome.storage or window.localStorage or IndexedDB contained nothing but settings. And for each of those places we have to refactor the code so that it takes into account that now there's a new thing in there. This new thing needs different treatment. It might be called "service_worker_state" or whatever you choose, and it must be ignored by the code that handles the extensions settings.

So now the extension developers world-wide will have to build a wrapper function or class around the existing storage APIs so as to emulate the effect of having two APIs, one for storing the service worker temporal state and another for the extension settings.

Whoever wants to learn to code and build cool stuff must definitely start with Chrome extensions MV3. The experience is beautiful. Plenty of rich and powerful APIs for anything you need. Intuitive like no other. No hacks needed!!

<end_of_sarcasm>

 

Are the items you listed in your last email all of the capabilities you're blocked on? If not, what other gaps are blocking you? Of the items blocking you, is everything on that list a hard requirement?

A hard requirement for me to even start the migration to MV3 is to have clear documentation of how the ephemeral nature of the service worker works in conjunction with the persistent components of the extension platform.

For example, the persistent port connections between the service worker and a content script or between the service worker and a native messaging host.

Also the "background" permission which is supposed to keep "something" working in the background when no browser windows are open.

But if the SW is ephemeral, then what is supposed to be kept in the background?

What happens to a Port object when the SW is terminated?

The port object is a Javascript variable with event handlers attached to it. What happens to those event handlers once the Port variable is wiped out together with the SW.

Do we have to create a new port variable and attached the event handlers again on every SW startup?

Something tells me that these kind of stuff are not even working properly yet.

These are the things that are a hard requirement for me. I need a platform that works correctly and predictably. And I need that this correct and predictable behavior is well documented.

[Alexei Miagkov]

Simeon, a couple of items off the top of my list:

• Injecting JavaScript into page context scope before-anything-else-happens is more broken than before. The current problem in MV2 is we don't have a way to synchronously provide configuration to before-anything-else page scripts. MV3 adds the problem of not being able to inject text or blobs into pages thanks to new Content Security Policy restrictions. Privacy Badger's current page script injection approach is broken.

• webRequest listeners go to sleep forever/never get reawakened after the MV3 Service Worker background page goes to sleep. This breaks webRequest-based learning capabilities (learning from cookie headers) of Privacy Badger.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAFY0HLNLhf4pDWtKUqaoGVQ4qRNbK_Q630qbq2UGv5%2BeuYKVDQ%40mail.gmail.com.

[Cuyler Stuwe]

@ Simeon Vincent:

"A few members of the platform and CWS teams maintain public extensions and have migrated (or at least tried to migrate) to MV3. I'd be willing to bet none of them are on the scale of what you and your clients maintain, though. We do try to eat our own dog food, but there are inherent limitations there."

Yeah, it seems to me that if the Chrome team is doing any dogfooding at all, it's just with "toy applications" probably meant mostly to smoke-test functionality that's expected to work.

To my understanding, nobody presently working at Google would have much time or any good motive to work on a side hustle working on an actual extension of any real consequence, esp. given questions about whether Google would be able to claim it as its own IP, etc.

So to me, this blinds the Chrome team into a a circle-jerk echo-chamber where nobody really realizes just how broken the extensions platform is for people whose business needs rely upon it.

[Cuyler Stuwe]

But again, if the changes are about "security", then definitely, a nonfunctional system is as secure as it gets.

If you want a secure laptop, for example, just give me a hammer. 😉

[Cuyler Stuwe]

@Simeon Vincent :

"To pivot the analogy, I think many developers assumed MV3 would be like moving into a new home that just hit the market while the extensions team viewed it more like opening up leasing space in a high rise currently being built. The foundation is solid, the ground floor is almost fully furnished, but at the same time we're still pouring concrete for the top floor and everything in between is at various stages between these extremes. MV3 as a work in progress. Our goal with landing support in Stable was to provide a foundation on which we can iterate and developers can build extensions."

Well I think the reason developers assumed MV3 would be "ready" is that Google has communicated on more than one occasion that it won't guarantee that MV2 will be usable at all for any longer than a year after MV3 hits stable Chrome.

This strongly suggests that MV3 must be "good to go" if MV2 has such a terribly-short guaranteed remaining shelf life.

I've worked on several commercial extensions which are several years into development, and their architectures would be so incompatible with MV3 that it would essentially require scrapping the codebase and starting over. Businesses are building entire applications on the extensions platform, and staking their livelihoods on it. If it took our team 2 years to get an MV2 extension to the state it's currently in, then it stands to reason that we need to get started on MV3 development in parallel right this moment to even stand a chance at making half our current progress. But it's hard to develop in earnest when the MV3 platform is so fundamentally broken.

[Simeon Vincent]

Chrome Developers are still sitting back eating Chocolate and ice cream.  Do as we say not as we do. - Darbid

Could you explain the idea behind this sentiment without the analogy? I don't follow, but I would like to.

Does Native Messaging work with MV3? Is it stable? If it is stable where is the simple Github example? It is often communicated here that a change from MV2 to MV3 is not much work so why have you not simply changed the manifest of your examples from MV2 to MV3?

I think it's fair to say that native messaging is currently broken in MV3. I don't know who in this group is communicating that "[changing] from MV2 to MV3 is not much work," but that's clearly not the case for the average extension. 

I'm actively working on building out the MV3 resources in chrome-extensions-samples repo. I'm not porting over the old examples because, honestly, I don't think they're as good as they could or should be, so I'm creating new resources from scratch. If you'd like to help, you're welcome to make a PR or open an issue to discuss ideas on what a native messaging demo should look like.

Further please have a read of the person testing the example in 1189678. It gives me little confidence that things will get better when the person testing cannot even get a NativeHost running.

It appears that you're referring to someone helping with the initial issue triage process, not a member of the extensions engineering team debugging the issue. They are not (and cannot realistically be) experts on all parts of Chromium.

For Tab manager, History manager and Bookmarks manager extensions, the favicon API api is indispensable. They need to display favicons for users. - Jackie

Thanks for the succinct reply, Jackie :)

That was a mix up of terms from my part. I meant "remotely-hosted code" in the original sense given in the MV3 proposal document. i.e. code that's not inside the extension package.

Sorry about the confusion, that's my fault as the broad definition of "remotely-hosted code" slipped my mind. As I mentioned, we are still planning to support for user script extensions, we just haven't had time to even get a design together for how yet.

There's also the concept of "user-provided code". i.e. code that's also not in the extension package but is provided manually by the user either as a URL or as string of JS code.

There are many extensions that need to do this. The so called user-script managers are only one kind of extension that require this functionality. - hrg

At the moment I assume that the solution we pursue for style/script managers will also apply to these other extensions. Would you mind sharing other examples in this space?

A hard requirement for me to even start the migration to MV3 is to have clear documentation of how the ephemeral nature of the service worker works in conjunction with the persistent components of the extension platform. - hrg

Thanks for all the detail you provided in this section. At least part of what you highlighted will fall on me and my tech writer teammate to consider and weigh. I hope you'll keep sharing feedback with us to help make the docs better for you and the rest of the community. 

Injecting JavaScript into page context scope before-anything-else-happens is more broken than before. The current problem in MV2 is we don't have a way to synchronously provide configuration to before-anything-else page scripts. MV3 adds the problem of not being able to inject text or blobs into pages thanks to new Content Security Policy restrictions. Privacy Badger's current page script injection approach is broken. - Alexei

Thanks for calling this out. I believe our plan to address this use case is to allow extensions to register content scripts with scripting.registerContentScripts and to provide config data (JSON serialized) at registration time. This is being tracked in crbug.com/1054624. I also want to call out that we are planning to allow callers to specify whether the script will run in the main or isolated world (comment 22).

webRequest listeners go to sleep forever/never get reawakened after the MV3 Service Worker background page goes to sleep. This breaks webRequest-based learning capabilities (learning from cookie headers) of Privacy Badger. - Alexei

I can see how this bug fundamentally breaks Privacy Badger. 

Well I think the reason developers assumed MV3 would be "ready" is that Google has communicated on more than one occasion that it won't guarantee that MV2 will be usable at all for any longer than a year after MV3 hits stable Chrome.

This strongly suggests that MV3 must be "good to go" if MV2 has such a terribly-short guaranteed remaining shelf life. - Cuyler

This is really useful feedback for me as I'm the main person that said this publicly and repeatedly. What I'm getting is that not only did we not share enough information about the timeline, we also should have published an updated timeline by now and shard updates on how we view the progression of the MV3 platform. 

On a more general note, this last email was the most useful for me as it contains concrete criticism I can bring to the team for discussion and consideration. The sentiments can help round out the picture, but this kind of feedback really help concretize the pain points.

Thanks all!

Simeon - @dotproto

Chrome Extensions DevRel

[Владимир Янкович]

As an extension developer, I was pleasantly surprised by the number of participants and the quality of this discussion.

I've been working on a new extension for two months now. We made it our mission to create an awesome new tab for Chrome. We immediately decided to develop on MV3. And every day I hope that we don't get stuck and we don't have to go to MV2. This is a stasis. But such discussions give hope. If the developers will listen, everything will be fine :)

понедельник, 19 апреля 2021 г. в 20:03:20 UTC+3, Simeon Vincent:

[hrg...@gmail.com]

we are still planning to support for user script extensions, we just haven't had time to even get a design together for how yet.

Really? I thought the "how" was already decided and you guys were just delaying the implementation.

This is a bit worrying. Please try to give us at least 6 months of a feature-complete MV3 before MV2 is no longer supported.

It won't be easy to refactor several years of work.

At the moment I assume that the solution we pursue for style/script managers will also apply to these other extensions. Would you mind sharing other examples in this space?

I know of two main use cases.

The first is script managers that must inject code automatically whenever a page matching a URL pattern begins loading. The user provides the URL of the script or the script itself and the extension is responsible of downloading the script (as well as future updates to the script) and injecting the code into the appropriate pages at load time (document_start).

The second use case are extensions that execute scripts in response to something the user does. i.e. there's no automatic code injection at load time. Instead, it's the user who decides when a script is executed (and where) by selecting a script from a list in the extension's popup or by pressing a keyboard shortcut. For example, a script that downloads the video in a Youtube page.

This kind of scripts may be designed to run either on a webpage or as an extension script (for running inside the extension itself, via sandboxing eval).

This is similar to the functionality provided by bookmarklets, with some clear differences. Bookmarklets run in the "main world" only (the page context) and don't have access to extension APIs, whereas content scripts run in an isolated world and can inject code into the main world as well.

Bookmarklets, however, can run in some protected URLs, such as  data: ..., view-source: ... and the Chrome Web Store, whereas content scripts cannot.

 

[Simeon Vincent]

we are still planning to support for user script extensions, we just haven't had time to even get a design together for how yet. - Simeon

Really? I thought the "how" was already decided and you guys were just delaying the implementation. - hrg

Apologies for the confusion. I was drawing a distinction between having a rough plan of action and a concrete design that we intend to implement. I tend to think of the creation and iteration on the design doc as the "design phase". In my experience it's common for a small group of engineers to consider several different approaches, have the engineer that will be implementing the feature flesh out the most promising idea in a design document, and then circulate that design doc to solicit feedback and iterate on the design.

Thanks for the notes on other script injection use cases.

Simeon - @dotproto

Chrome Extensions DevRel

[Pete Roszell]

Hi hrg,

I've been reading through the forum and obviously, you have a lot of knowledge.

Are you open to some consulting work?  I need some technical advice :-) 

Thank you,

Pete - @roszell

[hrg...@gmail.com]

Hi Pete.

I don't do consultation, but if you ask publicly here in the forum, many of us can give you technical advice and/or assistance, as time permits.

[guest271314]

I can cobble together a native messaging example using MV3.

Per https://bugs.chromium.org/p/chromium/issues/detail?id=1115640#c3 Native Messaging should still be applicable in MV3

> The Native Messaging API is part of both the Chrome Extensions and Apps platforms. As such, depreciation of the Chrome App platform does not impact this API. It will continue to be available to extensions. 

AFAIK https://github.com/guest271314/native-messaging-mkvmerge, https://github.com/guest271314/native-messaging-espeak-ng, and both extenstions in https://github.com/guest271314/captureSystemAudio/tree/master/native_messaging still work.

[guest271314]

> My quick search found https://bugs.chromium.org/p/chromium/issues/detail?id=1192458&q=native%20host&can=2 and https://bugs.chromium.org/p/chromium/issues/detail?id=1189678&q=native%20host&can=2 which indicate MV3 is not stable for native hots implementations.  Further I cannot find the issue I have previously read that Services workers do not wake up on Native Host Messages at all and that multiple instances of Native Hosts are created by Chrome service workers.

Cannot reproduce 1192458

background.js

const hostName = 'native_messaging';

let port;

const nativeMessagingPort = chrome.runtime.connectNative(hostName);

console.log(nativeMessagingPort);

chrome.runtime.onInstalled.addListener(async () => {

  console.log(self);

});

chrome.runtime.onConnectExternal.addListener((_) => {

  port = _;

  nativeMessagingPort.onMessage.addListener((message) => {

    port.postMessage(message);

  });

  port.onMessage.addListener(async (message) => {

    // console.log(message);

    while (true) {

      nativeMessagingPort.postMessage({message});

      console.log(message);

      await new Promise((resolve) => setTimeout(resolve, 1000 * 60 * 6)); // 6 minutes

    }

  });

});

nm.sh https://stackoverflow.com/a/24777120

#!/bin/bash

# Loop forever, to deal with chrome.runtime.connectNative

while IFS= read -r -n1 c; do

    # Read the first message

    # Assuming that the message ALWAYS ends with a },

    # with no }s in the string. Adopt this piece of code if needed.

    if [ "$c" != '}' ] ; then

        continue

    fi

    message='{"message": "Hello world!"}'

    # Calculate the byte size of the string.

    # NOTE: This assumes that byte length is identical to the string length!

    # Do not use multibyte (unicode) characters, escape them instead, e.g.

    # message='"Some unicode character:\u1234"'

    messagelen=${#message}

    # Convert to an integer in native byte order.

    # If you see an error message in Chrome's stdout with

    # "Native Messaging host tried sending a message that is ... bytes long.",

    # then just swap the order, i.e. messagelen1 <-> messagelen4 and

    # messagelen2 <-> messagelen3

    messagelen1=$(( ($messagelen      ) & 0xFF ))               

    messagelen2=$(( ($messagelen >>  8) & 0xFF ))               

    messagelen3=$(( ($messagelen >> 16) & 0xFF ))               

    messagelen4=$(( ($messagelen >> 24) & 0xFF ))               

    # Print the message byte length followed by the actual message.

    printf "$(printf '\\x%x\\x%x\\x%x\\x%x' \

        $messagelen1 $messagelen2 $messagelen3 $messagelen4)%s" "$message"

done

manifest.json

{

  "name": "native_messaging",

  "version": "1.0",

  "manifest_version": 3,

  "background": {

    "service_worker": "background.js"

  },

  "permissions": ["nativeMessaging"],

  "externally_connectable": {

    "matches": [

      "https://groups.google.com/a/chromium.org/g/chromium-extensions/c/gqdC9EbuIfY/*"

    ],

    "ids": [

      "*"

    ]

  }

}

Re 1189678 the Native Messaging host should be expected to automatically disconnect from background script. If the code is only expected to be executed once sendNativeMessage() can be used

chrome.runtime.sendNativeMessage('native_messaging',

  { text: "Hello" },

  function(response) {

    console.log(response);

});

On Thursday, April 15, 2021 at 1:28:30 AM UTC-7 maild...@gmail.com wrote:

[guest271314]

Re Native Messaging. The service worker actually does become inactive after N minutes and the port is diconnected.

Transferable Streams or WebTransport could be substituted for the current Native Messaging configuration.

[guest271314]

One workaround for background script disconnecting after N minutes in MV3 is to reconnect to background.js onDisconnect

var id = 'ioidncfnoimkhmoopfodljebocjbgmao';

var port = chrome.runtime.connect(id);

function reconnect() {

  port = chrome.runtime.connect(id);

  port.onMessage.addListener(

    handleMessage

  );

}

function handleMessage(e) {

  console.log(e);

}

port.onMessage.addListener(

  handleMessage

);

port.onDisconnect.addListener(async (e) => {

  console.log(e);

  reconnect();

});

port.postMessage('test');

[guest271314]

The issue with service worker becoming inactive after N minutes must be deliberate; an intentional bug, else that restriction would not be in the source code; also revealing that this use-case, persistent service worker connection to Native Messaging host could not have been, and has not been tested.

For that reason the following is not really a workaround; the issue appears to be easily fixed by removing the N minute time span before service worker becomes inactive; at the bare minimum providing an option to turn off that "feature"; however given Chromium authors resistance to incorporating user-defined options to omit source code restrictions, I am skeptical of any optional service worker not becoming inactive option actually being exposed to users at large.

background.js

const hostName = 'native_messaging';

let port;

let now = performance.now();

const nativeMessagingPort = chrome.runtime.connectNative(hostName);

console.log(nativeMessagingPort);

nativeMessagingPort.onMessage.addListener((message) => {

  port.postMessage(`${JSON.stringify(message)} at ${(performance.now() - now) / 1000}`);

});

nativeMessagingPort.onDisconnect.addListener((e) => {

  console.log(e);

});

chrome.runtime.onInstalled.addListener(async () => {

  console.log(self);

});

chrome.runtime.onSuspend.addListener(async () => {

  console.log(self);

});

chrome.runtime.onConnectExternal.addListener((_) => {

  if (port) port.disconnect();

  port = _;

  port.onMessage.addListener(async (message) => {

    nativeMessagingPort.postMessage({message});

    console.log(message);;

  });

  port.onDisconnect.addListener(async (e) => {

    console.log(e);

  });

});

console

async function* test() {

  let port;

  const id = 'ioidncfnoimkhmoopfodljebocjbgmao';

  while (true) {

    if (port) port.disconnect();

    port = chrome.runtime.connect(id);

    port.onMessage.addListener((e) => console.log(e));

    port.onDisconnect.addListener((e) => console.log(e));

    port.postMessage('test');

    yield new Promise((resolve) => setTimeout(resolve, 1000 * 60));

  }

}

for await (const message of test());

VM113:7 {"message":"Hello world!"} at 77.39239999997616

VM113:7 {"message":"Hello world!"} at 138.11920000004767

VM113:7 {"message":"Hello world!"} at 199.11020000004768

VM113:7 {"message":"Hello world!"} at 291.15229999995233

VM113:8 {onMessage: {…}, onDisconnect: {…}, disconnect: ƒ, …}

VM113:7 {"message":"Hello world!"} at 0.033699999928474424

VM113:7 {"message":"Hello world!"} at 60.874100000023844

VM113:7 {"message":"Hello world!"} at 172.8785

VM113:7 {"message":"Hello world!"} at 292.88279999995234

VM113:8 {onMessage: {…}, onDisconnect: {…}, disconnect: ƒ, …}

VM113:7 {"message":"Hello world!"} at 0.0235

VM113:7 {"message":"Hello world!"} at 119.95030000007152

VM113:7 {"message":"Hello world!"} at 180.00480000007153

VM113:7 {"message":"Hello world!"} at 299.966

VM113:8 {onMessage: {…}, onDisconnect: {…}, disconnect: ƒ, …}

VM113:7 {"message":"Hello world!"} at 0.07960000002384186

VM113:7 {"message":"Hello world!"} at 119.72239999997616

VM113:7 {"message":"Hello world!"} at 179.72430000007154

VM113:7 {"message":"Hello world!"} at 299.7203000000715

VM113:8 {onMessage: {…}, onDisconnect: {…}, disconnect: ƒ, …}

VM113:7 {"message":"Hello world!"} at 0.046600000023841855

VM113:7 {"message":"Hello world!"} at 119.82089999997616

VM113:7 {"message":"Hello world!"} at 179.82919999992848

VM113:7 {"message":"Hello world!"} at 299.88029999995234

VM113:8 {onMessage: {…}, onDisconnect: {…}, disconnect: ƒ, …}

VM113:7 {"message":"Hello world!"} at 0.06129999995231628

[Simeon Vincent]

We've completely diverged from the original thread multiple times at this point, so I'm going to lock this topic. Feel free to start another topic to continue any of the conversations happening here. 

Simeon - @dotproto

Chrome Extensions DevRel