Develop Reference

"A listener indicated an asynchronous response by returning true, but the message channel closed before a response was received", What does that mean?

I'm working on a React application and I use some npm modules, one of which I had to build myself. (my NPM package:
https://www.npmjs.com/package/modale-react-rm).
It is a simple modal that opens and closes with a useState().
After importing my package, I have an error in my console that appears suddenly after a few seconds without performing any actions.
Uncaught (in promise) localhost/:1
>{message: 'A listener indicated an asynchronous response by r…age channel closed before a response was received'}
message: "A listener indicated an asynchronous response by returning true, but the message channel closed before a response was received"
>[[Prototype]]: Object
>constructor: ƒ ()
>[[Prototype]]: Object
/* sometimes there are specific elements in addition but I could not check when they appear and when not */
Promise.then (asynchrone)
(anonyme) #content_script_bundle.js:108
handleNewFeatures #content_script_bundle.js:101
handleUpdatedNodes #content_script_bundle.js:101
(anonyme) #content_script_bundle.js:101
childlist(asynchrone)
0 #purplebox.js:1
(anonyme) #purplebox.js:1
v #purplebox.js:1
It doesn't block my pages, nor does it prevent the proper functioning of its features, but it's an error and I think it should be fixed and maybe help other people who have the same problem.
I specify that I do not make any async request in this project. Everything is local and the few data I use are directly imported in raw.
I don't know where Purplebox.js comes from as well.

This issue is a cross-origin request issue and it is caused by various Chrome Extensions.
I had this too in my Angular app and after testing it in the incognito mode, the error didn't show up anymore.
More info: Google Forum
/Edit:
If you are an extension developer coming here: You need to return true when fetching data from cross-origins. More info: Chromium Project

In my case, it is caused by Ghostery extension, if this error appears in your local host, you need to add it to the trusted sites list of Ghostery and the error will be gone.

It has been discussed in the webextension-polyfill library, which is used by many extensions (including Ghostery). There was a recent change in Chrome that introduced to the error message.
For projects that are using the polyfill, I would expect the warning to go away if a fix is merged. Note that the polyfill library is used, since only Firefox implements the new promised-based runtime.onMessage, while Chrome still enforces the original callback-style API.
Note that there is an open pull request in the webextension-polyfill library already. It has not been merged, but according to my tests, it solves the problem. So, if you need a quick fix for a project that uses the library internally, you can manually apply the patch with patch-package. For instance, this is how such a change would look like in Ghostery.

