When I try to debug this script is not in the list, only the content script. On my file I have only the following test code, and obviously it is not working:
(function() {
/**
* Listen for messages from the background script.
* Call "beastify()" or "reset()".
*/
browser.runtime.onMessage.addListener((message) => {
});
function handleStartup() {
browser.tabs.create({
url: "https://giphy.com/explore/cat"
});
}
browser.runtime.onStartup.addListener(handleStartup);
})();
That’s a profile startup, so it won’t fire until the browser is restarted while addon is installed:
The background script source code is visible only from the background console - visit “about:debugging#/runtime/this-firefox” and click the “Inspect” button.
PS: You can use the debugger statement to automatically open source code in opened console window:
Is it possible to install a temp extension rather than run it in the debugger?
Also how do I run an event at startup, when the extension is activated (after being disbled) or when the browser starts for the first time? Is there an event when the extension starts? For example, in my case, to load data from the storage, such as settings, and saved elements to be re-used in general.
All extensions must be signed by Mozilla and this happens only when it’s released, so I’m not sure you can install temp extension.
To run a code at addon startup simply place it in the top of the background script. Since Firefox is using persistent background pages, the background script will be executed only once, when the addon starts, usually after you turn on the browser (but also after addon reload, for example after update).
Would be enough, but yes, wrapping it with IIFE is OK.
Regarding the Manifest V3 workaround, actually the “background script” will be executed as a Service worker, so the window is gone, DOM is gone, whole state is gone.
That’s why the workaround they suggest is using the new in-memory storage chrome.storage.session (btw: limited to 1MB )
Thinking about developing for both firefox and chorme at the same time, is it possible to just call chrome instead of browser and have just one versione, or necessarily need to have 2+ different versions, one for each browser?
Also, i must be missing stomething, still not executing the code for some reason:
//called inside the background script
function handleStartup() {
browser.storage.local.get(['color'])
.then(getColor)
.catch(reportError);
function reportError(error) {
console.error(`Could not process: ${error}`);
}
function getColor(result){
browser.runtime.sendMessage({command:'color',value: result.color});
}
}
If you like promises, it’s best to use browser namespace and in the Chrome use the web-extension polyfill:
It will allow you to use Promise-based API in both browsers.
But anyway, cross browser development is now pretty challenging due to Manifest V3 / V2 incompatibilities. All of my addons are still V2 and I plan to migrate to V3 as late as possible due to many complications.
I can’t tell what is wrong with the code you’ve posted, it doesn’t really do anything visible unless some other code is listening for the message - but how could it, the background script is usually executed before any other context so when the message is send, nobody will receive it.
Also, use the common debugging techniques to find out what is running when, use console.log, debugger statement, etc…
The runtime.onMessage.addListener callback has actually 3 parameters, the last one is callback sendResponse which can be used to send response: chrome.runtime | API | Chrome for Developers
This is more question about Promises VS callbacks since browser namespace provides Promise based API whereas chrome used to provide only callback based API.
I would say, Promises are far more superior to callbacks, especially when combined with async/await.
Manifest V3 in Chrome brings also Promise based API to chrome namespace, so if you don’t provide a callback, it will return a Promise.
However, regarding the polyfill library I’ve mentioned, I use it in all of my many addons for 5 years and it works perfectly with 0 issues. So I can 100% recommend “browser-namespace-first” approach .