Beta InboxSDK on npm with MV3 Support

224 views
Skip to first unread message

Chris Cowan

unread,
Nov 19, 2021, 9:10:37 PMNov 19
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 AMNov 20
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 AMNov 20
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 AMNov 20
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 PMNov 20
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 PMNov 20
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 PMNov 20
to Abby, InboxSDK
I Haven't tried yet. Waiting for types to be fixed.

Abby

unread,
Nov 23, 2021, 3:36:06 AM (11 days ago) Nov 23
to InboxSDK
@Chris Any updates on this?

Abby

unread,
Nov 29, 2021, 3:29:29 AM (5 days ago) Nov 29
to InboxSDK
Hi folks, 

Can you please provide an update on this?

glr...@gmail.com

unread,
Nov 29, 2021, 11:21:01 PM (4 days ago) Nov 29
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 AM (4 days ago) Nov 30
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 PM (2 days ago) Dec 2
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.
Reply all
Reply to author
Forward
0 new messages