SendResponse from background script not being received by content script

Add-ons Add-on Support
21

I’ve adopted Search Result Previews. I noticed that Scroll Anywhere has many users. Well done!

1 Like
22

Good choice! And thank you for your donation!

It’s actually my second addon with a paid features, but not very successful. If you create an account on my server there, I’ll give you fee Pro license :slight_smile:.

1 Like
23

Most of this is moot, but I figured I’d share feedback on coding practices anyway :wink:

If you’re not going to use the sendResponse parameter you should also remove it from the function declaration. Normally this isn’t necessary as the existence (or lack thereof) of a parameter doesn’t have a functional impact but unfortunately it does here. I forgot to call it out, but in the example extension I shared in my last post the “out of scope” error is not logged if you omit the sendResponse parameter. Fun times! :upside_down_face:

Also, the updated code you shared in this comment does not always call sendResponse(). There are a couple of cases in the switch statement that cause the function to return/throw before the sendResponse() call near the end of the function would be able to execute. In those cases you would still see the “out of scope” error.

1 Like
24

Simeon, I hope you agree that this “sendReponse” API that requires you to return true and has bunch of edge cases is not greatly designed. Not to mention some exception handling and then checking global lastError property :smiley:, which is totally crazy design choice I’ve never seen anywhere else :upside_down_face: .

If you have still some power in the Google ecosystem, please make them implement the missing Promise returning version :slight_smile:.

25

Yeah, I’m not wild about sendResponse in the extension message passing APIs. As seen here, I think it’s a bit too hard to use correctly and I agree that the promise-based approach is more likely to work as expected for developers.

At TPAC 2024 we briefly discussed promisifying the message passing APIs. I think all browser vendors were on board with the idea but there were no concrete plans to implement the change in Chrome. FWIW, I also want to see this land.

1 Like
26

I’ve been stuck on a similar issue and have tried adapting some of what @juraj.masiar said but without success. I’d appreciate any help. I’m using manifest V3. The value i’m receiving in my content script is always undefined.

Content script:

var messageResponse = await browser.runtime.sendMessage({ action: 'GetSellers' });
console.log(messageResponse);

Background script:

async function getSellersAsync() {
    const response = await fetch('https://myapi.com/api/sellers');
    const data = await response.json();
    const usernames = data.map(seller => seller.username);
    return usernames;
}

browser.runtime.onMessage.addListener((message, sender) => {
    if (message.action === 'GetSellers') {
        return getSellersAsync();
   }
    return false;
});
27

If you are always getting undefined, it usually means there is another runtime.onMessage handler in your codebase with a async function handler - which means it always returns a promise and thus always sends an undefined response to the caller. You see, once one of your handlers replies to the message, other handlers won’t receive the message anymore, because it was already “processed”.

To help you debug, you can place a console.log into each of your handlers to help you see which are receiving your messages.

1 Like
28

That was the issue… Thank you for the help.

1 Like