Beta InboxSDK on npm with MV3 Support

[Chris Cowan]

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]

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]

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]

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]

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]

@Amiram

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

[Amiram Korach]

I Haven't tried yet. Waiting for types to be fixed.

To view this discussion on the web visit https://groups.google.com/d/msgid/inboxsdk/d7f1eb75-46d3-4975-bce0-fbe6f7fb543fn%40googlegroups.com.

[Abby]

@Chris Any updates on this?

[Abby]

Hi folks, 

Can you please provide an update on this?

[glr...@gmail.com]

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]

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]

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]

Any updates on this? It's been a while since the announcement was made.

[Abby]

Hi Chris,

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

Thanks

[Chris Cowan]

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]

Thanks Cris, 

Eagerly waiting for the new release!

Cheers

[Abby]

Hi Cris,

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

Cheers

[Aleem Mawani]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/inboxsdk/b5573c1d-4ae0-46b7-b316-96045633730fn%40googlegroups.com.

[Abby]

Thanks for the updates Aleem, looking forward to it!

[Chris Cowan]

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]

Hi Cris

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

Cheers

Abby

[Abby]

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]

Is InboxSDK compatible with Microsoft Edge and/or Firefox?

Regards,

[Guzman Rejon]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Hi Cris,

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

Cheers

Abby

[Laura Gutierrez]

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]

I would like to add more info to my previous message.

1. I am not directly loading the background.js file included in the npm package in manifest's service worker. Instead of this, I have added its code to my background file. I have checked that this is properly managed, because as a consequence, after calling InboxSDK.load() the message is intercepted in the background, trying to load the pageWorld.js file.

2. The pageWorld.js file is available at the root of my package. I am just using webpack ( entry: { 'pageWorld': '@inboxsdk/core/pageWorld.js'}) to output the file there.

3. The result is that when the browser tries to load the file, this error is thrown: ReferenceError: Invalid left-hand side in assignment (at pageWorld.ljs:114).

[Osama Inayat]

So I tested the beta version. My Functionality for extension is working as expected. But some console errors are thrown which are totally unrelated to the work I hope the SDK team works on these as given below.

. I am not using the background.js provided by the inboxSDK I just listened the message and responded as done in the background.js generated by inboxSDKs. And Everything seems smooth.

[Laura Gutierrez]

Hello Osama,

Thanks for your reply.

Yes, it seems that I had a problem with webpack. Adding directly the pageWorld.js file inside the npm package to the assets of my project did the trick. So now at least the load function is working.

Anyway, this way of working is a bit challenging from a project maintenance point of view. But still, thanks to the inboxsdk team for the effort.

[Osama Inayat]

Laura and InboxSDK team

I don't need scripting permission in rest of my extension. Is there any plan to remove this dependency or we are going with this.

--
You received this message because you are subscribed to a topic in the Google Groups "InboxSDK" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/inboxsdk/MAT_zImFu5I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to inboxsdk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/inboxsdk/dad241e4-4b5e-4f01-90b3-3602e03dfa2cn%40googlegroups.com.