0

Considering the following example, what would happen when data is updated?
Since it is an object, will the reference remain and the update be reflected in the contextMenus.onClicked process?

// background service worker

let data = { ... };

chrome.contextMenus.onClicked.addListener(onClicked);
function onClicked() {
  // some process that uses data
}

chrome.storage.onChanged.addListener(onChanged);
function onChanged() {
  // update data
}

If SW gets restarted on onChanged.addListener, and run fresh, would that mean updating data would not be the right approach and the code should create a new data?

erosman
  • 7,094
  • 7
  • 27
  • 46
  • 1
    There is only one process within any given JS environment (a page, frame, worker), so the reference is the same for all code that uses it. I guess you were misled by the poor MV3 documentation that tries too hard to glorify the stupid changes they've made to background scripts. Everything is much simpler: [the entire script runs each time](https://stackoverflow.com/a/73208288). – wOxxOm Oct 04 '22 at 17:10
  • 1
    Does this answer your question? [Does the entire code in the top level of the manifest v3 service worker run repeatedly every time it wakes up?](https://stackoverflow.com/questions/73206468/does-the-entire-code-in-the-top-level-of-the-manifest-v3-service-worker-run-repe) – wOxxOm Oct 04 '22 at 17:12
  • @wOxxOm Tnx. According to Firefox engineers, they create listeners in a different context, thus bg in event pages will just be a template. In any case, even if the bg SW is re-run in Chrome, what would happen to `data`? Will `onClicked` be using the pre-update or post-upate `data? If `onChanged.addListener` wakes up SW and then will it be necessary to create a NEW UPDATED `data`? – erosman Oct 04 '22 at 17:30
  • 1
    There will never be different contexts in different listeners in Chrome's ManifestV3 service worker. They all run in the same context as the entire script per the definition of the standard JS processing model, so those engineers must have meant something else or they will simply break all normal JS code expectations. All variables will be created and initialized by your code at the beginning when the script runs again. The answer I've linked explains the sequence. See also [this example](https://stackoverflow.com/a/73090402). – wOxxOm Oct 04 '22 at 18:41
  • @wOxxOm I was referring to the many contexts to run JS in, browser context, privileged extension (e.g. option page), limited privilege extension (e.g. content), webpage, userscripts as well as SW (without the same window as the options page) etc. In Firefox, AFA I understand, they work on persistent listeners in the event pages. – erosman Oct 04 '22 at 19:20
  • 1
    A listener as a JS entity (function reference) is a unique value which can exist only in one context, so it doesn't matter how many other contexts exist and it doesn't influence persistence or data binding. The thing you imply just doesn't exist in JS, so if somehow Mozilla implements this, it'll be something incompatible with standard JS code and certainly incompatible with ManifestV3 in Chrome or all service workers in general. – wOxxOm Oct 05 '22 at 00:03
  • 1
    I guess Mozilla might be working on implementing an internal persistent id for each listener that allows to invoke it correctly after the background script restarts, same as Chrome has been always doing it for their event pages in MV2 and service worker in MV3. – wOxxOm Oct 05 '22 at 00:21

0 Answers0