Beta InboxSDK on npm with MV3 Support

4069 views
Skip to first unread message

Chris Cowan

unread,
Nov 19, 2021, 9:10:37 PM11/19/21
to InboxSDK

With Chrome moving to require extensions to use Manifest Version 3, extensions will no longer be able to remotely load executable code, which affects extensions using the InboxSDK. The InboxSDK has relied on remotely-loading code from our servers to keep every InboxSDK-using extension on the latest version in a timely and hassle-free manner. Moving forward to MV3 support means moving away from remotely-loading code and changing how we distribute the InboxSDK.

Launching today

Starting now, a MV3-compatible beta build of the InboxSDK is available through the NPM package manager as the “@inboxsdk/core” package. We’re choosing to publish using the NPM package manager to allow developers to use standardized tooling to keep themselves on the latest version of the InboxSDK, and to better integrate with modern NPM-compatible Javascript build tooling such as Webpack, Parcel, etc. The NPM package contains Typescript type definitions too for Typescript users!

We’ve updated an example at https://github.com/InboxSDK/hello-world/tree/mv3 showing one way of how to build an extension using the InboxSDK through NPM with the Parcel bundler. Do let us know if you have any questions about the example. We’re interested in helping developers make use of this in their projects, and we’re also interested in figuring out if there’s anything we can do on our end to make it easier for developers to work with.

We encourage developers to use tools such as Webpack or Parcel, and we imagine many developers are already, but for developers who are not using any build tools that are compatible with NPM modules, you can access an MV3-compatible drop-in replacement “inboxsdk.js” file at https://unpkg.com/@inboxsdk/core@latest/inboxsdk.js. You can replace the inboxsdk.js file you already have in your project with this one.

Changes to updates

Because the InboxSDK is losing its ability to remote-load code in this MV3-compatible version, it will become necessary for developers to release an extension update whenever they need a new version of the InboxSDK. This might mean that if Gmail makes a change that introduces a bug with the InboxSDK, developers of affected extensions will need to pull the latest version of the InboxSDK and release a new version of their extension containing it. It’s possible for developers to use tools like Dependabot to alert them when there are new versions of the InboxSDK published on NPM. We’re interested in discovering and documenting other ways to communicate to developers about updates to the InboxSDK, so let us know if there’s a different workflow that works well for you. Any critical updates to the InboxSDK will be announced on this mailing list in addition.

The future

The previously-released non-MV3 remote-loading version of the InboxSDK will stay accessible and maintained as long as possible. If you currently have a pre-MV3 Chrome extension deployed, then the InboxSDK will continue to work in it as-is as long as Chrome continues to allow pre-MV3 extensions.

The MV3 version of the InboxSDK is not allowed by the Chrome team to remote-load code, but the Chrome team does allow extensions to remote-load declarative configuration, so we’re planning on making the InboxSDK remote-load configuration from our server. This will allow us in some cases to update the DOM selectors used to find specific Gmail elements in the page without needing extension developers to update their installed version of the InboxSDK or deploy a new version of their extension.

Abby

unread,
Nov 20, 2021, 4:13:35 AM11/20/21
to InboxSDK
Hi Cris,

Exciting news, 
We're interested in helping you in testing and finding a way to communicate to consumers about new releases or however we can.

I started testing the package and found some missing types,  like `getFromContact`, `getHTMLContent`, and `destroyed` missing. Would it be a good idea to use some issue tracker so you guys can better triage and fix the reported bugs?

Looking forward to hearing from you

Abby

unread,
Nov 20, 2021, 5:10:38 AM11/20/21
to InboxSDK
Although now I am loading the script from package, it still tries to load the script from remote