The background script (service worker in MV3) could be going to inactive state without sending a response back to a message it received from a content script.
Example:
Background script:
chrome.runtime.onMessage.addListener((request, sender, sendResponse) => {
// ... handle message
return true // Error message says you already return true
})
Most MV3 APIs are asynchronous and can return promises when it makes sense to do so. (In some cases, like event listeners (e.g.: chrome.tabs.onRemoved), returning a promise wouldn't make sense). Reading a response back however can be done using callbacks or promise-style.
Content script: method 1 to read response:
chrome.runtime.sendMessage('ping', (response) => { /* read response */ })
Content script: method 2 to read response:
chrome.runtime.sendMessage('ping').then(response => { /* read response */ })
The issue you are facing is this: background script does not invoke sendResponse() for one/more messages it received and went inactive (causing the message channel to close). However, the content script that sent the message is waiting for the response.
Please check your message senders & handlers.

I had the same error. I removed the Tampermonkey extension and tweaked my AdBlock extension and then it worked for me.

I encountered the same issue couple of days ago, and found out that the source of error is located in the background.js.
it's caused by the runtime Message Handler. to solve it, just add a third parameter as a callback function to chrome.runtime.onMessage.addListener.
forgot how i found the solution, but it works for me.
// to avoid the error, the parameter [sendResponse] is necessary!
chrome.runtime.onMessage.addListener(function(msg, sender, sendResponse) {
// do something ...
// this line seems meaningless but you have to invoke it to avoid error.
sendResponse({damn: true});
});

This error is related to ad blockers or similar. Just exclude the site for this application.
In my case it was AdBlock app. It kept showing this error in the console when working with LiveServer or FiveServer. It does not affect anything, but it is very annoying

I had the same error on my react app when i introduced an infinite loop through useEffect, the thing is that you most likely won't see too much change in your app or problem. For me it even helped reload some state for functions that i was still to write but over time it will introduce bugs and performance issues.

Avast Online Security & Privacy 22.11.173 is causing the same issue.

I had the same issue on my Windows 11 machine.
I added these lines at the bottom of the hosts file in the drivers/etc directory:
127.0.0.1 localhost
::1 localhost
This solved the problem for me.

I faced the same error. Where class Component didn't show any response over display.
Solution : Syntax error in spelling "render" => ~"rendor"~

SSE not working as expected on Heroku

It is the first time for me working with Server Sent Events and probably I'm doing something wrong... I just followed a few guides and doing code experiments and locally everything seems to work fine.
Unfortunately when I upload the app on Heroku it doesn't work as expected.
The Javascript looks like this:
// SSE Start
// Check if SSE is supported
if (!!window.EventSource) {
var source = new EventSource('/live/redis');
} else {
console.log('SSE not supported');
}
source.addEventListener('open', function (e) {
console.log('Connection Open');
}, false);
I'm using NodeJS and Redis to get real time messages from the API, but it doesn't matter...
When the SSE connection is open I just print a log on the browser.
I do nothing else at moment and if I open my app locally it just work fine and I receive the console.log message.
If I push the project on Heroku I don't receive any open connection message.
I can not understand why, probably something is missing or probably do I need to configure Heroku to support SSE?
If I open the project with the command heroku local it works fine as well...
EDIT:
From the Heroku logs I receive this:
app/web.1: GET /live/redis 500 86.403 ms - -
I can not understand why, locally it is working fine, on Heroku it isn't.

The error is on my Node.js controller for the route /live/redis that start with this line:
// let request last as long as possible
req.socket.setTimeout(Infinite);
Changing it with the line below solved my problem:
// let request last as long as possible
req.socket.setTimeout(0x7FFFFFFF);
Now I don't know if it is the correct way, but for now it is working.

Log JavaScript console into a log file with Firefox

We have a web application which runs in a kiosk mode Firefox, using the RKiosk extension to achieve this. We suspect that we have a very rare error in the system which yields in a JavaScript error. However because we can't access the JavaScript console we can't examine the log.
I'm searching for an option to make Firefox log all JavaScript console messages into a file regardless of the tab and page opened. I can't seem to find any extension for this. I'm already using log4javascript which sends errors back to the server, but it seems that our application crashes in a way that it skips the logging altogether.

Writing to a file sounds like a tedious task to me. It requires privileges that browser code doesn't normally have and you'd have to negotiate with an add-on you'd have to write in order to access file I/O.
From what I understand your issue is
I'd like to make Firefox log all errors
There are several approaches we can do to tackle this
First approach - log everything to localStorage too:
Now, rather than writing to an actual file, you can write to localStorage or IndexedDB instead.
localStorage["myApplog"] = localStorage["myApplog"] || "";
var oldLog = console.log;
console.log = function(){
oldLog.apply(console,arguments); // use the old console log
var message = "\n "+(new Date).toISOString() + " :: "+
Array.prototype.join.call(arguments," , "); // the arguments
localStorage["myApplog"] += message;
}
This is rather dirty and rather slow, but it should get the job done and you can access the log later in local storage. LocalStorage has a ~5MB limit if I recall correctly which I think is enough if you don't go crazy with logging. You can also run it selectively.
Second approach - log only errors
This is similar to what Pumbaa80 suggested. You can simply override window.onerror and only log errors.
// put an empty string in loggedWinErrors first
var oldError = window.onerror || function(){};
window.onerror = function(err,url,lineNumber){
oldError.call(this,err,url,lineNumber);
var err ="\n Error: (file: " + url+", error: "+err+", lineNumber: "+lineNumber+")");
localStorage["loggedWinErrors"] += err;
}
Third and drastic approach - use a VM.
This is the most powerful version, but it provides the most problematic user experience. You run the kiosk in a virtual machine, you detect an uncaught exception - when you do you freeze the machine and save its state, and run a backup VM instead. I've only had to do this when tackling the most fearsome errors and it's not pretty. Unless you really want the whole captured state - don't do this.
Really, do the extension before this - this is tedious but it gets very solid results.
In conclusion, I think the first approach or even just the second one are more than enough for what you need. localStorage is an abstracted storage that web pages get for saving state without security issues. If that's not big enough we can talk about an IndexedDB solution.
It all really depends on the use case you have.

