https://developer.chrome.com/extensions/windows
currently says
"The 'panel' and 'detached_panel' types create a popup unless the '--enable-panels' flag is set."
But PanelManager::ShouldUsePanels() [1] will also allow panels to be created in Chromium builds, and for Dev and Canary official channels. This could be confusing for extension developers that use Dev channel thinking that their feature works, when its behaviour will change when run on a stable/beta browser.
I think there are too many bugs for panels to go to stable in their current form, and the documentation should be updated to make that clear.
I suggest:
a) Rename --enable-panels to --enable-panels-deprecated [or just delete it]
b) Remove selection based on Dev/Canary channels. i.e. only support enable-panels-deprecated (and the whitelist)
c) Update documentation. My preference would be to just remove all mentions of 'panel', but clearly marking it deprecated is another option.
[1] https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/panels/panel_manager.cc&q=shouldusepanels&sq=package:chromium&l=105

Besides their floating ability, extensions can use panels to display information on the Chrome OS shelf by setting the favicon. Panels are also aligned to the right, grouping them with the status bar's other displayed info.
Two new things could make panels unnecessary:
-the ability for an app to set its icon, at least on Chrome OS (but with the rollover name)
-the ability for an app to chose whether its icon is aligned to the left or the right of the shelf

There is a plan that we coordinate with whitelisted app on removal of the whole feature. Unfortunately, we can't keep Panels in Chrome since we don't see the way to open it up to all apps (due to UX as well as implementation issues), and this makes it prohibitive to maintain for just a small whitelist. So in a quarter or so, this issue will be resolved for good. I believe before we remove Panels we'll need a proper warning and deprecation period since from some other bugs it looks like a few developers use the panels with a flag, although it's unclear how many users that affects.
For now, I'd support restricting the panels to whitelist in Chromium, dev and canary builds, to avoid confusing developers. It's great to remove them from the docs as well.
We probably still need a flag to avoid upsetting developers who may use it before we can do regular deprecation/warning steps and to run tests on bulidbots, since test extensions are not in whitelist. Also, flag should not confuse anybody since it's very explicit.

+1 to either making panels official or deprecating the API entirely ASAP, and coming up with a permanent replacement. Their functionality is unique and useful so it's tempting to use them, but as they've been in limbo for a few years now, it would be nice to have a final decision be made regarding their support.

Panels are supported on Chrome OS (technically on any Ash platform) through the chrome.app.window API (type == "panel"). That API falls back to a regular app window on non-Ash platforms.
Panel support through chrome.windows is no longer actively supported on any platform and I believe that there is a desire to deprecate it soon.

#16 that is a much-debated question. There hasn't been a compelling reason to do it, the web's windowing model (+ the affordances we give like popups) works fine for most cases. It's not high on the list to think about.

From an extension developer’s point of view chrome.app.window would be a perfect replacement if it was opened up for extensions.
I’m especially interested in better control over behaviour. I’d be disappointed if panels were deprecated without giving developers a suitable replacement; even changing regular popups (chrome.windows) to support a) disabling frames and b) toggling “always on top” could be sufficient.

#14, Panels seem to be supported on all platforms by the Hangouts extension, and has been in use for seven years[1].
I don't consider an API with seven years of whitelisted use in production code "experimental" and deserving of a whitelist, so there should be action to remedy this situation (such as opening up chrome.app.window to extensions).
#19, It isn't standard for a feature to be dev-limited while being used in production for seven straight years.
What seems the most off-putting is that Googlers are actively recommending the use of panels and are treating it as some kind of "official sponsored partner" feature[2] due to it being whitelisted. If Googlers are going to recommend using panels to third party developers, then either the panels or chrome.app.window API should be opened up to all extensions.
[1]: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/j5mIzrVd3GI
[2]: http://cdn1.tnwcdn.com/wp-content/blogs.dir/1/files/2015/07/Screen-Shot-2015-07-20-at-3.51.00-PM.png

