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)
Tracking
(firefox57 fix-optional)
NEW
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.
Comment 1•7 years ago
|
||
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.
Comment 3•7 years ago
|
||
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)
Updated•7 years ago
|
status-firefox57:
--- → fix-optional
Priority: -- → P3
Comment 5•7 years ago
|
||
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.
Updated•7 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•6 years ago
|
Product: Toolkit → WebExtensions
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•