When a CRX is added to the Chrome web store, Google adds a directory _metadata
to the crx. Older versions of Chrome do not know about this directory (tested on Chro
You -as an extension developer- cannot work-around this bug, because the directory is added by the Chrome Web Store (CWS). You could work-around the bug by not using the CWS to distribute the extension, but then the extension cannot be used by the majority of Chrome users, because Google has actively tried to stop users from getting extensions from outside the CWS.
The CWS team are the only ones who can fix the bug. They should serve crx files without a _metadata
directory if the user agent does not support the directory (Chrome 30-). This bug is being tracked on https://code.google.com/p/chromium/issues/detail?id=377278. So far, the response is:
We can't fix old versions of Chrome. Webstore side tracked at b/15176392, but extending support back to Chrome 30 is unlikely.
Star the issue to get notified of updates and to signal that you really want the bug to be fixed. If enough users/developers complain, then Google might fix the bug.
You can try to unzip the CRX (change the suffix name to ".zip" if needed) and then in chrome: Settings -> Extensions check "Developer mode", choose "load unpacked extension.." and select the extracted folder.
P.S.
I had to rename the folders starting with "_" (underscore) and remove the line
"default_locale":"en",
from the manifest JSON in order for that to work
Some people found resetting works. Some found emptying the recycle bin works. None worked for me. I re-installed chrome also didn't work.
Instead this worked for me (same as what Xan said): I download the .crx file, unzip it, erase the folder
_metadata
Then install it manually. This worked for me.
DELETE THE _METADATA FOLDER AND I ASSURE YOU INTERNET DOWNLOAD MANAGER WILL BE ADDED AS ONE OF YOUR EXTENSIONS.
This answer applies to CRX files that you:
_locales
folder should not pose problems. As long as the manifest contains default_locale
key, Chrome will load the unpacked extension as expected.
_metadata
is the problematic folder. It contains cryptographic hashes of all extension files to protect against tampering with those files, and is automatically added by CWS. This does not make sense in the context of an unpacked extension, and has no other use, so this folder simply needs to be deleted.