Regarding #21 citing Googlers actively recommending the user of panels for "official sponsored partners": this is not something that Chrome supports. I note in your attachment the Googler mentions they would discuss it with the Chromium team. I don't recall seeing anything, and I believe and hope our reaction to any attempt to add something to that whitelist would be refused.

Just echoing that this feature is way too useful to be deprecated and just be made a public API instead of being experimental. I've been wanting to add certain features to an app i'm building that are making the user experience horrible with the workarounds that had to be used.
Please consider this for public use soon.

#21 - Just to clarify a bit more:
* The extension API chrome.windows only exists at this time to support the old Hangouts extension which we expect to deprecate on all platforms.
* The app API chrome.app.window uses an Ash specific implementation and has only ever been supported on Chrome OS. Previously it was kept experimental because it was Chrome OS specific, but after some discussion it has been made generally available on Chrome OS only (as of Chrome 45 I believe). The docs at https://developer.chrome.com/apps/app_window have not been updated; I will fix that today.
There has been a great deal of discussion around these decisions but ultimately we do not have the resources to properly maintain panels on non Chrome OS platforms.

hi. as of today Chrome beta seems to have fully removed the ability to enable panels, not even with chrome flags!!
my chrome extension (free, open source) with 60,000 users use this daily and those on Chrome beta are complaining today. is it really gone and will it propagate to regular Chrome? can my extension be whitelisted? its "Plus for Trello" in the chrome store. https://chrome.google.com/webstore/detail/plus-for-trello-time-trac/gjjpophepkbhejnglcmkdnncmaanojkf?hl=en expect to see a lot of those 60K users coming here to complain :(

Hello,
It seems like enable-panels flag has been removed from 54 beta.
I have an extension with 16000+ users and is completely dependent on panels, and now users cant use this extension.
https://chrome.google.com/webstore/detail/pip-video/anoelogknphkblfagnpdmpfpaddikbae/reviews?hl=en
I just want to reiterate that panels is a pretty popular feature amongst chrome extension users (as mentioned previously in this thread). There are very many extensions that completely depend on this feature and have a very large user base.
In the words of a user not being able to enable panels on my extension after updating to 54 beta -
"I'm so disappointed with this. I loved this feature. I don't know why Chrome would take it away. I hope the developer will find a work around."
The fact that this feature is liked by so many users even when its an experimental feature indicates that it will be even more popular if its enabled by default.
I request that the decision to remove panels be reconsidered.
- Karnesh

in reply to #42: Not at all. In fact that blog post you link says to USE chrome extensions as a short-term way to deal with apps going away. There is nothing that the web offers that can replace the panels functionality, and that blog post specifically mentions chrome Apps, not Chrome extensions which are not going away.
There is nothing that can replace a Panel, web or not, because:
1) Panels have a different way of being always-on-top (auto-positioning, minimize feature etc)
2) Panels are the only way to keep a pending task that requires going back to a page, without actually keeping the entire page open (which I bet is also good performance-wise). A Chrome notification cannot replace a panel because it will automatically go away after a few seconds (and has very limited layout posibilities)

Hello, I'm happy Plus For Trello user.. but, I guess, I will be a sad Plus For Trello user soon when the panels were removed from chrome..
Please keep the panel working.. It is really useful to us.
At least, let us use a flag to enable the panels.
Thanks in advance,
Matheus.

Hi I am a developer and a Plus for Trello user, the Panel autohide feature is really useful in this extension and many other extensions and apps could also benefit from using it if it is fixed and documented. Please keep it alive :)

Panels on non-chromeos were an experimental feature and only supported on Dev channel, or on other channels behind a flag.
They are costly to maintain and we were never happy with their stability and functionality on Windows, Mac and Linux. As a result we've removed them.
We understand this will be annoying for users of extensions that rely on them, but this is part of an alignment of Chrome as being fundamentally a web browser supporting web applications. The link stevenjb@ gave is about another specific topic, but it articulates this shift of attention back to the web.

We will continue to support panels on Chrome OS in apps (chrome.app.window). Since we also maintain the window manager on Chrome OS it is much easier to maintain panel support.
Support for extensions will likely be deprecated at some point.

