stdout - A simple Chrome extension for console-logging *other* Chrome extensions

[FW Extensions]

https://github.com/fwextensions/stdout-ext  

I finally broke down and threw together this extension after banging my head trying to debug the transition from a persistent background page to a manifest v3 service worker.  I'd gotten it working while having the service worker devtools open the whole time.  Then I tested it with devtools closed, and... there were bugs.

But how to debug the service worker if having devtools open changes its behavior?  It's like trying to determine whether Schrodinger's cat is dead or alive without opening the box.  The best workaround I found was to log everything with console.error(), so the messages would show up in the extension details page without devtools being open.  But it's not ideal, as that page doesn't show timestamps, doesn't show repeated log messages, and objects are logged as [object Object].

So I finally tried sending log messages via runtime.sendMessage() to another extension, which could then render the messages without having the source extension's devtools open.  As long as the recipient extension sends a response back, the source service worker will still go inactive after 30 seconds.  So you can see debugging output while keeping normal service worker behavior.

Initially I tried using the console-feed component to render the messages in the stdout extension, but ran into issues with regenerator-runtime and its use of Function(), which doesn't work in an extension.  I belatedly realized the best console is the actual console, so the whole stdout "extension" is just a service worker with a single onExternalMessage() handler that redirects the incoming messages to the console.

Anyway, hope this helps other folks trying to debug the quantum weirdness of service workers.  To use it, you just need to load the unpacked stdout extension into Chrome and get its ID.  Then import a simple package and call stdout() with that ID.  After that, any calls to console.log() and whatnot will be forwarded to the stdout extension, where you can view the messages in its service worker's console.

[Cuyler Stuwe]

Pretty good idea! I suspect this will cause some of its own issues as well, but it’s a clever solution to get around some of the problems inherent to the platform and its native tooling. Here’s to hoping that Google works on the DX so that a tool like this will eventually become unnecessary.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/35815265-6e24-41dd-a34f-cb30e3040f7an%40chromium.org.

[FW Extensions]

> I suspect this will cause some of its own issues as well

Are there examples you can think of?  The only thing I saw was that the visible state of whether a service worker was active or inactive, as shown in the Extensions page, would sometimes not update immediately.  A page refresh always showed the correct state.  But I'm not sure if that had to do with cross-extension messaging or just that I'd had Chrome open for so long at that point and it was getting tired and confused.

[Cuyler Stuwe]

Well, it’s not necessarily that it would “break functionality”, but there are certain aspects of extension debugging you’re going to lose — breakpoint debugging, for example. You’re also going to lose the ability to click the line of code that generated a log in order to immediately see it in the sources panel. Things like that. So you’re going to end up with a sort of “fragmented” experience where something like this could be useful specifically for bugs that seem to involve the lifecycle of the service worker, but you have to use a totally different set of tools and debugging flow for anything requiring other tools.

[Max Nikulin]

On 09/09/2024 03:46, FW Extensions wrote:
> https://github.com/fwextensions/stdout-ext

>
> So I finally tried sending log messages via runtime.sendMessage() to
> another extension

I had a similar idea, but I have not tried to implement it because in my
cases chrome://serviceworker-internals/ was enough despite rather ugly
representation of console messages. (By the way, why it is not mentioned
in
<https://developer.chrome.com/docs/extensions/get-started/tutorial/debug>?)

Have you considered extracting current file and line number from `new
Error().stack`?

Another idea is to send
`self.addEventListener("unhandledrejection", ...)`
events (and may be "error" as well). It should reveal some failures
without explicit console logging. In addition I use
`try { ... } catch (ex) { Promise.reject(ex); }`
to have location where the exception is thrown instead of where it is
caught in collected errors.

I have noticed that `convertError` does not try to convert the `cause`
filed that may contain another `Error` instance. (Side note:
unfortunately AggregateError.errors is not supported in console.)

[FW Extensions]

>  So you’re going to end up with a sort of “fragmented” experience where something like this could be useful specifically for bugs that seem to involve the lifecycle of the service worker, but you have to use a totally different set of tools and debugging flow for anything requiring other tools.

Well, yeah, a little 50-line extension can't fix the Chrome extension platform and its DX. ;)