You can use XULRunner...a Mozilla runtime environment for XUL applications. It uses Gecko like Firefox and:
You can access the file system or using the SQLite database to store logs.
You can render your kiosk in fullscreen mode without using extensions.

Have you tried jserrorcollector? We are using it and it works fine (only in Firefox). It's only for Java.
// Initialize
FirefoxProfile ffProfile = null;
ffProfile = new FirefoxProfile();
JavaScriptError.addExtension(ffProfile);
// Get the errors
List<JavaScriptError> jsErrors = JavaScriptError.readErrors(webDriver);
More information: https://github.com/mguillem/JSErrorCollector

Have you considered remote logging?
I commonly assign window.onerror to do send a request to a webserver storing the details of the error remotely. You could do the same with console.log if you preferred.

Try the following console export. It is a plugin for Firebug of Firefox. It's quite handy.
http://www.softwareishard.com/blog/consoleexport/

If you are able/willing to switch from Firefox to Chrome or Opera you would be able to use the Sandboxed Filesystem API to write a local file. See:
http://www.html5rocks.com/en/tutorials/file/filesystem/
http://caniuse.com/filesystem
Start in kiosk mode using chrome.exe --kiosk <url>
You would then want to disable Alt-F4 and Ctrl-Alt-Del which on Windows can be done with several third-party tools like Auto Hotkey (Disable Ctrl-Alt-Del Script).

You could use a remote logging script like Qbaka. It catches every JS error and sends it to the Qbaka server. There you can login and see all JS errors. Qbaka stores the exact error message, the script, line number, stack trace and the used browser for each error message.

WebSocket onmessage() not being called when messages are sent

I'm using autobahn 0.4.10 (https://github.com/oberstet/Autobahn) as a WebSocket server to send messages to a Google Chrome Extension. I am able to open and close connections using WebSocket(), but when I call autobahn.websocket.WebSocketServerProtocol.sendMessage() the message appears to be sent but isn't delivered until the connection is closed.
The api for WebSocketServerProtocol's sendMessage() (derived from WebSocketProtocol) can be found here: http://www.tavendo.de/autobahn/doc/python/websocketprotocol.html#autobahn.websocket.WebSocketProtocol
Has anyone experienced this problem before?
The code I have been on the client side is (js):
ws = new WebSocket('ws://localhost:4444');
ws.onmessage = function(event) {
console.log('hii');
}
And on the server (python)...
#json is a string object
def sendEvent(self, json):
print 'to', self.peerstr
self.sendMessage(json, sync=True)
Both Autobahn and my version of Chrome (17.0.963.46) appear (from what I've gotten out of the headers and docs) to use version 13 of the WebSocket draft protocol.

Turns out this was a threading problem with some threads block the twisted reactor.
See:
http://groups.google.com/group/autobahnws/browse_thread/thread/6bf0c43ec169efc3#
http://twistedmatrix.com/documents/current/core/howto/threading.html

Autobahn works with Chrome (tested up to v19 .. Canary).
Could you try the
https://github.com/oberstet/Autobahn/blob/master/demo/broadcast/broadcast_server.py
demo to see if you have a general issue?
If that runs, direct your extension to that demo server .. it'll send you 1 tick per sec.
You can also enable debug output by changing the factory line to code like this
https://github.com/oberstet/Autobahn/blob/master/demo/echo/echo_server_with_logging.py#L50
2 more notes:
you don't need the sync = True option (it's really an advanced option .. mostly used with the Autobahn WS testsuite)
you might wanna join http://groups.google.com/group/autobahnws .. get answers more quickly .. I discovered your Q only by accident here
Disclosure: I am author of Autobahn and work for Tavendo.

App Engine Channel API's Javascript Client Isn't Using my onError Callback

I'm using App Engine's Channel API to maintain a connection between a Chrome extension and an App Engine app. You can see my Channel-related code here: https://github.com/2cloud/Chrome/blob/3fe70262ef69ae8286a057055f4108760560c47e/socket.js (The app is open source, so you can check out the repository to get an idea of how it all fits together)
My issue is, for some reason, the 401 error that App Engine throws when a token expires isn't being sent to my onError listener. I've tried just logging the error object from within onError, outside of an if statement, and still got nothing. My conclusion was that onError isn't getting called when a 401 is thrown, as the documentation says it's supposed to.
Has anyone else seen this error? Does anyone else have an idea on how to fix it?

I've reproduced this bug and started work fixing it. http://code.google.com/p/googleappengine/issues/detail?id=5685