New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 477424 link

Starred by 548 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: ----
Type: Feature

Blocked on:
issue 507400
issue 508565

  • Only users with EditIssue permission may comment.

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Implement chrome.sidebar API

Reported by, Apr 15 2015

Issue description

Chrome is developing a Sidebar API (chrome.sidebar). benjamin.j.mccann will be leading development, and I will be the Chromium contact.

API proposal:

Since the proposal we have had discussions internally, and the minimum feature set we will initially launch with is:
- Sidebar is an HTML view, similar to popups. They are declared with a "sidebar" manifest key specifying a page to load: {"sidebar": {"page": "sidebar.html"}}. 
- Sidebar visibility is tied to toolbar buttons (browser action), similar to popup. Sidebars can only be shown by clicking on the toolbar button, and only a single sidebar can show at once. The last shown sidebar wins.
- While visible, the extension's toolbar button stays depressed[*]. This is sufficient for attribution.
- Sidebars only show on the right.
- Sidebars automatically grow and shrink depending on the content area, to some maximum width (similar to popups). In this way, extensions can implement minimization by shrinking the size of their sidebar.
- Sidebars can close themselves with window.close().
- Sidebars declare whether they should be shown only on a single tab, or for all tabs. The choice will depend on the use case: for example, a bookmarks manager sidebar will probably want to be shown globally, while an annotator for a specific website will only want to be shown on a single tab.

Am I missing anything? Did I add anything that we didn't agree on?

[*] To be finalised in UI review.

Comment 1 by, Apr 15 2015

"Sidebars declare whether they should be shown only on a single tab, or for all tabs"
And the proposal for that was to make it part of the manifest, like {"sidebar": {"page": "sidebar.html", "scope": "global"|"tab"}}.

I also forgot to mention that we will probably want a method like at some point, but TBD how that will fit in with the manifest key.
I'm not sure we came to consensus on this last point: "Sidebars declare whether they should be shown only on a single tab, or for all tabs. The choice will depend on the use case: for example, a bookmarks manager sidebar will probably want to be shown globally, while an annotator for a specific website will only want to be shown on a single tab."

This introduces some funky UI complexities. For example, what if you open per-tab sidebar A on tab 1 and per-tab sidebar B on tab 2, and then you open per-window sidebar C on tab 3? Would sidebar C be on all tabs? If you close C, will all sidebars be closed on all tabs?

Comment 3 by, Apr 15 2015

To answer that question: in the world where last extension wins, opening C would close all sidebars, closing it would keep them closed.

IIRC the other proposal we had there would be to make it always-global then extensions handle themselves what they show on each page.

However, that makes me realise a problem here: where do these sidebar pages run? Is there one per tab? Is there a single shared across all tabs? The former would be very wasteful and annoying if you want to have state synchronised across all tabs (and lots of tabs). The latter would make it impossible to have per-tab annotations. Honestly I don't even think it's possible.

Ideally I think you'd have a different view in per-tab mode, and a single view in global mode - but as I said, not sure that's possible. If it's not possible - we need to do something clever to avoid instantly creating a view on every tab.
There are basically three options: per-tab, per-window (sidebar opens on all tabs in a given window), and global (sidebar opens in all tabs in all windows). The code I have right now supports per-tab and global. As in Ben's comment, a bookmarks manager sidebar will probably want to be shown globally, while an annotator for a specific website will only want to be shown on a single tab. I wasn't sure the use-case for per-window, so I left it out.

I'm not sure this introduces any new UI complexities. Let's say you have extension A's sidebar open and then you open extension B's sidebar on the same tab. If you close B's sidebar, will A's sidebar re-open or remain closed? You need to answer this question regardless and supporting tab and global doesn't change that.
The UX logic makes sense to us as API designers, but I'm concerned that users would have trouble understanding the behavior and would consider it unpredictable. For example, imagine you have five tabs open, and you bring up different per-tab panels for the first four, each of which perfectly matches the content. You try to do the same for the fifth tab, you forgot it was global, and boom: you've wiped out all your hard work.

For this reason, I think we should choose just one of per-tab/global and stick with that. I'm leaning towards global.

Comment 6 by, Apr 17 2015

> You try to do the same for the fifth tab, you forgot it was global, and boom: you've wiped out all your hard work