Can appWindow.setIcon() be shipped if/when CrOS extension support is removed? I currently change the extension panel icon with <link rel=icon>, which doesnt work on app panels.
https://crbug.com/590743

Here is a comparison of using Panels vs. chrome.notifications.
Key point is that the panel UI is much more customizable and provides a minimize feature.
Seems most chrome panel bugs are related to snapping them out of their corner position. We can live without the snapping-out feature.
maybe chrome.notifications could be extended to support these differences, at least for the minimize/width abilities.

Unfortunately, I don't see notifications replace panels at all.
First of all, as stated before, we're talking about extensions, not Chrome apps (which were never really useful to me) for which we need panels. Second, this panel in discussion *is* actually for an extension (Plus) for the web app Trello, so I see it in line with efforts to support the web and get away from OS-based applications.
Notifications indicate a short-term attention keeper that hides itself again, and their design (no minimising, no resizing or repositioning, no custom styles above the standard design) supports that heavily. The beauty of the said panel from Plus for Trello was that I *could* have it sit on my right screen and inform me of where I am, but I also could minimise it for the moments I need that portion of the screen to do $things.
Following that, I would love to have panels coming back!

Hi there,
Really disappointed there'll be no panels soon. I understand some motivation behind the decision (cost of maintanence, etc.) but it's hard to overestimate the significance of the feature. The most important thing IMO is panels are configurable and can be equipped with controls, while a notification is... well, just a notification. Plus for Trello mentioned above many times is a great example of an extension that makes use of panels for the good of its users. Trello is a web app and PfT extends its functionality without forcing users to keep a page with controls open. How can its author implement the same functionality with no panels? Is it really possible? If it is, it'll be great to find a workaround.

key point: panels dont obscure the screen because they are minimizable. Chromium notifications obscure part of the screen, cant be moved or minimized thus to view whats behind one must close the notification. its clear that notifications were not designed arround preventing obscuring a part of the screen because most uses only show them for a few seconds. having them forever on screen is an eye sore. not so with panels.

+1 For keeping panels as a flag.
Reasons:
1) I'll switch to Firefox.
2) Chrome is meant to be the 'platform' for web apps, not just a browser. Word isn't TABBED with my other apps. It has a dedicated window and title bar.
3) URL bars are UGLY.
4) Many extensions use it (e.g Plus for Trello, Open-as-pop, Youtube Magic actions--just to name a few).
You engineers shouldn't be allowed to play with UI decisions.

Joining my voice to the choir of Plus for Trello users who rely on panels as a feature. Please keep them in the product. There is nothing else that lets you display information always on top in a non intrusive fashion.
Regards.

Is the panels support in the open source part of the browser or the proprietary part?
E.g. Could other developers take over the code part?
And also:
Could the functionality be limited instead of fully removed?

As the Plus for Trello maker, im making efforts to replace panels with notifications, so no you the feature is not lost but it wont be as nice as with chrome panels. I have been able to hack-in a minimize option to notifications, but still not as cnice and with a notification window that is twice the size as the one using chrome panels, and the look is not customizable.

The important thing for me was the always on top functionality. Being able to have a video playing in the corner of the screen while I do other stuff was really nice, and there were numerous extensions that offered this in one form or another, but the only way to make it possible was via the panels feature. Now that you've removed this, I can no longer use Chrome to watch videos while I get the boring stuff done. Hangouts is markedly worse too, now that it no longer pops up like it used to. I find it really frustrating getting us all used to having certain functionality available and then just destroying it without any kind of suitable replacement.

I use Plus for Trello and other Chrome apps which make use of the panel functionality. Please do not deprecate this very useful feature.
Why does it seem like Google kills off many of the things I regularly use? If the reason is that (supposedly) few people use it, maybe the real problem is Google's communication with its users.

