In Bug 1792559 we have applied fixes to the WebExtensions internals (in particular to BaseContext's applySafeWithoutClone method) to make sure to log an error with the category "content javascript" and the same innerWindowID actually associated to the BaseContext instance related to the extension API event listener.

Bug 1792559 was tracking the issue related to the exception being thrown by a non-async listener, but if the listener is defined as an async function then an exception raised from inside the async function will be automatically converted into a rejected promise being returned and so from a caller perspective the call was successful and our internals propagates the rejected promise to the parent process.

Besides API events related to the extension messaging APIs, where the rejected promise will be propagated on the other side of the communication channel (e.g. if runtime.onMessage async listener rejects, then the call to runtime.sendMessage will return a rejected promise, if the rejection is not handled by the extension itself then it would be logged for that extension context) a rejected promise will be received by the API internals running on the parent process and eventually an error logged in the BrowserConsole (but not directly visible in the AddonDebugging toolbox because the error being logged wouldn't be associated to the innerWindowID of the context that have originated it).

As an example for the case mentioned in comment 24 related to WebRequest API events, the rejected promise are going to be propagated to WebRequest.jsm, where HttpObserverManager.applyChanges await on the promise and will be then logging the error on the BrowserConsole (from the catch block here in WebRequest.jsm).