Subject: Research: What is the most frustrating bottleneck in your Chrome extension development workflow?

[Jdu Uy]

Hi everyone,

I'm interested in learning from experienced Chrome extension developers about the real challenges they face during development, testing, publishing, and maintenance.

I'd really appreciate your insights:

1. What is the most frustrating or time-consuming problem you regularly encounter while developing Chrome extensions (for example, Manifest V3 migration, API limitations, debugging, testing, Chrome Web Store publishing, or anything else)?

2. How do you currently deal with this problem?

3. If an ideal developer tool or Chrome extension existed to solve it, what features would it need?

4. Is this problem significant enough that you would use such a tool regularly? If so, what would make it truly valuable to you?

I'm not promoting any product or service. I'm simply trying to better understand real developer pain points and learn from the community.

Thank you for taking the time to share your experience. Your feedback is greatly appreciated.

[woxxom]

The inability to use HMR (hot module reloading) in the background script or reload it without reloading the entire extension in MV3, which closes all of its tabs and popups so we have to reopen everything or just use devtools snippet to copypaste the code manually. This sets back development of extensions 15 years back to the ancient times before MV2. Still not fixed even though there are several ways to fix it. The official reason is that this is how service workers are, but then again extensions never needed a service worker, the same level of performance improvements could have been achieved with the event pages that support normal debugging experience and hot module reloading. Theoretically though it might be possible to develop a CDP debugger that runs code dynamically in the service worker context effectively implementing HMR. It's worth exploring because I don't expect Chromium team to help us in something they consider WAI.

Similarly, service worker restrictions that are entirely irrelevant for already locally installed extensions prevent us from importing local scripts from the extension package dynamically in a response to event in the service worker. The only clunky workaround today is to use importScripts() inside onactivate event for every script you will ever need to import later so that the browser remembers this code as local, an utter redundancy in case of already local extensions.

There's also a bug that crashes the browser if you open Application tab in devtools attached to an extension service worker and reload the extension. The workaround is either to patch resources.pak or crash the browser enough times to make your brain develop an evasion pattern for the Application tab.

A minor inconvenience is the official chrome-types package's defining of types as literal objects on the callbacks for the events like chrome.webNavigation.onCommitted which makes it seemingly impossible to use on a callback function declared separately and not as an inline callback of the event, at least I couldn't exfiltrate the type via Parameters<> and anyway such trickery shouldn't be required.

As for the API, there are many things to fix/improve that are discussed in https://github.com/w3c/webextensions/issues/

[woxxom]

Correction, it's oninstall event for importScripts: https://stackoverflow.com/a/66408379