The work here we're talking about is... opening a few sidebars. I think that's an acceptable loss, and a rare rare case that it'd even happen, and that people would care. Better to do the more commonly correct thing.

> choose just one of per-tab/global

Something else occurred to me: per-window *does* make sense. It's augmenting a window with a single panel, sort of like toolbar buttons. Global would mean opening a sidebar on every window, which means *loading a new extension page on every window*. That's something we need to be very careful about.
What do you mean when you say per-window is "augmenting a window with a single panel, sort of like toolbar buttons". A toolbar button is global, right? It's either on every window or no window.

Comment 8 by, Apr 17 2015

I mean that if "global" just meant "per tab on every tab" then you'd need to load a separate sidebar instance on every tab, and that'd be crazy. Instead, on the window scope you only need to load a single sidebar instance per window.
Having thought about the UI a bit, I think per-window is perfect (in addition to the technical reasons that Kalman has brought up). Firstly, the UI is consistent. Users don't have to think about whether a sidebar is per-tab, global, etc. It can always be per-window. This simplicity is a big win. Secondly, users can still have multiple sidebars open. This essentially replaces the per-tab use case. If you really want sidebar A on tab 1 and sidebar B on tab 2, just make them separate windows.
Hmm, I'm not quite sure I'm sold on the idea of per-window. Couldn't you say the same things about making the UI per-tab only? Users wouldn't have to think about whether a sidebar is per-window, global, etc. It can always be per-tab. Secondly, users can still have multiple sidebars open. And it's much easier than with the per-window case because you wouldn't need to make the tab be a new window.

If we're going to support only one mode, I think there may be a stronger case for per-tab. I think that per-window is the least intuitive of the options in many ways. There's nothing in Chrome today that works on a per-window basis, but there are lots of things that work on a tab or global basis. Global does have some technical challenges that may rule it out. So I think showing the sidebar only on that tab could be the best solution.

There are good arguments for both and I think this is the one part that's really hard to decide on when building just the UI portion first without the API. I think that many of the uses cases may be driven by the API and depending on what the API looks like, I could see one option or the other being a better choice.

There's also the openPopup API that's being discussed on another bug that I'm interested in as well. I offered to Ben today to try and send some code your way for that one too. If the extension calls openPopup and the popup is in sidebar mode, that may affect how we feel about this decision. I'd like to propose we punt on the per-tab vs per-window discussion for a bit. I can start sending you the UI component code without us making a decision on this part of it right now. Simultaneously I'll work on openPopup a bit and see if I can send you some code for that. I think that if we have a couple sample extensions that we can play around with to demo a couple different use cases in both per-tab and per-window that may help us make a decision we're happy with longer term that works the best with some of these other things like the toolbar redesign, openPopup, etc.
Landing code while we think about it some more SGTM. If there is something reasonable we can easily implement on top of that (whether tab or windows based - and I really can see arguments for either - but do think that per-window would be harder to argue given there is indeed no precedent for it in Chrome) when commit that and we can start testing it out.
"Sidebars only show on the right" is likely to be quite unpopular with end users. It appears (to an outsider) to be an attempt to visually associate the side bar with an extension button but ignores a lot of usability concerns which the users will have. I personally with rather vote for "Sidebars only show on the left" if it has to be one side only. I feel strongly enough about this to write the current comment and my guess is that the majority of end users will have equally strong or stronger feelings.
Re. #12: Could you elaborate on what usability concerns you anticipate? Scrolling is the only one that comes to mind at the moment.
Re. #13: Think for example of bookmarks, history and similar page index/directory sidebars. In virtually all programs where there is an index/directory pane and a content pane (e.g. - other browsers, file managers, IDEs etc.) the index/directory pane is on the left side and the content pane is on the right side. Even regardless of the (good) reasons for the existence of this visual idiom, reverting it would be a big usability problem for end users. A less prominent but still popular idiom is that content properties pane resides on the right. Therefore the implementation should ideally support both left and right placements but if this is not doable or too expensive then index/directory style extensions with their left placement should be favored since they are more likely to appeal to "regular" end users whereas attributes style extensions are more likely to appeal to developers only.
We could let an extension choose if it wants left or right? I agree that either makes sense. I prefer it underneath the buttons from an aesthetic perspective, but left does make more sense in a lost of cases as #14 says. Specifying left/right would also let you open 2 sidebars at once... for better or worse.
I feel strongly that we should stay away from 2 sidebars at once, and also that we should not give a choice of sidebar side to the developer. I think a better option would be to provide a button on the sidebar for the user to switch it to the other side.

