I've noticed some inconsistencies with opening sidebar links. With OOP disabled: Left-clicking loads in the current tab (uses current tab's container). Middle-clicking creates a new background related tab (inherits current tab's position and container). With OOP enabled: Left-clicking creates a new active quasi-related tab (inherits current tab's position but not container). Middle-clicking creates a new background unrelated tab (end of tab strip with default container). Suggestions: 1. Left-clicking should inherit the container of the current tab given the new tab's position is related to the current tab. This would be similar to OOP disabled behavior but in a new tab. 2. Middle-clicking should create an active tab given it is no longer related to the current tab. Creating background tabs that aren't visible in the tab strip feels wrong. Creating unrelated active tabs is consistent with bookmarks sidebar.

Behavior after bug 1392210 should match what happens with the clicks in a pinned tab. However, there is also bug 1396988 for a similar problem with pinned tabs when it comes to links in iframes in the pinned tab. How the tabs are opened is a matter of other prefs and have nothing to do with the sidebar specifically.

So Shane is this a dupe? Not sure next steps based on comment 1.

I was leaving it to kestrel to resolve whether its still an issue, but IMO it's either a dup or invalid.

I tested again in 57.0a1 (20170907100318, Windows 10) in a clean profile with the test extension isAppTab.xpi from Bug 1392210 which provides a sidebar with a plain link without subframes and got the same results. No other settings were changed other than OOP enabled/disabled (extensions.webextensions.remote = true/false). The behavior with OOP enabled does not match clicks in a pinned tab as detailed in comment 0.

I dont think this is a webextension bug, beyond fixing link traversal, we don't do anything related to what kind of mouse click is happening, that is all lower level. Link traversal only does a fixup on the link target (forcing _blank) if not specified to make the link open in a new tab. It has nothing to do with altering behavior of that tab opening. So basically, bug 1392210 fixed the ability to open from WE panels into the tab, but doesn't address differing click behaviors.