#75 - actually, you were not supposed to use it. It was a highly experimental feature. The fact is that you needed a flag in order to even activate it. I do not see a need to communicate about experimental features that are not shipped to the entirety of Chrome users (even on a certain platform). It was not like the five-year GMail beta that was open to everyone and one day was made "stable" without any real changes. This was not enabled by default to the public.
You were not supposed to rely on it in the first place.
And not "supposedly". Few users used it, because it was disabled by default and few people change defaults. Even fewer use command line flags. And 50,000 users can be considered "few" in terms of a more-than-a-billion-user user base.

please don't remove it, it helps me during work and gives me opportunity to use the full screen for work, please do keep it and maybe you can advertise about it more.
So I add my voice to "Don't remove the panels" and make us change browser.

hi again from the Plus for Trello maker. Please I ask to only comment with new information and no "me too!". Else just "star" the issue at the top-left of this page. See my previous comment about an alternate implementation Im making to replace panels in my extension, which I expect to be ready within a week.

I am a Plus for Trello user. I need the panel functionality in my workflow which often involves working on more than one task (aka Trello card) at a time. Tasks in this case are directly related and I need the timer reminder to help me stay authentic when reporting the time and description of my workflow. Please do not remove panels!!

Please don't remove panels. I use them every day to have videos online be "always on top" via the pip video chrome plugin. Obviously you guys have the choice to do whatever you choose, however I think it's in your best interest to keep them.

http://www.plusfortrello.com/p/change-log.html
It seems like the Plus for Trello developer has asked their users (via an alert in the extension and in the extension change log) to comment on this bug, which is why we've been getting a steady trickle of comments over the past week or so.
These comments are not helpful and are just wasting the time of Chrome developers.

#76 Indeed, we are 'few' compared to your 'more-than-a-billion-user user base' but these 'few' users may be developers just like you and as we respect your work, please return the same favor to us. Chrome was ( yes , it was ) the browser of choice because of the developer tools and because of the things which we can do with it ( as a browser ) but since then many things happened. We didn't argue when the decision to remove the extension auto-update ( outside the market ) was taken because most of your 'billion user base' installed all kind of shady extensions found all over the internet. We also don't complain about the fact that we have to pay google to use the same auto-update function for our extensions and now you simply throw us this bullshit that we are few ? My friend, this 'few' are the ones who keep that damn market alive and provide your 'billion user base' with extensions. Maybe i missed that part but can you please tell us when you guys got so big that we, from active supporters of the project are now classified as 'few'?

#76 - I think you just nailed it. The option has been hidden behind a flag, so few users would have stumbled across it anyway, and developers possibly did it like Zig and helped their users enabling it through a tutorial in their extension, so it could actually reach a 50.000 user base.
While I understand that there was never a promise to include it (as being behind a flag), how would you think users should actually get to know it, so the user base could grow so you can actually see whether this feature is being used and useful or not?
I think you took an unfavourable example with Gmail Beta. It became a running joke for its constant Beta status, and while it was invitation only for quite a while, invitations were flooding the internet almost right from its start, so there was little to no barrier to get an account. Also, it was stable from the beginning, and with a rapidly growing user base (and extensions and services around it) and so many people relying on it while being in Beta for five years, this is a good example of something that isn't finished, but already something people rely on - as with the panels feature here, only it's harder for people to use it thus far.
I am no developer, still asking myself whether it is not possible to somehow keep panels while making it more secure, hence probably restrict it in order to do so?

#76 - I am a Chrome user, not a Chrome engineer. :)
Chrome (and Google and any other company) favors features that (1) will be used by a large percentage of its user base, (2) meet certain quality levels and (3) are maintainable.
As it was explained here, the feature apparently did not satisfy (2) and (3). It also could not have satisfy (1) because it was off by default.
I understand your needs as a developer, but users are the primary audience here. Some browsers have editions for developers (Firefox Developer Edition, I guess). Engineers are limited and there are much more important features to add or maintain than this.