Comment 17 by Deleted ...@, Jun 8 2015

A simple standard sidebar API would be great. I can think of use cases that would benefit from a left-side sidebar and even concurrent left and right sidebars. I agree it makes sense to let the user choose which side a given sidebar can appear on.
I agree too, it makes sense to let the user choose which side a given sidebar can appear on.

Comment 19 by, Jul 6 2015

Blocking: chromium:51084
Is there a reason the user could not choose to move it to the top or bottom also?
to #20

Then it will be some sort of toolbar, I think.

Comment 22 Deleted

Comment 23 Deleted

Blockedon: chromium:507400
Let's move this sidebar placement discussion to  bug 507400 . It is clearly important to many people, but I'd like to focus this bug on making progress.
Please don't develop a sidebar API. Sidebars are an outdate user interface, and their use by FF ( a travesty hodgepodge of outdate UI patterns ), is not something it works for Chrome ( the King ) to be be inspired by. Sidebar's have no analog in mobile, and the use of an obscuring "drawer" type menu has no place on the desktop. 

Please realize that the Chrome view portal is a sacred rectangle, it is _the_ portal to the most important apps for the majority of online humans. Please do not allow this sacrosanct rectangle to be obscured by extensions ( any more than they already do ), please do not legitimize or encourage these out dated patterns by making them part of the Chrome APIs. 

Chrome is _not_ going to lose ground to FF, if it stays true to its minimalist, "stay out of your way" roots and continues to provide awesome functional app and extension api, roots. It will however lose ground to FF if it compromises these principles, and misguidedly copies from the playbook of mistakes of an inferior product. 

It would work to focus on continuing the streamlining and minimizing of the browser "chrome frame" and enhancing ( rather than obscuring ) the presentation of web content. When it works to in fact enhance and annotate the appearance of that web content, I hope the Chrome team can continue to set the standard as they have done, by pioneering new ways of conveying information and facilitating people's interactions ( as they have on mobile with that awesome pull down to "reload, new tab or close" view ), instead of lowering their own bar implementing something the web would do well to leave to the UI trashbin of yesteryear. 
Further discussion of why sidebars don't work ( with examples from mobile ) 
I understand that sidebar API's can allow extensions with bad UI, but they do not in and of themselves bad UI because they can also allow extensions with good UI.

I mean, I would certainly like to have a vertical tabs bar on the left side, if you don't mind, because desktop resolutions allow for that and it helps me figure out my tabs in a way that I really enjoy and make use of. Would you really like to have that option denied from me?

It is a question, though, whether this API will be available on Android. Can the developers answer that, please?

Comment 29 by, Jul 7 2015

#27 & #28 Chrome on Android does not support extensions, so your concerns are not relevant.

#26 These sidebars are not required. If you don't like them, don't install extensions that use them.
An interesting question is whether it is possible to hide the sidebar (analogous to how extension buttons can be hidden by right-clicking on it and selecting "Hide button").

Comment 30 by Deleted ...@, Jul 7 2015

@longlive...: while I understand some of your points and find that having a sidebar can possibly lead to poor UX in many situations, we have to keep in mind the state of desktop resolutions today and going forward. As @mightyiampresence stated, he (and I) would absolutely love to have vertical tabs. This feature was in Chrome some time ago (under experimental features) and was awesome to use on my high resolution desktop monitors. As long as this feature isn't available on mobile, I think it would be great to have in place.
On the per-tab/per-window/global discussion, we'd definitely appreciate a solution that supports per tab.

We develop a chrome extension that has millions of users and we would only be able to use the sidebar API if it supported:

1) Annotating a web page case - i.e. user is looking at something, and they want more contextual information about that web page. That makes the per-tab solution very attractive to us. I'm not saying it should be the only supported mode but it would be crucial for us to have that mode supported.

