Chrome Rejection Received with Violation Code: Blue Argon

[Matheus Cysneiros]

Hi there

We are attempting to publish a new version of our extension after undergoing a major code refactor. Due to this change, the WebAssembly (wasm) we previously used, which was in Go, has now been replaced with Rust. the new version is upload on npm so that may be triggering the violation ?

Item ID:ifclboecfhkjbpmhgehodcjpciihhmif

Violation(s):

Violation reference ID: Blue Argon

Technical Requirements - Additional Requirements for Manifest V3:

• Violation: Including remotely hosted code in a Manifest V3 item.
• How to rectify: Ensure that all logic related to the extensions operation is included in the extension package. For more information please refer to the documentation on removing remotely hosted code & migration checklist on Manifest V3 version.
• Relevant section of the program policy:
  • Extensions using Manifest V3 must meet additional requirements related to the extension's code. Specifically, the full functionality of an extension must be easily discernible from its submitted code. (learn more)

[Patrick Kettner]

HI Matheus

Congratulations on the refactor! That sounds like it was quite the endeavor. Out of curiosity, have you contacted One Stop Support to get information about your rejection? If so, what is the case number?

I looked into the latest review for that extension ID, and it the issue that was flagged is that PDFObject is being included from it's cdnjs.org link. With Manifest v3, you need to embed all code within the extension package itself. You would want to update your extension to include pdfobject.js as one of the files, and load the local file rather than from a CDN link.

patrick

- 

--
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/2c6c0168-60f3-42ac-9fcd-488c37446ef9n%40chromium.org.

[Matheus Cysneiros]

Thanks for the response. I contacted support and created the topic simultaneously. The peculiar aspect of this issue is that we are utilizing the jspdf library (the only one related to a pdfObject), which we accessed via npm.

[Patrick Kettner]

Hi Matheus,

>  I contacted support and created the topic simultaneously

Thats good to hear, thanks for confirming!

> The peculiar aspect of this issue is that we are utilizing the jspdf library (the only one related to a pdfObject), which we accessed via npm

Understood. You will still need to modify the build to not load it that way. There are a number of options on how to do that. I use rollup for my build system, and my course of action is normally to create a new plugin that is a custom loader. It looks like this

import { existsSync } from 'fs';

import fetch from 'node-fetch';

export default {
  plugins: [{
      load: async function transform(id, options, outputOptions) {
        // this code runs over all of our javascript, we check every import
        // to see if it resolves as a local file, if that fails, we grab it from
        // the network via fetch, and return the contents of that file directly inline
        if (!existsSync(id)) {
          const response = await fetch(id);
          const code = await response.text();
          return code
        }
        return null
      }
    }
  ]
}

Other options are using things like patch-package to update the line that loads the dependency to one that loads it from a locally provided version.

If you have any questions, please don't hesitate to reach out

best

patrick