This is related to material design extension page 

Unable to reproduce the issue on Win-10 using chrome reported version #65.0.3325.146, latest stable #65.0.3325.162 and latest canary #67.0.3374.0.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Visited chrome://extensions after enabling #enable-md-extensions from chrome://flags.
2. Observed that all the chrome extensions installed (enabled or disabled) remained visible on chrome without any issues.
3. Also was able to remove a particular extension.

jainabhishek@ - Could you please check the attached screen cast and please let us know if any thing missed from our end.

Thanks...!!

Deleted: 823164.mp4 5.0 MB

	823164.mp4 5.0 MB View Download

Hello Krajshree@

I have reached out to Googler who experienced this issue. 
I will update this bug once I hear back.

I reported this issue.
This happens on linux.
Version 65.0.3325.162 (Official Build) (64-bit)
Developer mode off.
See attached links which I recorded between refreshes: random showing of incomplete list of extensions.
https://screenshot.googleplex.com/KsgArEXKvNf
https://screenshot.googleplex.com/bLKEw4LsSZH
https://screenshot.googleplex.com/hJmUzwVhrZy
https://screenshot.googleplex.com/oSWxBXjLQgU

I think I'm on the public build. So if this is a wide-spread problem, anyone with a linux machine should see it. If not...well, unlucky me...

Are you able to reproduce consistently with the same user-data-dir?

Could it be the case where extensions are still syncing from Chrome sync? Or do you see a case where after a refresh there are fewer extensions sometimes?

Also it might help if you can check the developer tools for any errors.

I am seeing this issue as well on both Win10 and macOS 10.13.3. Chrome stable 65.0.3325.162. 

For me it seems to load a random number of extension cards between 6-10 or so, but never gets further than that. 

I get this error in the dev console when I load chrome://extensions

polymer-mini-extracted.js:2128 Uncaught Error: Assertion failed: Unreachable code hit
    at assert (crisper.js:60)
    at assertNotReached (crisper.js:60)
    at Object.isEnabled (crisper.js:68)
    at HTMLElement.isEnabled_ (crisper.js:124)
    at HTMLElement._annotatedComputationEffect (polymer-extracted.js:1634)
    at HTMLElement._effectEffects (polymer-extracted.js:1443)
    at HTMLElement._propertySetter (polymer-extracted.js:1427)
    at HTMLElement.__setProperty (polymer-extracted.js:1436)
    at HTMLElement._applyConfig (polymer-extracted.js:2049)
    at HTMLElement._afterClientsReady (polymer-extracted.js:2043)

+rdevlin.cronin:
Looking at the code the assertion that is failing is most likely the one at [1], which would indicate that an unexpected ExtensionState is encountered. Looking at [2] the JS code does not seem to handle EXTENSION_STATE_BLACKLISTED case.

Is there an easy way to try that codepath locally?


[1] https://cs.chromium.org/chromium/src/chrome/browser/resources/md_extensions/item_util.js?&l=30
[2] https://cs.chromium.org/chromium/src/out/Debug/gen/chrome/common/extensions/api/developer_private.h?type=cs&l=247-252

Unfortunately, not a really easy way.  In a custom build of chrome you could have extension_info_generator.cc mark a specific extension as blacklisted, or in the dev console you can set the state bit of the info to blacklisted.  Either of those shouldn't be too hard, but are somewhat hacky.

I am able to repro, after modifying the C++ code to fake "blacklisted" extensions, see screenshot, where the error in the console is same as the one at comment #9.

Deleted: repro.png 212 KB

	repro.png 212 KB View Download

FYI, candidate fix is at https://chromium-review.googlesource.com/c/chromium/src/+/981522.

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

commit 17e5f9946495b41018674a2d2410231374c60626
Author: dpapad <dpapad@chromium.org>
Date: Tue Mar 27 19:32:10 2018

MD Extensions: Fix assertion erroneously failing on blacklisted extensions.

This is causing the Extensions page to not display all extensions in such cases.

Bug:  823164 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I39ba59b9e1ccd71cca3b5c68fc9d3715949342ec
Reviewed-on: https://chromium-review.googlesource.com/981522
Commit-Queue: Demetrios Papadopoulos <dpapad@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#546203}
[modify] https://crrev.com/17e5f9946495b41018674a2d2410231374c60626/chrome/browser/resources/md_extensions/item_util.js
[modify] https://crrev.com/17e5f9946495b41018674a2d2410231374c60626/chrome/test/data/webui/extensions/extension_item_test.js

Should we merge this to M66, or is it too late?

Marking as fixed.

@rdevlin.cronin: See question at #15. WDYT? Is it worth a try?

This is a pretty high severity bug.  I think we definitely need to merge to M66, and would think about M65.  Correct me if I'm wrong, but without this fix, any user with a blacklisted extension will be unable to view or modify their installed extensions - is that right?  That seems like it may be important enough for a stable merge (especially given how low-risk it is).

