Sidebars are not properly displayed in New Private Window
Categories
(Firefox :: Private Browsing, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox46 | --- | wontfix |
firefox47 | --- | wontfix |
firefox48 | --- | wontfix |
firefox49 | --- | wontfix |
firefox50 | --- | fix-optional |
firefox51 | --- | fix-optional |
People
(Reporter: JuliaC, Assigned: janne+mozilla)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
Comment 1•9 years ago
|
||
Updated•9 years ago
|
Comment 2•9 years ago
|
||
Updated•8 years ago
|
Comment 3•7 years ago
|
||
Comment 4•7 years ago
|
||
Updated•7 years ago
|
Comment 5•7 years ago
|
||
Updated•7 years ago
|
Comment 7•7 years ago
|
||
Comment 8•7 years ago
|
||
Comment 9•7 years ago
|
||
Comment 10•7 years ago
|
||
Comment 11•7 years ago
|
||
Comment 12•3 years ago
|
||
The steps to reproduce don't capture the fact that if you leave a private window open, then the sidebar is closed in any new non-private windows, and vice-versa. For example, if you are opening multiple windows, alternating between private and non-private, the sidebar gets closed every time.
It seems to me that in the most common use cases for the sidebar, the user would prefer to keep it open consistently, regardless of the window type - to show history or bookmarks, or in the case of the many people like me who use Tree Style Tab, to show tabs. Personally, I find that I'm constantly having to turn the sidebar back on to see my tabs, which is frustrating.
Is the reason for the decision in bug 885054 a decade ago still valid? Now that we are able to specify which extensions can run in private windows, does that change the question? Should it be framed in terms of determining the opening state on the basis of what extension or feature is using the sidebar, and whether it's allowed to run in private windows? If so, does that require a new bug?
Updated•2 years ago
|
Assignee | ||
Comment 13•7 days ago
|
||
This is incredibly useful for users of Sidebery or Tree-Style-Tabs.
We might as well change the default in the future, since I don't see any
privacy concerns, but let's have that conversation another timer.
Updated•7 days ago
|
Adding the comment here that I added in phabricator when I resigned from reviewing this patch:
Hello, thanks for your interest in contributing to Firefox. I'm not actively involved with work on the sidebar, so I'm not sure I am the right reviewer for this patch. I see you have also requested a review from timhuang, who is the triage owner and may have bandwidth to mentor you, but I would suggest needinfoing him in the bug, or making contact on matrix, as a first step. Assuming he has bandwidth to guide you, he will outline the right approach to fixing the bug.
I will add that this seems like the wrong approach to me, because add-ons may sometimes not be granted access to private windows by users, so it's essential to preserve the private window checks--see https://support.mozilla.org/en-US/kb/extensions-private-browsing for details.
Updated•6 days ago
|
Description
•