Confirmed. Seems to only happen on macOS.

The issue can be reproduced on Chromebooks running Chrome OS Version 59.0.3071.35 dev (64-bit).  On Windows I've confirmed it also happens on Windows 7 running 59.0.3071.36 and on Window 10 running 59.0.3071.47

Gentle ping!!

@lazyboy: Is there any latest update available for this issue?

Thanks!!

Able to reproduce the issue using latest beta #59.0.3071.71 on Win 10 and Mac 10.12.4.

Note:  Unable to work on the extension as it's not opening on clicking the extension icon in M57, M58, so considering this issue as Non- Regression issue. Hence removing the bisect label.

Thanks!!!

The extension functionality only will show up when in a text field and (like gmail or Docs) it also must be "on" (the icon will be purple not gray).  Here's a little video showing how it works once logged in... https://youtu.be/9J0sCBzAQsQ?t=2m42s

Thanks for the help with this.

I didn't notice this one, will start looking into it.

Just curious if there is any update.  If you need anything please feel free to let me know... If there are changes needed on the App side, we can make those changes too.  

(Still trying to narrow down the issue)

@comment 10,
from the original bug:
[661:1295:0509/184454.839143:VERBOSE1:content_verifier.cc(143)] VerifyFailed ifajfiofeifbbhbionejdliodenmecna reason:3

reason = 3 means extension system thinks that one or more files' contents have changed since installation of the extension. In particular when I looked closely, it seems it was complaining about
NativeClient/CWPredictionResources/Locales/US/Topics/Ancient Assyria.cwz
So likely that all .cwz files would suffer the same problem...

Just wanted to confirm: these .cwz files are part of the extension and are never modified anyhow, right?
If so, then it seems like a bug in content hash / hash verification code.

Thanks for the details - that's really helpful.  These are "Topic Dictionaries" and are not modified so I think it's something to do with the hash verification.  Is "Ancient Assyria.cwz" the only file that is causing an issue?  If so, I can remove it and see if that resolves the issue as they are not critical for the extension to work.  If there are others I can remove those as well.  

Thanks again.

I just removed "Ancient Assyria.cwz" and put a new build up on the Chrome Webstore.  Everything works as expected.  I'll look into what is unique about that particular file that caused the content verification failure. I'll post what I find.   Thanks again.  

 Issue 729978  has been merged into this issue.

Found the root cause for this bug and 729978:

Summary: files that are of size equals multiple of content hash's block_size (4096 bytes) always fail content verification due to bug. The file in question: hide_default.PNG is 8192 (2 * 4096),  bug 720597  is due to a file "Ancient Assyria.cwz" which is of size 16384 bytes (4 * 4096).

(changing the summary line to indicate that this is not NaCl specific)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2557ca6ae520912f73ff133c4371a45a2cb43161

commit 2557ca6ae520912f73ff133c4371a45a2cb43161
Author: lazyboy <lazyboy@chromium.org>
Date: Wed Jun 07 20:29:41 2017

[Content verification] Fix a bug for files that are multiple of 4k bytes.

There was an off-by-one error in ContentVerifyJob::FinishBlock, that
would try to look beyond the last 4k block if the total file size was
multiple of 4k block. The out of bound block would not be returned
by hash_reader_->GetHashForBlock, so content verification would always
fail. e.g.

For an 8k file:
FinishBlock() -> for bytes 0-4095
FinishBlock() -> for bytes 4096-8191
Then an additional FinishBlock() from either ContentVerifyJob::DoneReading or
ContentVerifyJob::OnHashesReady would get called.

Ideally we shouldn't be calling the third FinishBlock() in this case, but
because how the code is laid out currently:
1) hash fetching and reading file content to compute hashes in any order, and
2) handling zero byte and deleted files,
It is less intrusive to add a bail out in FinishBlock to handle this case.

The bug was exposed by https://codereview.chromium.org/2771953003.

This CL also adds regression tests.

BUG= 720597 
Test=See bug description for reproduction.