var n = [];
          r ? n.push(t.replace(/\/\/# sourceMappingURL=(?!data:)[^\n]*\n?$/, "")) : n.push(t), n.push("\n//# sourceURL=https://www.inboxsdk.com/build/injected.js\n");
          var o = n.join("");
          e.text = o, document.head.appendChild(e).parentNode.removeChild(e), document.head.setAttribute("data-inboxsdk-script-injected", "true");

Hence breaking V3 Compatibility, any ideas on this?

Abby

unread,
Nov 20, 2021, 5:22:09 AM11/20/21
to InboxSDK
https://github.com/InboxSDK/hello-world/blob/mv3/static/manifest.json

"manifest_version": 2
So I am not sure if it would work on v3 at all!

Amiram Korach

unread,
Nov 20, 2021, 2:31:32 PM11/20/21
to Chris Cowan, InboxSDK
Hi Chris,
Google was approving our versions very quickly in the past. Recently it started to take days. I hope they'll make it short from now on, otherwise we might be in trouble if there is an urgent fix.
Your ts file misses a few definitions. For example for ComposeView: destroyed, getHTMLContent(), getTextContent(), isMinimized, isFullScreen, setMinimized(), send(), getFromContent(). We can finally drop @types/inboxsdk when yours is complete.
I suggest we close this group and move to github issues tracker, together with using github for the source. This will be very helpful for all of us.
Keep up the good work!

Amiram

--
You received this message because you are subscribed to the Google Groups "InboxSDK" group.
To unsubscribe from this group and stop receiving emails from it, send an email to inboxsdk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/inboxsdk/f830c971-a53c-48ef-bb46-f3416728d336n%40googlegroups.com.

Abby

unread,
Nov 20, 2021, 3:48:30 PM11/20/21
to InboxSDK
@Amiram

Did you managed to get it to work from @inboxsdk/core with MV3?

Amiram Korach

unread,
Nov 20, 2021, 3:50:26 PM11/20/21
to Abby, InboxSDK
I Haven't tried yet. Waiting for types to be fixed.

Abby

unread,
Nov 23, 2021, 3:36:06 AM11/23/21
to InboxSDK
@Chris Any updates on this?

Abby

unread,
Nov 29, 2021, 3:29:29 AM11/29/21
to InboxSDK
Hi folks, 

Can you please provide an update on this?

glr...@gmail.com

unread,
Nov 29, 2021, 11:21:01 PM11/29/21
to InboxSDK
Hello everyone,

I tried the sample mentioned by Chris. But it seems the sample is based off Manifest v2. 
I also tried changing the manifest to support v3, but the extension did not work anymore.

Any updates?

Thank you.

Abby

unread,
Nov 30, 2021, 3:54:39 AM11/30/21
to InboxSDK
Same, I fixed the missing types, updated manifest to v3 but the problem is that package still tries to remotely load the script.

Juan Pablo Piedrahita

unread,
Dec 2, 2021, 4:14:37 PM12/2/21
to InboxSDK
I'm currently having the same issue as Abby, I fixed the type errors by creating an inboxsdk.d.ts file with:

import '@inboxsdk/core';

declare module '@inboxsdk/core' {
interface SendOptions {
sendAndArchive?: boolean;
}

export interface ComposeView {
send(options?: SendOptions): void;
}
}

but the script is still trying to be loaded from a remote location, so I'm getting an error saying: Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-T+yIhYmIzfgSMlQO/CT7+7ErSqEY2+9uxDxkAVaiFMo='), or a nonce ('nonce-...') is required to enable inline execution.

in my content script. The example repo still has manifest version 2, so I'm not really sure if the correct code was pushed to that branch or if the npm package has been tested at all.

+1 for the issue tracker idea.

Abby

unread,
Dec 13, 2021, 8:04:15 AM12/13/21
to InboxSDK
Any updates on this? It's been a while since the announcement was made.

Abby

unread,
Dec 16, 2021, 3:32:13 AM12/16/21
to InboxSDK
Hi Chris,

Can you please look into it? It's almost a month.

Thanks

Chris Cowan

unread,
Dec 17, 2021, 10:53:34 PM12/17/21
to InboxSDK
Thanks for the feedback and reports. We're going to have a new release on Monday addressing these issues, and we're going to start putting out more regular updates to the package.

Abby

unread,
Dec 20, 2021, 3:48:30 AM12/20/21
to InboxSDK
Thanks Cris, 

Eagerly waiting for the new release!

Cheers

Abby

unread,
Dec 22, 2021, 4:36:59 AM12/22/21
to InboxSDK
Hi Cris,

I still see no updates on the npm, do you plan to release sometime this week?

Cheers

Aleem Mawani

unread,
Dec 23, 2021, 2:25:54 PM12/23/21
to Abby, InboxSDK
We had to make some more changes to make sure the SDK was MV3 compatible. Those changes should hit NPM in the next few days.


--
You received this message because you are subscribed to the Google Groups "InboxSDK" group.
To unsubscribe from this group and stop receiving emails from it, send an email to inboxsdk+u...@googlegroups.com.

Abby

unread,
Dec 24, 2021, 8:45:02 AM12/24/21
to InboxSDK
Thanks for the updates Aleem, looking forward to it!

Chris Cowan

unread,
Dec 30, 2021, 8:30:41 PM12/30/21
to InboxSDK
We've released a new version (0.2.1) of the InboxSDK on NPM now! It comes with a few breaking changes in order to get all of our functionality to properly work with MV3. Because of Chrome MV3 changes, an extension background script is now required for us to properly inject some code to fully interact with Gmail. We've also fixed some oversights in our Typescript type definitions.

The example at https://github.com/InboxSDK/hello-world/tree/mv3 has been updated for the latest InboxSDK with a simple Webpack setup.

If you are trying to adapt a build process where you're not using Webpack, then the important change is that you must copy the "background.js" and "pageWorld.js" files from the npm package into your extension, and configure the manifest as shown in the example. Please let us know if you have any questions about this! We're working on our documentation and we're interested in whatever pain points there are in this.

Abby

unread,
Dec 31, 2021, 4:49:46 AM12/31/21
to InboxSDK
Hi Cris

Looks promising, I gave it a spin in our extension and everything seems to be working fine.

Cheers
Abby

Abby

unread,
Jan 4, 2022, 2:05:24 AM1/4/22
to InboxSDK
Hi guys,

So we gave it a try and things seems to work fine and we'd like to go to Production with v3 implementation. Do you think it's a good idea? Is the library ready for Production?

Cheers

Guzman Rejon

unread,
Jan 7, 2022, 1:08:09 PM1/7/22
to InboxSDK
Is InboxSDK compatible with Microsoft Edge and/or Firefox?

Regards,

Guzman Rejon

unread,
Jan 10, 2022, 3:38:24 PM1/10/22
to InboxSDK
In our project we are not using Webpack.
We have copied the files: "background.js", "pageWorld.js" and "inboxsdk.js" from “@inboxsdk/core” NPM package and we have included them in the project.

Our project uses the javascript function XMLHttpRequest () and when invoking it we get the following error:
Error in event handler: ReferenceError: XMLHttpRequest is not defined

How can I fix this error?

Regards,

Chris Cowan

unread,
Jan 10, 2022, 6:35:43 PM1/10/22
to InboxSDK
It's fine to use this in production, but it's important to understand that this version does not remote-load updates automatically as our previous non-NPM version did, so if Gmail makes a breaking change or an urgent bugfix becomes necessary, you will be required to update the version of the InboxSDK your project depends on and then release an extension update yourself.

To help avoid issues from this, we are working on making the InboxSDK remote-load some configuration data, so we can push out updated configs to users of the InboxSDK immediately which will let us work around certain kinds of Gmail changes. A future version of the InboxSDK NPM package will support this.

Given that pre-existing Chrome extensions are allowed to continue using MV2 and continue to remote-load code for another year, you might find it better to stay on the non-NPM remote-loading version of the InboxSDK for now.

Chris Cowan

unread,
Jan 10, 2022, 7:04:47 PM1/10/22
to InboxSDK
I think your problem is that you need to set up the manifest.json as the example extension does in https://github.com/InboxSDK/hello-world/tree/mv3/static. I believe that error would happen if background.js did not run.

Abby

unread,
Jan 11, 2022, 2:57:04 AM1/11/22
to InboxSDK
Hi Cris,

Thanks for your reply. It's clear to me from initial post that remote loading updates are not possible. However I am asking more updates on the current state of library itself. For instance, the types coming from @inboxsdk/core are still not quite correct. The definition of getDraftId and getCurrentDraftId are switched. I am wondering if the npm package will also be maintained actively? Also did you guys at streak also switched on MV3?

Cheers
Abby

Guzman Rejon

unread,
Jan 11, 2022, 9:47:47 AM1/11/22
to InboxSDK

Hi Cris,

XMLHttpRequest is a browser api; it's not native to node.

You plan to publish  the MV3 version of the InboxSDK non-NPM?

Regards,

Chris Cowan

unread,
Jan 12, 2022, 2:09:46 PM1/12/22
to InboxSDK
Thanks for reporting the issue with the getDraftId types. We'll have that fixed in the next release.

The code in the NPM package is the same code as our previous non-NPM release, except that it doesn't remote-load code and that it has the brand new Typescript type-definitions included. The errors discovered in the Typescript type-definitions do not correspond to any newly-introduced issues in the actual code.

The NPM package will be updated every time we update the non-NPM remote-loading release.

Our own Streak extension is currently continuing to use MV2 with remote-loading of code.

Chris Cowan

unread,
Jan 12, 2022, 2:11:38 PM1/12/22
to InboxSDK
Our code has a variable named "XMLHttpRequest" that may be null at runtime if the background.js and pageWorld.js files aren't correctly configured to execute. We'll see if we can put a better error message for handling that case.

Abby

unread,
Jan 14, 2022, 7:05:48 AM1/14/22
to InboxSDK
Hi Cris,

Thanks a lot for reply. We will wait for next release and may be go live with MV3 after that.

Cheers

ffau...@allego.com

unread,
Jan 14, 2022, 3:01:31 PM1/14/22
to InboxSDK
I have been working on porting our extension over to MV3 using the beta (currently 0.2.1) and wanted to call out a few stumbling blocks incase it helps anyone else. (We are going to stick with MV2 in production for a long time, this was just for testing the beta.) 

Background: We are using webpack to bundle this extension.

Issue #1 - Simply doing "import * as InboxSDK from '@inboxsdk/core';" in the content script is not enough. Work needs to be done in the background service worker to inject pageLoad.js, and pageLoad.js needs to be accessible. In the sample repository this is being handled in webpack.common.js with the pageWorld and background entry points.

Issue #2 - My extension already had a background page that needed to be ported over to be the one and only background service worker, so I cannot just copy background.js like the sample repository. Instead I had to add the scripting permission to my manifest and add some logic to my existing chrome.runtime.onMessage.addListener block:

if (request.type === "inboxsdk__injectPageWorld" && sender.tab) {
        chrome.scripting.executeScript({
                target: { tabId: sender.tab.id },
                world: "MAIN",
                files: ["pageWorld.js"],
        });
        sendResponse(true);
}

Question for the InboxSDK team - is that code I added final / stable, or will you be providing some other way of doing this?

-Frank

Abby

unread,
Jan 17, 2022, 7:46:50 AM1/17/22
to InboxSDK
Hi Frank,

For issue two, I've addressed it by importing the background.js in my background script

// eslint-disable-next-line import/no-unassigned-import
import '@ inboxsdk/core/background.js';

Hope this helps!

Cheers
Abby

Abby

unread,
Feb 4, 2022, 2:09:26 AM2/4/22
to InboxSDK
Hi Cris,

I was wondering when you're gonna make the new release with fixes mentioned earlier in thread.

Cheers
Abby

Laura Gutierrez

unread,
Feb 9, 2022, 7:33:51 AM2/9/22
to InboxSDK
Hello,

I am migrating my extension from MV2 to MV3. I have tried both options: including the new inboxsdk.js in my package and using the npm package compatible with MV3.
The result: InboxSDK is not working at all. 

For the case of loading the new inboxsdk.js file, when calling InboxSDK.load(), it never returns the promise (without an error giving a clue).
For the case of the npm package, according to the example, it seems that apart from installing it, the background and pageWorld inside the package should be added in the background and content scripts of my project. That results in an "Invalid left-hand side in assignment" error when it tries to inject the pageWorld.js file. If I avoid adding this file as a content script, the result is similar to the first option (InboxSDK.load() not working).

So, any help with this? is this something already reported? I am totally blocked, so I would like to know if a new version will be released in the recent future or if this will be resolved, because if not, I will have to remove the library from my project, what would be a mess.

Thanks for any info or feedback

Laura Gutierrez

unread,
Feb 9, 2022, 8:59:29 AM2/9/22