I've uploaded new browser extension to Opera addons and I've sibmitted the version from 1 week, but till now there is no response, is it ok?
Extensions submitted to Opera Add-Ons are manually reviewed, and this takes time.
If the extension is minified or obfuscated, the moderators will ask you to provide source code and the way to reproduce submitted files. Such extensions have lower priority in the review queue.
Adhering strictly to the acceptance criteria and some patience will make the trick.
Related
Before deciding to write this issue on Stackoverflow, we tried everything that we could through the normal/official (and slow) contact process (contact form and developers emails).
So this is actually our last try to solve it and also expose some of the Google's review mistakes and inconsistency when reviewing new items (extensions).
We currently have an extension (item hjdkfeeffbfcoanbnkeedjccphcmpehm) that was approved and published few months ago and that is now used by more than 70,000 people, with excellent rating on Chrome Web Store.
https://chrome.google.com/webstore/detail/ad-block-chega-de-publici/hjdkfeeffbfcoanbnkeedjccphcmpehm?hl=pt-BR
This extension is an Ad Blocker and was primarily focused in the Brazilian market, for Portuguese-speaking people.
Due the success of this extension, last week we decided to add two new extensions (Ids: mmcgdfakfmbepgnoogipkccigohjjcim and hgekbffcnpflnhfjkdfdlhffigdfbnae) that would focus on English-speaking and Spanish-speaking countries and, when we tried to add these extensions with the exact same source code that we used for the item that is approved and published, the Chrome review team is always rejecting with these arguments below:
To have your item reinstated, please make any necessary changes to ensure:
All of the files and code are included in the item’s package.
All code inside the package is human readable (no obfuscated or minified code).
Avoid requesting or executing remotely hosted code (including by referencing remote javascript files or executing code obtained by XHR requests).
So, just to make it clear:
1) The extension that is currently approved and published (item hjdkfeeffbfcoanbnkeedjccphcmpehm) does have minified code and even so was approved.
Even so, we did what Chrome's team was requesting and uploaded new packages with human-readable code (not minified) and even so, again, our extensions were rejected;
2) The extension that is currently approved and published (item hjdkfeeffbfcoanbnkeedjccphcmpehm) does load dynamic content from our server, as we need to daily and automatically update our URL list for blocking ads, its impossible to simply build and publish a new extension version every time we need to block a new URL or type of Ad.
Ad Block Plus, uBlock and other Ad Blockers do the same and they are approved and published on the Chrome Web Store.
3) The extension source code of the new items, except by the text that needed to be changed, as the new extensions are in different languages (English and Spanish), is exact the same of the extension that is approved and published, line by line;
In order to prove that from them, we even created a diff file comparing line by line the source of the approved extension with the new extensions, even so this was not enough to prove them we were right and also to simply get some answer on our emails.
We have already argued all of that through email with Chrome's team, but never received any answer or reply, except by the standard "rejection and removal" emails. They simply don't care.
That being said, it's clear to me that:
Google Chrome team is deliberately trying to prevent us for publishing two new Ad Blocker extensions, because they saw the growth that we had with our first extension (that is approved and published);
or
Someone at Chrome's team is simply making repeated mistakes and no one cares nor read our emails;
I hope this message can help us get some human attention within Google's team and also alert you guys about the "really strange" problems that we are facing.
Although this issue was more related to Google's policies than programming in the first place, the solution is still relevant to share for other Chrome extension developers, as it was somehow related about how to load remote resources for your extensions.
After posting this issue Google's team contact us and their question for keeping rejecting our extensions was related to the way we were loading remote resources for our extension.
Google's reply by email
Your new extensions are fetching resource(s) from AAA.com.br. However, the official website(s) registered for your new items is BBB.com. This means that the resource(s) being fetched are coming from remote/third-party source(s) and as per our program policies, we had requested you to check the following:
If all of the files and code are included in the item’s package,
All code inside the package is human readable (no obfuscated or minified code), and
If the items are requesting or executing any remotely hosted code (including by referencing remote javascript files or executing code obtained by XHR requests)
The specific issue here is with #3.
It'll be great if you can give us some context on the resource that you're fetching and how the two websites in question are related. Once we have that information, we'll be happy to help you guys with the publishing process.
As we have two different URLs related to the same extensions (we have three extensions), for the new extensions the URL BBB.com was configured on Chrome Web Store Developers Console, but we were actually loading the resources from the URL AAA.com, that have being in use since we published our first extension.
Although both URLs were added and owner-validated to our Chrome Web Store Developers Console and both URLs were related to the same extensions, we now understood that is a good practice to load the resources from the URL that is actually configured on the extension details, even if you have more than one URL for the same extensions.
So, if you have URL AAA.com and BBB.com, and both are used for the extensions A and B, try to load the resources of the extension A from the URL AAA.com and the resources of the extension B from the URL BBB.com, even with both share the same backend.
This will avoid Google's team to think that you might be loading resources for your extension from unknown 3rd parties, that is forbidden according to the program policies.
Why is Opera SRI support unknown? On a Mozilla Developer Network page, it shows various browsers and if they support SRI. Opera is unknown, why is Opera unknown? Is there not a way of testing Opera, for SRI support?
Of course there is a way to test Subresource Integrity support in opera. You just need two things for that, first you need to have opera installed, and second you need some time to start opera, trying to visit a page which should fail the integrity check (possibly setting it up first) to document the result.
It just seems the author of the Wiki entry decided to not spend time on downloading, installing or testing Opera hisself. As it's a Wiki, anyone willing to spend the time on testing opera is likely welcome to add the result.
Our Chrome Extension was removed from the Google Chrome store (and Google Marketplace) and we didn't get any notification before hand that it was going to be removed, and didn't get notified that it was removed (or for what reason).
Our extension is FollowUp.cc (a growing company that depends on the extension)
One of our engineers started reverting changes and republished an older version of the extension in hopes that that may help. We're out of ideas.
Any help would be appreciated!
I need to edit and then publish my Chrome extension. I know that it sometimes takes over an hour to publish an extension, but once it has been published, can I assume that all users are using this new extension version? Or might they still be using the old one for a while? And, if so, for how long?
I publish via the Chrome dashboard. Sorry if this is the wrong place to ask. I have tried searching through Chrome's documentation.
Issue: I need to update my server side code, but if a user is still using the old extension version, then it will fail very badly.
You should not make any assumptions about the extension update frequency. The update frequency is 5 hours by default. This value can be changed by the user through the --extensions-update-frequency flag. In practice, most users will stick to the defaults though. And do not forget that it is unreasonable to expect that all of your users have their computer online all the time.
You should keep the code for the old and new version at the server's side. If you haven't done before, include a version identifier in your request. This version identifier does not need to map 1:1 to your Chrome extension version; just use a value and keep incrementing it for every significant API update.
If you did not include a version identifier in your previous version, just assume that the user is using the old version if the version identifier is missing from the request, and consistently include the version identifier in requests from your new Chrome extension.
If you have set a minimum_chrome_version in your manifest file, then the user will also be stuck at an old version of your extension if they use an older Chrome version.
Though not relevant for your specific situation, extension authors can choose to distribute their extension to a specific percentage of users via the dashboard at the Chrome Web store. When this feature is used, you obviously have users who are still using the old version.
You have to handle in your code the possibility of users having the old version. Its not published how long that might be but from experience it can be a full day at least.
According to the docs and other sources the update happens within a few hours from publishing.
Every few hours, the browser checks whether any installed extensions or apps...
The default update check frequency is several hours,
I suggest you implement a mechanism to check the version of the extension making the request and if it is not current, either fallback to differently handling the request (based on the old server-side code), or inform the user they have to update (although I would not advice that, as it might scare and annoy users).
In order to force an update of one's extension:
but you can force an update using the Extensions page's Update extensions now button.
Basically, you have to go to the Extensions page, check "Developer mode" and press the "Update extensions" button that appears.
Bottom line
I would:
Implement a mechanism to include the version in a request
Maintain two code based on the server (for a few days only)
serve each request based on the version
I built a quick one-off chrome extension about a month ago during the SOPA craziness. Long story short, it unblacked Wikipedia, so that people who needed it could get some work done.
Once the blackout was over, I updated the app to no longer have any effects on any websites. I also modified it so it would put a console.log() saying essentially "The blackout is over. SOPA is still important, but you should uninstall this extension".
Unfortunately, a month later, I'm still showing that 90% of the original users have the extension installed. Certainly it doesn't have that large of a footprint, but as a developer I feel it's my duty to not let my extension become crapware on my user's computers.
Is there a way to forcefully uninstall a chrome extension? Is there some way that would be unintrusive to the user that I could inform them that they should uninstall the extension?
You can update the extension so that it requires the 'management' permission, and then use chrome.management.uninstall to make the extension uninstall itself.
In my opinion, there is no way in this situation. Unless
If your extension makes a request to a server that you can access, such as a web service from you, maybe you can send an alert to your users.
If auto update is enabled in your extension, you can update your extension. In your updated version, you can show users an alert (shouldn't be a real javascript alert. Some kind of alert) to uninstall your extension.
If auto update is enabled, you may update your extension to do nothing. Just a console.log message.