> will be unable to view or modify their installed extensions

Technically I think they'll still be able to modify the extensions that did render before the assertion was hit.

> This is a pretty high severity bug.

The fact that users can still turn off MD Extensions, makes it way less severe though, no? I don't think this bug is severe enough to write a post-mortem (which would be required for an M65 merge).

Also FWIW, https://bugs.chromium.org/p/chromium/issues/detail?id=822939 is a different bug with the exact same user impact (not able to see/modify all extensions), so what we discuss here should apply to that bug too IMO.

@jawag: Please see discussion above about potentially merging this fix to previous releases.

FYI : M65 stable is already out at 100% and we're NOT planning M65 stable respin unless EXTREMELY critical issue arise. M66 wil go to stable on 04/17/18. Thank you.

re: #19, how common is the case that the user's extensions rendered before the assertion was hit, vs. after?

From the original description (1st comment):
"In fact, every time I refresh, the size of the list is different."

So I don't think we can make any assumptions on how many extensions are rendered before the assertion is hit.

Another question that seems also important is how common is the case of having any blacklisted extension installed? FWIW, I tried blacklisting an extension via a policy [1], and it does not exhibit the problem reported here. It seems to me that only extensions that have been blacklisted otherwise (by CWS itself) are hitting the problem.

[1] https://www.chromium.org/administrators/policy-list-3#ExtensionInstallBlacklist

> The fact that users can still turn off MD Extensions, makes it way less severe though, no?

Yes, though this is only achievable by modifying the experiments passed via a commandline flag, right?  That's a pretty steep barrier (especially since the users most likely affected by this might not be power users).

> Another question that seems also important is how common is the case of having any blacklisted extension installed?

I'm out of the office for tonight, but can try to find this number tomorrow.  I know it's non-trivial, but by no means the majority.

That said, I didn't realize we were so close to M66 stable.  If this is only 3 weeks, and we're just discovering this now, maaaybe it's okay?  I'm interested for jawag@'s opinion.

In either case - definitely for M66. :)

(Adding a reminder for me to check blacklisted counts)

+1 we should definitely merge to 66. 

With respect to severity / 65 respin. Looking more closely at the original report, am I reading correctly that it's still possible for impacted users to access missing extensions via the search function? Have we verified this?

Separately, have we verified whether impacted users are still able to reliably view/access their enabled extensions via the "Manage Extensions" link in the context menu (when right clicking on the extension icon in the toolbar)? This link directs the user straight to the extension detail page.

Problem sizing will certainly help (I'm also of the impression that the number of users with a blacklisted extension installed is non-trivial), but if either of these paths are still working I probably lean toward not considering this respin worthy. Especially given that, as rdevlin pointed out, we're half way to 66 and are only just discovering this.

The NextAction date has arrived: 2018-03-28

> this is only achievable by modifying the experiments passed via a commandline flag, right?

Using a command line flag is one of two ways I am aware. The other one is visiting chrome://flags/#enable-md-extensions and disabling from there. A third way would be to tweak our Finch config to turn off MD Extensions for M65 for everyone.

> Separately, have we verified whether impacted users are still able to reliably view/access their enabled extensions via the "Manage Extensions" link in the context menu

Yes. I am able to verify this locally. Even when an extension is not showing in the list, clicking "manage extensions" correctly opens the details page, and user can disable/enable from there.

Just to update.  Re user counts, I investigated the numbers and shared them with jawag@ offline (since this bug is public, and user counts are internal-only).  dpapad@ or govind@, please chat with jawag@ or myself (though I'll be out this afternoon) if you have specific questions about these counts specifically.

This bug requires manual review: M66 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approving merge to M66. Branch:3359

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

commit 78af801b702ce4035c30e89e311a67f05d9a9269
Author: dpapad <dpapad@chromium.org>
Date: Thu Mar 29 21:45:52 2018

[M66 merge] MD Extensions: Fix assertion erroneously failing on blacklisted extensions.

This is causing the Extensions page to not display all extensions in such cases.

TBR=dpapad@chromium.org

(cherry picked from commit 17e5f9946495b41018674a2d2410231374c60626)

Bug:  823164 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I39ba59b9e1ccd71cca3b5c68fc9d3715949342ec
Reviewed-on: https://chromium-review.googlesource.com/981522
Commit-Queue: Demetrios Papadopoulos <dpapad@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#546203}
Reviewed-on: https://chromium-review.googlesource.com/986977
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#507}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/78af801b702ce4035c30e89e311a67f05d9a9269/chrome/browser/resources/md_extensions/item_util.js
[modify] https://crrev.com/78af801b702ce4035c30e89e311a67f05d9a9269/chrome/test/data/webui/extensions/extension_item_test.js