Blog post: Chrome Manifest V3 extension development advice

[Dave Vandyke]

Hey everyone,

I've just written a blog post with some tips and advice for Chrome MV3 extension development. I thought I'd share it here in case it helps anyone.

Shout if you have any questions or feedback!

Cheers, Dave.

[Jackie Han]

Good article!

I would like to point out that your "createContextMenu" has a bug.

function createContextMenu(createProperties) {
  return new Promise((resolve, reject) => {
      chrome.contextMenus.create(createProperties, () => {
        const lastError = chrome.runtime.lastError
        if (lastError && lastError.message &&
            !lastError.message.startsWith("Cannot create item with duplicate id")) {
          reject(lastError);
        } else {
          resolve();
        }
      });
  });
}

You create a context menu and ignore the "duplicate id" error. For example, when you publish a new version, and you want to change the context menu's title, above code will fail to update it since "duplicate id".

Although there is a contextMenus.update() method, there is no contextMenus.get() method. So to update a context menu, I do it with contextMenus.remove/removeAll() then contextMenus.create() .

About the alarm use case: 

Check that alarms don’t already exist before adding them. Otherwise, if you set an alarm for five minutes time, the Background ServiceWorker will restart before it fires. At that point, the alarm is recreated (no errors) for five minutes time again. This repeats ad infinitum, and five minutes never comes!

This is because you set the alarm when the service worker starts. Most use cases, setAlarm happens on an event, not on startup.

--
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/173dd78e-4b14-4805-b9a5-d55ee5a871a0n%40chromium.org.

[Jackie Han]

I opened a new issue for creating or updating contextMenus in a single call at WECG.

https://github.com/w3c/webextensions/issues/312

[wOxxOm]

>  While you’re inspecting the Background ServiceWorker (e.g. have the background console open), the ServiceWorker will persist much longer (possibly forever). That makes testing the Background ServiceWorker lifespan tricky since you can’t view errors as they show up in the console until after the ServiceWorker was restarted, but by then, the errors are lost! What can you do? Well, instead of using the debugger or normal logging, use console.error.

An arguably much better workaround is to open any page of your extension in a separate tab or just open chrome-extension://id/manifest.json. Then open its devtools where you will see all SW errors printed during its lifetime including the startup and you can also manually start/stop the SW in Application -> "Service Worker" section.

[Dave Vandyke]

Thanks for reading and thanks for all the feedback! 😎 I've added a link to this discussion in the post.

Cheers, Dave.

[wOxxOm]

It would be helpful if you could write an article in the main extension documentation site about using `priority` to construct complex conditions. Hopefully even to imitate regexFilterExclude.

[Dave Vandyke]

Interesting, I would be open to writing more it's something I can get my head around. I'm not sure I follow about regexFilterExclude though, could you maybe give me an example of what you mean?

[wOxxOm]

Well, in webRequest it was possible to exclude URLs that match a JS regexp inside the callback and the ModHeaders extension was using it. I wonder if the same is possible via declarativeNetRequest at least in some simple cases.

[Dave Vandyke]

Ah right, I see what you mean. Yea, I think you could do something like that by combining multiple declarativeNetRequest rules. You could have a blocking/redirection rule that matched the request, then an allowing rule with a regexFilter condition to allow the request again. You could hit problems if you had other rules that should also maybe apply to the request though, for example if you also wanted other blocking/redirection rules to potentially apply to that request, you'd have to make sure they had a higher priority than the regexFilter allowing rule.

Good idea, thanks I'll give it some thought and see if I can draft something.