Which OS are you using? 

Can you go to chrome://flags and check what value is set for #top-chrome-md?

I'd be surprised if this were an MD-specific bug, but I'll double check once I get the answers to the above.

+Devlin as FYI

Chrome OS beta channel. 

The flag is set to Default however it looks material now with the hotdog menu becoming the more common three dot context icon etc. 

As far as I can tell the "Hide in Chrome menu" wasn't even there before it updated to material design (a bunch of extensions also appeared up there which weren't there before such as password manager which is when I noticed).

I'm attaching three screenshots to show the process. 

1. I click to hide extension 1 (password manager)
2. I remove extension 2 (cert installer beta)
3. password manager is magically back

Thanks for confirming. Material design and the new extensions UI are actually unrelated features. I just tried this out myself on Chrome OS beta channel and it reproduces with MD turned on (which is the Default) as well as with MD disabled, so it looks like it's a bug with the new extensions UI.

 Issue 599886  has been merged into this issue.

The reason for this is because right now, we store the order and the length of the toolbar, and we wanted to address the case of unloading and reloading an extension putting it back in the same spot, which, if we changed the number of visible extensions on extension unload, wouldn't work (we get unload signals for extensions being disabled, removed, or reloaded - the latter of which often happens without user interaction).  In theory, we could address removal and reload specially, with removal adjusting the visible count and reload not adjusting the count, but then disable/re-enable becomes kind of funny.

The more involved fix would be to have a per-extension visible/hidden preference, so that the extension would be shown/hidden properly on reload, but this also causes some confusion with conflict resolution with the stored toolbar order.

I think the best fix here might be to default to saying unloading a visible extension reduces the visible width by 1 unless the extension is just being reloaded, and saying that re-enabling any extension causes the extension to be visible.  This addresses the most common cases of removing extensions causing others to pop in, and the number of times users disable/re-enable an extension in quick succession is pretty low.

Alex, Finnur, WDYT?

Also, tomhanson@, do you mind if I delete the screenshots in #2 so that I can unrestrict this bug?

Sure.

The design decision we took early on was to go to some lengths to respect the wishes of the user when it came to the toolbar width. This is why a new icon pops into view when you remove an extension icon. 

I'm not super excited about an approach that causes extensions that were previously hidden in the menu becoming visible in the toolbar on disable/enable. I think that's worse than a hidden icon becoming visible just because another one was removed (which is how things have always worked). 

It would be nice to have hide and remove work the same in terms of toolbar width, if we can fix it in such a way that there's no unintended side-effects. But I'm not sure that solution exists, so I'm inclined to say this is working as intended, especially given that the bug steps is a bit contrived (first hide an extension, then remove one).

> It would be nice to have hide and remove work the same in terms of toolbar width, if we can fix it in such a way that there's no unintended side-effects.

I think we could at least say if an extension is unloaded for uninstallation (and was visible), we shrink the visible size by one.  That way, disable/enable still work as they always have, and we address the most visible instance.  WDYT?

> especially given that the bug steps is a bit contrived (first hide an extension, then remove one)

To be fair, I don't think this is really contrived.  Step 1 could have been "have an extension overflowed" - a state which many power users live in (and we expect them to).  The length of time between steps 1 and 2 can be arbitrarily long.

> To be fair, I don't think this is really contrived.  
> Step 1 could have been "have an extension overflowed" 

That's a different bug, though. The sentiment in this bug (as seen in the expected outcome) is: "I hid my extension and it re-appeared because I removed an extension".

> That way, disable/enable still work as they always have, and we address the 
> most visible instance.  WDYT?

I'm fine with that, with the caveat already mentioned (that it doesn't cause weirdness in other scenarios).

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

commit 12671aca120fb0ffe0b61644b59035da504de9a5
Author: rdevlin.cronin <rdevlin.cronin@chromium.org>
Date: Thu Apr 07 18:18:44 2016

[Extensions UI] Don't pop out an overflowed action on item uninstall

If an extension is uninstalled, we shouldn't pop out a previously-
overflowed extension. We still do this for an extension being
disabled because we want a disable->enable cycle to maintain toolbar
width and position.

Change behavior for uninstall and add a test.

BUG= 599362 

Review URL: https://codereview.chromium.org/1861943002

Cr-Commit-Position: refs/heads/master@{#385811}

[modify] https://crrev.com/12671aca120fb0ffe0b61644b59035da504de9a5/chrome/browser/ui/toolbar/toolbar_actions_model.cc
[modify] https://crrev.com/12671aca120fb0ffe0b61644b59035da504de9a5/chrome/browser/ui/toolbar/toolbar_actions_model_unittest.cc

 Issue 561623  has been merged into this issue.

 Issue 647263  has been merged into this issue.

 Issue 692516  has been merged into this issue.

This was partially helped by revision 12671aca120fb0ffe0b61644b59035da504de9a5 (for uninstalling/removing extensions), but is still an issue for disablement.   That, and others, are being tracked in issue 839241.  Given this was originally about uninstallation (right click, Remove from Chrome), marking as fixed.  Follow along issue 839241 for the rest.