2) Opening the sidebar from a content script. I know this is likely to be contentious but it goes along with the previous use case. If we analyze the page and see that we have some contextual information to show, we should push that to the user and not have them have to check whether we have any data to show them by opening and closing the sidebar every time.
I wonder how per-tab sidebar is going to behave when users clicks on another tab?
Is it gonna stay (with context of that previous tab and data related to it) or is it gonna close it self...
Changing rendered area in Chromiums it choppy, and closing sidebar (and changing the width of main frame) when switching to another tab could be really annoying (under presumption that sidebar is actually part of Chrome UI, and not injected panel that narrows the parent page)

same goes for in-tab navigation to another origin... 
I would loosely echo the sentiment in #31 — our extension has hundreds of thousands of users and the sidebar functionality we provide requires tab-specific information about the page being viewed.
We run some code inside a content script when a page loads to determine whether or not it makes sense to show the sidebar at all, at which point we allow the user to open the sidebar (it's default state is hidden).

Having a per-window API would be useful for many people I'm sure, and there is definitely reason to have that as an option. For our extension to use the sidebar API, however, we'd need to have per-tab capability *plus* API access inside content scripts.
You already do not have API such browserAction in content scripts. However, you can still have access to all such API via port connection from content script to background page. Some one might call it "proxy". So if sidebar API will have ability to open sidebar from the script (background page) then actually you will be able to open it from anywhere.

Proxying through the background page via message port would be a feasible workaround to trigger sidebar API methods from content scripts. For our extension, the real must-have is a per-tab option. 
Two questions:

1. Would the sidebar UI push the page content left? Or would it cover on top of current page?
2. Would the sidebar be able to communicate with current page? e.g. listen for mouse events from current page.
1. The current plan is to make the sidebar effectively make the window smaller, and push the content out of the way. We might explore a version which only shows temporarily and covers the page.

2. The sidebar content will live inside an extension process, so it will have access to all the privileged extension APIs. It will be able to communicate with the page via content scripts as usual.

Comment 38 by, Jul 9 2015

Opera already has a sidebar API (introduced in version 30). Instead of designing and developing a different sidebar API for Chrome, wouldn't it be useful to first check out their API?

Blog post on dev.opera:
Extensions documentation:
Yes, we've checked out their API. Opera's sidebar API is designed to be used with its own tab strip e.g. the ability to set the badge etc. Ours is built into the existing toolbar API.
Blockedon: chromium:508565
to #39

It's understandable because yours UI is different. But do not you think that mixing popups and sidebars to browserAction would be a bit confusing (for existing users)?
It shouldn't affect what the user sees, we can design it the way we want. The main difference between the APIs will be just that we don't need/want the ability for sidebars to change their icon, because they're not going to have a separate icon, the only icon they have is in the toolbar.

(however also note that the API structure itself isn't finalised.)
Idea: To provide a more predictable user experience, have global and/or per-window sidebars restricted to the left and per-tab sidebars restricted to the right.

Comment 44 by, Jul 16 2015

there's also data sharing thingie between sidebars (no matter per-tab or per-window)

if user have two sidebars of the same extension opened in, for instance, two windows, and change data in one sidebar, how that change will effect other sidebar of the "same" content?
In Opera that procedure is left to developers, but that sucks...
I have to listen for storage change and window focus, then test if change is happened in focused window (to refresh or not) and if not in focused, then refresh it
basically it creates annoying refreshing when user switching focus, no matter between browser windows or for instance open/save dialog popup window.
Because if "old" content is presented to user, it might create serious issues/bugs
the best solution would be to have some internal listener, and if change happened in non-focused sidebar, to refresh it on focus

#43 I will reply to that in  bug 507400 .

> In Opera that procedure is left to developers, but that sucks...

Regardless, this is the most flexible, and is logic we will implement (i.e. no special logic). Refreshing the sidebar on focus is magical and I don't think it will work properly in all cases (e.g. who is to say that focus is the only time you want to update; plus reloading on focus would be a bad UX).
My own sidebar and those of many that have expressed interest in this are used such that the sidebar is in the context of a page's contents or used to annotate a page's contents and may only apply to some tabs. While my initial inclination was towards per-tab, I believe that we can make the other solutions work well for our use case as well. If we go with a per-window approach we can still have the option of having the extension hide/shrink the sidebar for pages where the sidebar doesn't have related contents.

One of the reasons why we may end up going with per-window is that it allows us to minimize resource usage for users that have sidebar extensions. For the users that don't have any sidebar extensions installed or active there shouldn't be any impact on performance or resource usage in either case.
 Issue 51084  has been merged into this issue.
Blocking: -chromium:51084

Comment 49 by Deleted ...@, Aug 24 2015

I admire the effort here to standardize the sidebar practice & strive for a better user experience. I echo the suggestions made in #31 and #33. I also develop a Chrome extension that augments Gmail with CRM information. I have two suggestions based on my field experience:

 * Ideally, the sidebar could follow some rules of matching urls. Because sidebar provides contextual information that is relevant to current tab. Consider Rapportive, a Sidebar Chrome extension used by hundreds of thousands of people, it is only valuable in profile pages like LinkedIn, Twitter, Facebook, and Gmail, but much less useful in other places. The per-window option would make the sidebar useless in 90% of browsing cases. And per-tab option would require the user to click-to-open sidebar manually every single time he/she opens a new LinkedIn/FB/Twitter page, which would lead to low engagement. However, if I have to choose between window vs. tab, I'd probably go with tab.

 * A showSidebar() API would be extremely useful. This allows the extension to programmatically determine the open-sidebar logic. With this, the above matching-url-rules would be unnecessary. However, I understand the implications here on malicious extensions (cannot call show / hide in rapid succession?), and contention among multiple extensions (last one wins?).

From my experience developing a sidebar Chrome extension, and having studied multiple extensions in the same field, I feel that without offering the flexibility to determine open-sidebar-logic based on url rules (or preferably business logic), this API might not see much adoption among enterprise-extension developers.

Comment 50 by, Aug 24 2015

To resolve the problem of which sidebar to show simply show all the open sidebars permitted by url-matching or explicitly opened by user as either:

* a vertical stack (useful for large or vertical displays)
* last one expanded, others collapsed/docked

See the attached screenshots from CorelDRAW where it was implemented more than 10 years ago. Similar UI is present in lots of applications.
4.1 KB View Download
12.3 KB View Download

Comment 51 by, Aug 24 2015

@44 there's also data sharing thingie between sidebars (no matter per-tab or per-window)
Not exactly... Each window has independent sandboxed background page, there is no communication between them apart that we can save data to disk.
Otherwise you can use
runtime.connect(), tabs.connect() or runtime.onMessageExternal()
just like in standard extensions, but each sidebar acts on its own. What I don't like about it, is that I can't find out in which sidebar is displayed, standard chrome's API does not help, since there is no connection with it.
By the way I'm the author of this:
And as soon there will be sidebar in chrome I will do the port.

Comment 52 by, Aug 24 2015

@49 However, if I have to choose between window vs. tab, I'd probably go with tab.

What benefit would that have? Each tab would have to communicate with all others, causing big overhead and probably higher cpu use, especially if you want the same content for all tabs. Yes it can benefit sandboxing the tabs content, but you have access to tabs from chrome's API anyway.
If you go per window, you can just add listeners in extension when active tab is changed and do your stuff.

Comment 53 Deleted

Relevant to the discussion, now that Firefox is shifting to a largely-compatible extensions API ( ), they also plan to implement a sidebar API:

> We plan to add our own APIs based on the needs of existing Firefox add-ons.
> * Sidebars. Opera already supports sidebar functionality; Chrome may soon. We would like to be able to implement Tree Style Tabs or Vertical Tabs by hiding the tab strip and showing a tab sidebar.

It would make sense for Chrome devs to interact with FF devs to make the implementation as standard as possible.
«It would make sense for Chrome devs to interact with FF devs to make the implementation as standard as possible.» An excellent idea !...


Comment 56 by, Aug 24 2015

I don't think you understood what i wrote. 
I was complaining about the lack of internal data sharing.
and btw. it's very easy to get windowId thorough windows API and maintain logic based on that for each sidebar

Comment 57 by, Aug 24 2015

Indeed, thanks for correcting me, I re-read what you wrote. Yes it's like you say. So we both agree, there is a lack of any communication.

As for windowId, there is no way to discover in which window you are currently in, I'm not talking about current or active window which is unrelated to a sidebar. For example when window is not active and you wan't a list of tabs from window where sidebar is you have only active windowId or a list of "other" windowIds, you have no connection with a sidebar. Simply, at this point, sidebar does not know in which window it is. In my extension I get windowId from active window, but you end up with the same list of tabs in each sidebar (from active window) when you restart browser with multiple windows open. You have to re-open each sidebar to have correct tabs for each window. Something like sidebar.windowId would be really useful in my opinion. I'm not sure if I explained it well.

Comment 58 by, Aug 24 2015

in your panel script, at the start, call 
 chrome windows.getCurrent
and write ID from it in some global var (thisWindowId)
so that every sidebar knows it's parent windowId
when you needed it, for instance, if you send message to your sidebars, each of it will collect it's own global variable (thisWindowId) and act based on it... response or whatever
...or on windows.onFocusChanged compare newly focused with your global var and decide weather you are in focused sidebar window or not...

Comment 59 by, Aug 24 2015

Problem is that every single sidebar gets windows.onFocusChanged event, and yes I can save to disk and read it in other sidebars, no problem here, but each sidebar gets only one windowId which is from active window; and each thinks it's in this window which is wrong. There is no connection with sidebar! I don't know how to explain this better... When Opera starts with multiple windows, All sidebars will get exactly this same windowId from active window from chrome's API, unfortunately, there is no way to tell where sidebar currently is open! The only thing I found in Opera's API is opr.sidebarAction.onFocus, then I know what correct windowId is, but user must click anywhere in the sidebar, which is not what I'm after, beacause I know then anyway that this window is active and I can get it from Chrome's API. The other one which can give me sidebar's windowId is opr.sidebarAction.onBlur, which fires when sidebar looses focus, but what if it never had focus in the first place? It never fires up when browser starts. I asked Grzegorz Miazga from Opera, if they could implement some other way to get sidebar's windowId, they asked me for an example where it could be used, so I explained it to them, but had no further response.
when will this be available? it's hugely valuable, and just wondering if there's a goal date.

Comment 61 by, Aug 25 2015

"Problem is that every single sidebar gets windows.onFocusChanged event, and yes I can save to disk and read it in other sidebars, no problem here, but each sidebar gets only one windowId which is from active window"

you don't save it to the storage, you just keep it in global var, and compare it to onFocusChanged result. If they match, you are in focused window.

Comment 62 by, Aug 25 2015

Hmmmm... When I start I get in all sidebars WindowId from active window (one in focus and not windowIds where sidebars are), then when onFocusChanged triggers in all sidebars I will get new WindowId from the last focused window since I don't know where to send it, I can only send it to all, because sidebars don't have any type of Id, nor they have any information in which window they are and not even they know if they are focused (until clicked), and in all sidebars list of tabs will be from that new focused window, still does not solve the problem... You say compare, but with what? With first active windowId? All sidebars have that one windowId, which is wrong. As I said before, only way to get the correct windowId is opr.sidebarAction.onFocus, but user must click somewhere in the sidebar. Still I don't have correct windowIds from inactive windows, until activated and clicked on the sidebar. Then I can compare, but it may be frustrating to click each time you close and reopen the sidebar. If I went this route all sidebars would display tabs from active window, so when you would switch window I would redraw tabs in all sidebars, but it would be extremely slow.
All vertical tabs extensions so far, display tabs from all windows to avoid this problem, I wan't display tabs just from one window. So far I have no solution to that. So when you restart browser with multiple windows, you have to reopen all sidebars to have correct tabs in each window.

There should be a sidebar object, that we could use without needlessly complicating our code.
Things like windowId, tabs, width, icon, listeners onFocus, onHover, onBlur and so on, for each open sidebar.
This is what I would love to see done better in Chrome, since opera's sidebar is really limited.

Comment 63 by, Aug 25 2015

you should read more carefully :)

first, at the start get current window ID and save it to some var
onFocusChanged comapare result to saved var...that's it.

my extension manipulate windows, and splits tabs by windows in single list
it's not over yet, I'm about to update it thise days with other stuff and bug fixes, but spliting tabs into windows groups is something that it does from the start
it's not a problem to present tabs only from current window
but I want to have all possible windows in one list
that's the whole point of it

Comment 64 by, Aug 25 2015

Oh so you are vux777 :) Hello there :) You are my biggest inspiration :)
I've read that carefully, but I'm not sure if you got my point.
"first, at the start get current window ID and save it to some var
onFocusChanged comapare result to saved var...that's it."
It still does not give me Id's for sidebar just some random active window. There is no correlation between active window and sidebars windows. I can just hide tabs from other windows when I get correct windowId, for example from opr.sidebarAction.onFocus and compare with one from the start, but only after a click. Otherwise all sidebars are just clones, displaying tabs from active window. Just like you have all tabs from all windows, split in windows groups. You can for example scroll to active window group when you get id from onFocusChanged, and so on. But in my case I want tabs only from one window. And on startup when windows are not in focus I have no way to do it correctly.