Review-Url: https://codereview.chromium.org/2928693002
Cr-Commit-Position: refs/heads/master@{#477751}

[modify] https://crrev.com/2557ca6ae520912f73ff133c4371a45a2cb43161/extensions/browser/content_verify_job.cc
[modify] https://crrev.com/2557ca6ae520912f73ff133c4371a45a2cb43161/extensions/browser/content_verify_job_unittest.cc
[add] https://crrev.com/2557ca6ae520912f73ff133c4371a45a2cb43161/extensions/test/data/content_hash_fetcher/different_sized_files/README.txt
[add] https://crrev.com/2557ca6ae520912f73ff133c4371a45a2cb43161/extensions/test/data/content_hash_fetcher/different_sized_files/source.zip

Our extension also experienced the same error on the Chrome stable release (59).
Can someone tell me how to check which files are blocked by the content verification? The extension works fine on Chrome Canary 61.

this is our extension: https://chrome.google.com/webstore/detail/gistnote-highlighter-pdf/cbnaodkpfinfiipjblikofhlhlcickei

#19 - if it is the same issue, just go over all of your file sizes and see if anything is a multiplication of 4096. If you find a file of that matches this condition, either remove it, or change its content (add a byte, remove a byte or whatever).

Thank you, I solved the problem by adding some comments in a CSS file.

In case other Chrome extension developers need an urgent fix about this issue, I wrote a python script that printing out the potentially related file.
https://gist.github.com/kingychiu/8faf23a3e42e864ae9ebd4c1b5939924

 Issue 736699  has been merged into this issue.

 Issue 754282  has been merged into this issue.

 Issue 756034  has been merged into this issue.

When will this fix be merged + released?

We observed this bug impact our extension again today where we used a 4096*n-sized image. 

I had thought that root-cause understanding confidence in the fix and the level of impact (basically killing certain extensions with no user-level workaround) would motivate getting this into C60 or a patch... can you clarify release plans?

It's unlikely that there will be any more M60 releases/patches (only if a high-severity security issue is discovered). M61 (which contains the fix) is scheduled to start shipping next week.

re: https://bugs.chromium.org/p/chromium/issues/detail?id=720597#c26

Thank you for explaining.  A couple of things still puzzle me a bit, perhaps you can help clarify:

- I'm happy it's in C61, but looking back at the history - it looks like this fix was ready ~6 weeks prior to C60's release - wasn't that sufficient time to get it promoted into the release?  

- I cannot tell from label updates in the issue how this fix was marked to be included in M61 (and not M60) - should we be able to view label updates to interpret which release should carry the fix?

Yes, the fix could have been merged in early June to M60 (then in beta). I wasn't involved with the issue at that time so I can't tell you for certain why a merge wan't made. I investigated a merge on August 7th, but at that time we were very close to stable promotion, where the bar for merging changes rises dramatically due to the elevated risk. Given the existence of a workaround, the (relatively) low number of affected extensions, and the high likelihood that developers would detect this issue, I did not push for the merge.

The labels in this tool will only tell you if it was merged to a branch post-fork; in this case, the M61 branch was forked from trunk after this CL, but the M60 branch forked before and no merge was made (hence no labels on this issue). You can use the Find Releases tool on omahaproxy.appspot.com to figure out where the fix landed on trunk.

Hello.

I am also having this issue and everything I have tried have failed.

The extension in question is Chrome Currency Converter (https://chrome.google.com/webstore/detail/chrome-currency-converter/anbfhidldjknonaihbalghlebaijealk).

I was told by the Chrome team this is related to a "browser version" issue, however this takes place in multiple systems and version.

Again, all I have tried have failed and I am afraid I am out of ideas.

Is there a way to pinpoint what's wrong? Perhaps a tool or some sort?

Anything, really, would is appreciated.

Thank you.

Deleted: 2017-10-13 at 21.42.png 27.5 KB

	2017-10-13 at 21.42.png 27.5 KB View Download

Some extra info (related to the previous comment in the thread).

Apparently the issue is that verification fails because of this reason "MISSING_ALL_HASHES".

Proof: https://d.pr/i/oXrXLx (breaks here: https://d.pr/i/T5QxW)

I tried to figure what that really means by I have never been any good at C so I failed.

Any ideas? please?

Thank you

Re: #30, I believe this is an unrelated server-side bug. I'm investigating now.

Thank you. 

Please let me know if there’s anything I need to do in my end. 

Looking forward to hearing from you. 

Re #30, it turns out this is a problem with the extension's commands declared in the manifest.json of the app. Specifically: 

      "suggested_key": {
        "default": "MacCtrl+Shift+C"
      },

MacCtrl cannot be used in "default", only in "mac". IIUC one way to rewrite this would be:

      "suggested_key": {
        "default": "Ctrl+Shift+C",
        "mac": "MacCtrl+Shift+C"
      },

I've opened crbug.com/775555 to correct the deficiency in the documentation. Sorry about the confusion.

Thank you so much.

I would have never figured this out, not in a trillion years.

Again, thank you.

Hello again.

Just published a new version with the suggested change.

Unfortunately, it seems the issue persists.

In fact, this time, the moment I try to repair it gets totally vanished :(

Ideas?

This time I get "Package is invalid. Details: 'Could not load extension icon 'assets/icon/16.png'.'."

I think the problem is that your manifest.json uses "assets/icon" but the ZIP file contains "assets/Icon" (the path is case-sensitive).

Thank you - again.

This time all feel normal.

I wish there was an easier way to be informed on those issues - and not having to bother you all - but in any case those are lessons learned :)

One last q, please: I was advised to include (all) the source code in the zip sent a while ago. Is that still the case? 

Yes, the MacCtrl issue was quite hard to find! Most other issues you can find if you try to do a fresh install of the extension - an error message will appear in most cases.

If you're getting in touch with us, it is often helpful for us to have all the source code when we are trying to debug, but in the normal case you need only include what your extension needs to run.

Hello,
I have run into same issue as well.
This is the extension: https://chrome.google.com/webstore/detail/ecomreveal/icgjijfoeedoeloffeeopbancoohjgnd
What happens is that extension gets installed and its icon disappears and in extension page I see this message "This extension may have been corrupted." When I reload the chrome store link of this extension it says that extension is disabled Click to Enable it, i Enables it and extension works fine, untill chrome is relaunched.

When its installed from the "Load unpacked extension" it works fine even when I package it into crx myself it works fine as well. But when Uploaded to chrome store the crx which chrome store creates causes issue because I tried to get the code of this extension from chrome webstore page of this extension, packed it locally and then it caused the same issue.
Can anyone help on this issue?

Its a bit urgent.

Best 
Bilal

Looks like your manifest.json references the directory "images", but your actual extension package has the directory "Images". On Windows file paths are case-insensitive, but not on other platforms - and as you see you still have problems on Windows because the file verification system that Webstore adds to the extension is case-sensitive.

I recommend you lowercase the "Images" directory and try again.

#41 - can you make sure a proper error message is emitted in this situation?

@42 We're discussing now what the best method and place to surface that error is (in chrome, during validation from upload to the webstore, etc).  I'll circle back here when we have an answer.

#41 I Updated the manifest.json file,I used "Images" instead of "images" then created a crx locally and dragged and dropped it on extensions page still the same issue. 

Please note: I am creating this crx file locally because I downloaded the entire code of this extension from the url of this extension using "Chrome Extension Source Viewer" extension, it would not be necessary for me to publish the extension again and check it because this downloaded version of the code causes the same issue. I removed "_metadata" folder. Attached zipped file contains the entire code + 2 Packaged versions

1-Packeged version working
2-Packaged version not working

1-"Packaged version working" contains the crx that does not cause the issue, in order to create this crx I removed the "update_url" property of the manifest.json file. If I remove this line from manifest.json and then package it, it does not cause the problem.

2-"Packaged version not working" contains the crx that causes the same issue, In this version I did not remove the update_url property from manifest.json.

This property "update_url" is not added by me it gets added when extension directory zip file is uploaded as part of publishing process.

Let me know if I can tell you guys any thing else

Deleted: Chrome store version.zip 242 KB

Chrome store version.zip 242 KB Download

#44:
In your manifest.json I still see:
  "browser_action": {
    "default_icon": {
      "19": "images/icon_19.png",
      "38": "images/icon_38.png"
    },
    "default_title": "EcomReveal"
  },
Which is using a lowercase path for the icons.

#41 - definitely agree we need a better UX for these errors. In this particular case the error is pretty clear on Linux/Mac ("Package is invalid. Details: 'Could not load icon 'images/icon_19.png' for browser action.'.")) because it fails at an earlier step (installation of the extension). It's tricky to make the corruption checker output better messages, but I think we could catch this class of error at upload time if we put some simple checkers into the webstore.

#45: 
You must be talking about the version of extension that is available on chrome store I mentioned in the comment that I did not have to publish the updated extension as I downloaded the source code of that extension from chrome webstore link using "Chrome Source Viewer" extension. I am able to recreate the same problem using the code which I downloaded.
In #44 I have attached the code in which I updated "images" with "Images" in manifest.json file. Did you get a chance to check this one out? or you want me to publish the latest version (with "Images") on chrome webstore?

#45 I have had to launch this extension, This extension link was supposed to be provided to selected customers, I would request you to kindly let me know what can be done from my end in order to get smooth installation of this extension from the link. its a bit urgent, any help would be appreciated

#48: Now that you've launched the updated manifest.json, I can install the extension, and I believe you will no longer encounter that error. For security purposes, it is usually not possible to install an unpublished draft of the extension using the link from the developer dashboard.

yes it works fine now I dont know why the local version was still causing issue.
Thanks for your help guys, just in case for future Logs assocaited to these kind of bugs are not available to us, is there a way to get logs for these kind of bugs?

In the future, we want to better expose more actionable errors in the UI so that this isn't as confusing. The logs really aren't much better. (To debug the MacCtrl issue above, I had to step through the install execution in a debugger.)

In the short-term, since this issue is most commonly caused by case-sensitivity in manifest.json, your best bet is to try installing the extension on Linux or Mac, which will give you a better error code due to the case-sensitivity of those platforms' file systems.