Open Bug 1397210 Opened 7 years ago Updated 2 years ago

[OOP] Opening sidebar link inconsistencies with new tab active state and container inheritance

Categories

(WebExtensions :: Frontend, defect, P3)

57 Branch
defect

Tracking

(firefox57 fix-optional)

Tracking Status
firefox57 --- fix-optional

People

(Reporter: ke5trel, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

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.
Blocks: 1392210
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.
No longer blocks: 1392210
Depends on: 1392210
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.
Flags: needinfo?(kestrel)
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.
Flags: needinfo?(kestrel)
Blocks: webext-oop
No longer depends on: 1392210
Keywords: regression
Priority: -- → P3
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Product: Toolkit → WebExtensions
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.