#91 -
Restricted features are not maintainable at scale. I think Google usually strives to create automatic procedures rather than manual ones, so features restricted to certain (non internal :() extensions are probably out of the question.
The flag was not there to be used by public extensions, a flag shows that it is experimental and meant for testing. The fact - the someone created an extension and made people mess around with command line flags - is not a good thing. Command line flags are unsupported and could break anytime, as well as compromise the security of the browser. The users that use those flags quite frankly put themselves at risk. I hope that was explained to them as part of the instructions.
Note that I do not think Google has ever asked for feedback on the panels feature (it did sometimes ask for feedback on other experimental features), at least not publicly that I can recall.

#95 - thank you for taking time to respond :).
However, what are flagged extensions/options there for actually, if they are not meant to be used? I understand that hiding it behind a flag IS a warning not to use it, so what is actually the use of it? If one is not advised to test and use flags, I wonder what the use of it is in the end.
And since I am no dev, I cannot examine how 2) and 3) are met by the panels feature. Was still hoping there is a way to keep it, but it looks like there is no way of persuasion to actually make it stay.

Flags are meant for experimentation. Sometimes the experimentation is mostly internal and sometimes it is not internal and it is advertised (--enable-web-platform-features).
I know the declarative web request API was (or still is) experimental - and public feedback was requested a few times in the discussion groups.

disclaimer: im the plus for Trello maker.
to clarify again: pft is migrating out of panels and will not lose functionality. however other extensions will suffer like the one that shows videos as the only suitable replacement, web notifications, cannot be used for that case.
I believe the chrome team could improve the situation by adding the missing stuff into the chrome.windows api, for example the always-on-top flag that panels supported.

Those that want always-on-top support in extension APIs should create an issue for it. Whoever creates an issue, please, comment here with the issue numbers so others could star it instead of filing it again and again.

Panels are an awesome feature and removing them would be a bad call. The ability to have a movable, resizable, always-on-top panel is invaluable and extensions that I use on a daily basis would be seriously impacted by the removal.

While closing this issue as "Fixed", I feel I need to offer a couple of words of personal explanation to the users of Trello who were directed here by the developer of the app, as well as others who can be interested.
I'm the original developer of Panels in Chrome, and I'm the engineer who's lead a team to maintain them. I also finally removed them. Panels were a part of my life in form of time, thoughts, inspiration and passion. Our initial plans were to enable panels to all apps which wanted to use them, and we saw how those can be useful of course. It is with sadness but also with appreciation of the experience that I had to remove the feature from Chrome M54.
The time passes and things change, we all learn. In case of Panels, we "proved" by practice that it takes a team of a few engineers full time to be able to catch up with teams of OS developers in Windows, OSX, Linux and even our own ChromeOS. The window management and graphics/input subsystems are constantly evolving and it is more or less prohibitively expensive for a small team to try to build and keep a high quality but non-standard window management mode. OSes have too many mechanisms that are linked to a specific windows behaviors (focus, window switching, active windows treatment, titlebars, where input goes, shortcuts, animations, multiple desktops, other OS gadgets etc), and usually OSes do not provide 'hooks' or APIs to integrate with those, which makes it necessary to 'reverse-engineer' and hack around. While it can be done, it quickly leads to 'card house' design that falls down even easier with the next major OS update... So the costs of development and testing rise.
There was another factor that kept us from enabling panels for all apps. The specific UI Panels provide does not scale well if/when multiple apps are using it. It is very easy to get in trouble with multiple always-on-top windows popping up from multiple apps. Several independent apps using panels at the same time actually makes the interface annoying and hard to control. We had several apps using Panels at the same time and it was hard to manage windows because they were all intermixed. There were several design ideas on how to build some 'panel managers' and corresponding APIs but they increased the complexity significantly, especially considering those would be in addition to APIs OS provides for other windows. So we never were able to enable it for every app.
Now, if the major OSes would adopt the concept and built into their window managers, it'd be much much easier to support it in Chrome. But it's not the case, except for ChromeOS where panels stay.
So at the end, this was a great experiment. We are now way past the point where additional discussion can move the needle much. Google Hangouts app had millions of users and some of them loved Panels. Apparently Plus for Trello has passionate followers. The YouTube viewers is a neat idea. But we all need to move forward, the platforms change much faster and generally to the better :) Hope developers of your favorite apps will figure out even better ways to implement great UI their users demand!