Chrome Extension - migrating to V3 with respect to global variables and native messaging ports

user_678412 0
Viewed 923

I am just starting to look at the V3 manifest requirements and had the following questions.

  1. I currently have in my background.js var settings = new usersettings(); usersettings fetches all the settings from chrome.storage.local once and then if a setting property is changed then saves it back to storage.

    Do I understand it correctly that with V3 each time I need a value from settings I need to use for example chrome.storage? Further is/will the only way to retrieve storage be the following;

    chrome.storage.local.get(['key'], function(result) {
console.log('Value currently is ' + result.key);
});

    I am not a professional software engineer but using the above code each time I need to read a boolean setting seems very inefficient and is going to not only slow down the extension but also create a lot more code. I read that V3 will take advantage of promises is this something that can be used with chrome.storage.local.get?

  2. I use a native messaging host. I call chrome.runtime.connectNative when the background starts up and hold the port open meaning that the Native Host which Google Chrome starts also runs. I cannot find anything on how native messaging is supposed to work with service workers. Is chrome.runtime.connectNative even useful anymore with service workers? Will the native host start and stop with the service worker? If it does how can any native code send messages to the Extension?

  3. Is the following strategy a good idea? Is a Manifest V2 with background "persistent": false the same as a service worker? In other words instead of doing a major change to V3 could I first get my code running in V2 with a non-persistent background.js?

  4. My native host passes some javascript to my extension which in turn adds it via the script tag. I read that in V3 that javascript cannot be retrieved by an external source. Has anyone seen anything from Google on whether the native host will be treated as an external source? On the one hand I of course can see that by definition native host code is external, however, a native host has (at least for a windows PC) much higher installation standards and user rights requirements than an extension that gets code from some external url. This is the reason for my question.

  5. Anyone got a crystal ball on when a V2 update will be rejected?

google-chrome-extension
2 Answers

TL;DR ManifestV3 is still a semi-broken toy that can't handle many nontrivial scenarios.

with V3 each time I need a value from settings I need to use chrome.storage

  • Yes.

    If your data object isn't big it shouldn't be a problem.
    If in doubt, use devtools profiler or performance.now() in your code to measure the impact.

native messaging host

Is a Manifest V2 with background "persistent": false the same as a service worker?

  • Yes, conceptually.

    However, there may be differences due to the inferior nature of service workers as this is still an immature Web technology so it doesn't support things we grew accustomed to such as dynamic script loading, ES modules, clipboard handling, DOM parsing, and a lot more.

instead of doing a major change to V3 could I first get my code running in V2 with a non-persistent background.js?

  • Yes, it's a good start especially since ManifestV3 is still in development.

My native host passes some javascript to my extension which in turn adds it via the script tag.

  • Definitely forbidden.

    This code is not a part of the extension package so it can't be verified by the web store reviewers.

    An alternative will be revealed when Chromium team announces their solution for Tampermonkey and similar extensions that allow installing external userscripts.

    Meanwhile, try switching to a declarative approach: create rule definitions in JSON which will be processed by your extension code.

when a V2 update will be rejected?

  • Probably next year.

    There's no official announcement yet but if Chromium developers have a bit of conscience they won't disable ManifestV2 until they fix all or most of the problems in V3, which will probably happen next year.

    There's almost no active development currently for ManifestV3 problems though (other areas such as DevTools see ~100 times more meaningful activity) and seeing how Chromium team has been factually ignoring most of feedback from extension authors for the past five years, it's not exactly encouraging...

user_39598750
user_168573850
Related