I agree but I don't think they'll do it. Maybe they could expose the path of locally loaded extensions in chrome.management API (e.g. as 'updateUrl') so we could write a simple toggler extension. Currently one would have to write a nativeMessaging utility that analyzes the Preferences file directly.

Thanks for filing the issue!

As per comment# 0 from the reporter issue seems to be a Feature request, hence marking it as Untriaged.

Thanks!

I can take a look at this, shouldn't break the UI flow in chrome://extensions

I don't think this is something we'll add to the card view on the top-level chrome://extensions page.  Unfortunately, we have to be pretty judicious about what goes there, and we also prioritize information that can be shown for each extension (i.e., not just unpacked) so that the card heights are uniform.

As a (somewhat suboptimal) workaround, could you use different versions to indicate the difference in extensions?  Those are displayed on the top-level page.

Marking as won't fix for now.

What about exposing the path of locally loaded extensions in chrome.management API (e.g. as 'updateUrl') so we could write a simple toggler extension? 

@8 Exposing it on the management API is an interesting thought.  There's two catches, though:
1) An unpacked extension could actually have a separate updateUrl in the manifest; I'm not sure we would want to implicitly override that for unpacked extensions.
2) The path for the extension would expose (a part of) the user's file system structure, which may or may not be sensitive.  I don't know if we'd want to include that by default, since it's a bit different scope than the rest of the management API.

As for 1), I'm actually not opposed to introducing an optional "path" or "loadedFrom" property for these extensions, though I'd be curious if there's use cases beyond this.  2) is a bit trickier, but we could potentially gate it on whether the extension has file access granted by the user - if it does, it shouldn't be any kind of risk to expose the path.

Thoughts?

Actually, I think "wontfix" is the wrong resolution here since the request only pertains to the non-default developer mode, which is used only by [supposedly] 0.1% of users. So there's no need for the judiciousness to kick in. Moreover, there's nothing particularly terrific about the current UI design of chrome://extensions page that's worth protecting. Visually it's just a bland primitive grid of cards - not even particularly readable or structured in any way - regardless of the under-the-hood work you devs put into it. As a developer of extensions I think it's just barely useful when the developer mode is enabled, and every time I have to go back from details to the top level just to reload an extension I get annoyed by the poor UX and I curse modern UI designers who are too detached from reality so they just draw their neat mocks.

@10 Please remember to keep discussions respectful and constructive.  UI is always incredibly controversial, and there's never going to be a UI that works for everyone and that everyone likes.  We can certainly endeavor to make improvements in usability and functionality, but just saying something is bad doesn't help move us in the right direction.

Please remember I'm not working for Google so I don't think I'm disrespectful being an outsider. I think my language had just the right amount of colorful epithets to relay the amount of accumulated frustration your designer's attitude of ignoring obvious issues is causing me. Admitting something is wrong or plain bad is the first step in fixing it. Dodging the issue certainly won't be helpful.

Actually, one could argue it's this dodging and continuous ignoring the obvious problems is disrespectful towards the users, but that's not in the Code of conduct, right?

Let's not get distracted here. The UI of the developer mode extensions page should solve the real problems of the extension developers who use it a lot, like dozens of times per day or even more. In this situation the correct approach is to listen to the developers instead of dodging the problem by citing the controversial nature of UI. It only becomes controversial when the UI designer stops solving the real problems and instead focuses on solving imaginary problems with the aesthetics. The developers need more info on the cards, the developers need to be able to perform the basic routine actions such as reloading as easily as they were able to do for roughly ten years prior to the redesign. You've been ignoring that for about a year, but maybe it's time you admit it was wrong?