Do more on the web, with a fast and secure browser!

Download Opera browser with:

  • built-in ad blocker
  • battery saver
  • free VPN
Download Opera
  • *this is continuing discussion from chromium bur report, and since it's not related exacly to chromium issue itself, I'm opening this thread... *

    when you call
    at very "start" of your panel script, it will fetch ID of the window that is currently focused and in which code is executed.
    And that is the window in which user opened sidebar.
    Even if user starts with multiple windows and every of those windows have opened sidebar automatically, still, there is enough time for your code in every individually sidebar records it's parent window id.
    Because those windows are opened one by one (in short period, but not in infinitely small moment)

    var thisWindowId; {
    thisWindowId =; {
    if (thisWindowId === newWinID) //this sidebar instance is in focused window

    also you can use thisWindowId in tabs.onUpdated(tab), onActivated.... etc....
    moste of them will give tab.windowId that you can compare to your thisWindowId and choose what to do with that tab, eg. is it in this window or not
    if method that you need doesn't give tab.windowId, it will surly give, and from there you can find windowId

  • Hey there 🙂 Sorry for late response, I will be here just for a moment since I have something to do, but I will be back in few hours 😛
    Yes I'm using this when sidebar opens, each sidebar gets this same windowId because this windowId is not the id where the sidebar is, it's from Chrome's API and unfortunately it's not related to sidebar's window. You can check it with my extension if you want.
    Open few windows with my extension, exit opera (using ctrl+Shift+x), or from menu->exit opera.
    Start Opera; In result you will get tabs from active window in all windows with sidebars, "cloned".

    Problem is here:
    "still, there is enough time for your code in every individually sidebar records it's parent window id."

    Where do I get that parent window id? There is no way to guess in which window sidebar is. It does not matter if window is active or not.
    onFocusChanged does not help me, correct tabs will be only in first focused window, since all sidebars do exactly the same code and all will think they are in focused window which is not true.
    I'm not sure if you get what I mean. There is no connection between chrome's API and sidebar's API...
    Only from here:
    or here
    Both are not good on Opera's start since there is no action from user.

  • @kroppy
    well, let's try this way :wizard:

    I don't know how you did logic in your extension, this is example from my code

    this is for individual opening

    ...and this is when users starts with multiple windows

    every sidebar is aware of it's parent window :smurf:

  • You made me scratch my head for hours here. But I found the problem.
    And it's not in my code.
    When I use:{alert(;});

    All I get, are alerts with the same id.
    So I watched your video ten times, and noticed no difference between what I do.
    But after a while I realized that you use Opera dev!

    So I checked Dev 33 and baaaam!

    Problem f*cking solved!

    In opera dev 33, gives me frigging different ids !!!!!
    Now I know that problem is that in CURRENT STABLE version there is NO WAY to get current windowId, where the sidebar is! Check it out for yourself!
    The bug was just here,, returns ACTIVE windowId on startup.

    Cheers and thanks for your time

  • I think your problem is in alert, try using console.log (it behaves differently, not good to test these things with alert)
    In my first video, I'm using stable.... didn't want to break work, so for second video i used developer
    on my side it works fine in stable just like in dev

  • I did a little test with stable and all sidebars get this same windowId as active window. I have no doubt here.

    This seems to be fixed in dev 33 version, it looks like they finally linked current windowId with sidebar, so I'm not sure if it's worth a further investigation here, but I double checked it with opr.sidebarAction.onFocus.addListener with log inside.

    If you have a moment you can compare dev and stable and see the results for yourself.
    Paste that at the top of your sidebar's script:

    opr.sidebarAction.onFocus.addListener(function(window) {{populate:false}, function(current_win){
    console.log("You focused sidebar in window with id: "" sidebar window id: ";

    In opera stable you will see that both ids are equal when focus is changed, in dev you will get correct id, where sidebar is and the one from focused window.

    I discovered that thanks to you, so I'm glad I checked dev, since it's been a while since I used it.

  • you don't need to use sidebarAction.onFocus
    it's new and probably buggy still (not ready for mac yet, from docu)
    when you have onFocusChanged already for windows

  • "onFocusChanged" don't worry I'm not using it anyway, yes it gives this same, but on click and it's not buggy, it works perfectly (at least on pc). I only pointed out that will give you different windowId in dev and stable Opera. Which I'm after. I consider it as "solved" but only in dev version, hopefully it will work when Opera 33 hits stable. 🆙 :happy:

  • Opsss i copied and pasted "onFocusChanged" instead of "sidebarAction.onFocus" in my previous post. Can't edit since I went to eat, and now it's too late 😛

  • uhmmm...btw, current window is window in which code is currently not necessarily focused one...
    why there is different behavior between dev and stable, I'm not sure...
    maybe Stable is doing some more actions when switching between windows... so getCurrent is fired while some process are still hooked on stable

  • I'm asking myself why that happens... In chrome there was no way to tell since all extensions where just in a popup (or a separate popup window), so active window was usually the current one, so maybe it's a recent fix in chromium 46, but I can't tell if that is the case. Or maybe just a bug in Opera. 😕