So fingers crossed Chrome folks won't do a poor job with their sidebar and will give us some sidebar object with some options. We are here for that aren't we?

Comment 65 by, Aug 25 2015

let's continue here

because kalman and others are probably on the edge of deleting our chitchat 

Comment 66 by, Aug 28 2015

To those who are interested, we discovered a bug in opera, when calling get current window from sidebar's script, it returns active windowId instead of sidebar's one, this is why I said to vux that there is no correlation between sidebar's windowId and chrome's windowId. But actually there is! It has been fixed in the latest developer version, but I'm not so sure if it's only Opera's bug, because they didn't mention anything about this, and bug disappeared when they upgraded their source to Chrome 46.
Nonetheless some kind of a sidebar object with all Id's would be the best in this type of situations.

Comment 67 Deleted

Hey everyone, I'm jumping into the conversation, I'd love to see this sidebar thing happening!

A few suggestions though:

1/ How about allowing to set a custom position of the sidebar to right, left or bottom?

2/ And how about not defining a maximum size for the panel? Being able to play with the dimensions of the sidebar would allow to do some powerful stuff. And if an extension starts messing with my screen estate I'll just uninstall it anyway... So let the developer community and the end users eventually decide, no?

3/ A method to open/close the sidebar would also be very useful.

Here's what we achieved on Firefox thanks to those points:

