Unexpected delays in CWS approvals

[Péter Szász]

Hi all,

I'm working at dashlane.com, and since our main product is a browser extension, having a quick and reliable release process there is crucial for us to serve our customers. 

Up until recently the Crome Web Store was quick and reliable most of the time, but since a few weeks, we had multiple releases held up for longer reviews, not just for the production extension, but our unlisted MV3 version too. This is affecting our customers  because it takes more time to deliver fixes and new features for them - and also our work towards MV3 compliance.

It's especially frustrating that there's no way to understand the reason for these delays, and more importantly, no way to escalate for a faster resolution or asking for more information. I know that escalations are not possible for "security reasons", but would still love to have some kind of flexibility for a featured extension with 2M+ users. It's incredibly frustrating to have this step in our otherwise very agile release process that we have zero control or information on. 

Could Google provide some improvements in this area? Are there extension developers in a similar situation with some guidances or best practices to share?

Any help would be appreciated. 

Thanks,

[hrg...@gmail.com]

When you say "the Crome Web Store was quick and reliable most of the time "

How long is "quick"?

In my experience, "quick" would be a review time of about 24 hours for an extension with tens of thousand of lines of code and <all_urls> permission.

Between 2 to 3 days I would say it's normal.

More than 3 days I'd say it's slower than usual.

More than a week is definitely slow.

[Péter Szász]

I agree with your assessment of expectations.

However, our previous production version took 14 days to approve, and the update sent immediately after is still pending review since the 10th November. 

Similarly, our unlisted MV3 version's previous approval took 8 days, the update sent on the 10th November is still pending. 

I don't think these are acceptable delays, especially without zero communication or an option to escalate.

[Raul Ramos]

Hi all,

We are in exactly the same situation as Peter. Our main product is as well a Chrome extension mailtrack.io that got recently migrated to manifest v3.

Mailtrack is a Chrome Extension created in 2013 that now has over 2M users according to public data published in the Chrome Store and one sustainable company that makes a living producing a chrome extension (we employ over 30 people).

Our release cadence was twice a week when we were still in Manifest v2, and review times could be to up to 24h.  Now, with manifest v3 our review times are getting insane. Our release from 17 October got published on 2 november. Our release of 10 of november is still pending.

This release included important bug fixes regarding mandatory changes due to Manifest v3 compliance. We need more flexibility from the Google web Extension team these days, not the other way round, especially taking into consideration the immaturity of the Manifest v3 ecosystem. The developer experience is being very harsh: bugs, incomplete documentation during this process and now this insane review times.

Can anyone in the Chrome Extension Team please explain what is going on?

Regards

[Artem Harutyunyan]

Hi,

Our experience is consistent with this too. Manifest V2 review times during the past two months were very reasonable. The MV3 version of the same extension always took longer to review. I'd submit MV2 and MV3 at the same time, and MV2 version would take hours, whereas we had to wait for days for the MV3 version to get published. I thought that it is due to the MV2 version having 10,000s users vs. just 100s in the case of MV3. However, since we switched the main extension from MV2 to MV3, we started seeing very big delays in reviews, very similar to what I experienced all along with MV3 extensions.

Any guidance on returning to normal review times would be appreciated!

Artem.

--
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/5dfb1e84-dc3e-4aac-ae85-61bc949addbbn%40chromium.org.

--

Co-Founder and CTO bardeen.ai

Explore | @bardeenai | Slack 

[Simeon Velichkov]

Anything that can help the reviewer may speed up the review process. Unfortunately there is no official way to do that. For example, when you submit an extension in the Firefox Addons marketplace there is a textbox labeled 'Notes to the reviewer' where you can specify anything useful for whoever reviews this. They even asked me for a bash script to build the extension package.

And now that the official review process https://developer.chrome.com/docs/webstore/review-process/ (thanks for that document btw) is supposed to involve manual steps, and it also mentions things that may increase the review time such as: 'having a lot of code', 'hard-to-review code' and 'You may also want to consider structuring your code in a way that is easy for others to understand', makes the build script option even more viable. Personally, I find some of these statements a bit funny or borderline disturbing, such as the code style hint for example, but I know that they were put there with a good intent, and also that this is one way to improve the review time.

But back to my point with the build script, if I am able to provide a build script, that you can use to build the package, then hash it and compare to the one I have uploaded to the Chrome Store, and then you can also read all of the sources from which that build script is pulling those dependencies from, then that should cover at least all of my dependencies. And if those are some well established open source project pulled from cdnjs or npm then than should cover some of the 'having a lot of code' point I guess.

The rest will be my beautiful code, which no matter how hacky it looks, it will still have to conform to the requested permissions and their outlined usage.