Comment 70 by, Sep 6 2015

Regarding per-tab vs. per-window: I argue that both should be supported, and one sidebar of each type be allowed to be active at one time.

My rationale is that these are actually different, and orthogonal, use cases. As such this should be reflected in the UI as well:

- The per-tab sidebar should appear to push the content of the tab ("the webpage") out of the way to make room for the sidebar, leaving the Chrome header unaffected.
- The per-window sidebar should push the entire Chrome UI out of the way (that is, the Chrome header area plus the content area) to make room.
- They should be allowed to coexist: while I have a per-window Vertical Tabs sidebar open, I may also have a per-tab Annotations sidebar open within the current tab.

I think this distinction is important because per-tab and per-window sidebars naturally have a different degree of persistence (per-tab being more transitory), a different associated UI scope (one tab vs many), and orthogonal UI concerns (e.g. managing all tabs vs. annotating a specific tab).

Comment 71 Deleted

Comment 72 by, Sep 7 2015

@70 I see your point, so if we would have a choice how our extension should behave then I'm more than satisfied :)

Comment 73 by Deleted ...@, Oct 5 2015

I get the following assertion failure with test sidebar extension (chrome/test/data/extensions/sidebar) and

[10231:10231:1006/] Check failed: host_type == VIEW_TYPE_EXTENSION_DIALOG || host_type == VIEW_TYPE_EXTENSION_POPUP. 

master as of today.
Status: Untriaged
Meanwhile I have found a clever way to make a sidebar with Bookmarks, History and Google Search using Chrome DevTools - see:
Update: the sidebar above is now available in the Chrome Web Store:

Can we have an update about the state of the sidebar please ?

Thank you.
Status: Assigned
Mass triage! Please close, find an owner, or assign back to me. Thank you!

Comment 80 Deleted

Is this still ongoing ?
Labels: -Pri-2 Restrict-AddIssueComment-EditIssue
Owner: ----
Status: WontFix
We will not be proceeding with this feature request. We recognize that there is a significant number of you who will be disappointed with this decision, evidenced in part by the many stars on this issue. We debated it extensively, both inside the team and with members of the community. In the end we decided that the WontFix resolution was more in keeping with Chrome's core value of simplicity (
 Issue 733634  has been merged into this issue.

Sign in to add a comment