Closed Bug 729865 Opened 13 years ago Closed 12 years ago

UI for per-window private browsing on desktop

Categories

(Firefox :: Private Browsing, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
relnote-firefox --- 20+

People

(Reporter: jdm, Unassigned)

References

Details

(Keywords: meta)

Attachments

(3 files, 1 obsolete file)

Thinking out loud, I expect we'll want: * a new menu item (New Private Window) * a new context menu item (Open Link in New Private Window) * remove Start/Stop Private Browsing menu item * disallow dragging tabs to windows of a different privacy nature Things I would like, but need UX feedback: * keyboard shortcut - I dearly love Ctr+Shift+N for Chrome's Incognito mode, but we currently use that to reopen closed windows. Could it be repurposed? * visual indicator for private windows - I believe this was nixed in the past, but given that every other major browser has this, it's probably worth considering again
Attached patch WIP - Add UI for per-window private browsing. (obsolete) (deleted) — Splinter Review
ISTR Steven already has some mockups of what UI changes should be applied in PB mode?
Comment on attachment 599916 [details] [diff] [review] WIP - Add UI for per-window private browsing. This is just a really simple proof-of-concept I've been using to test out my changes to other components (eg. history). The about:privatebrowsing changes help demonstrate that the window-level API functions - in a non-private window, you'll see the option to start private browsing, while in a private one you'll see a description of what private mode is doing for you.
Attachment #599916 - Attachment description: Add UI for per-window private browsing. → WIP - Add UI for per-window private browsing.
Depends on: 723353
This is the last mockup ( http://people.mozilla.com/~faaborg/files/20111101-cuttingRoomFloor/stealth-firefox4-full.png ) that I have found, but I think Stephen Horlander may have ones updated on the Australis design.
(In reply to Justin Dolske [:Dolske] from comment #2) > ISTR Steven already has some mockups of what UI changes should be applied in > PB mode? Currently we change the Firefox button from orange to purple. But that is only on Windows Vista/7 or XP if the user enables it. Things we have talked about in the past include completely skinning the browser with a dark theme: http://people.mozilla.com/~shorlander/private-browsing-mode/mockups/australis-pbm.png Basically a look for "stealth mode". Which would be quite awesome, but would probably be a lot of work and there are always the concerns of whether or not you want to advertise you are in private browsing mode. Considering impending UI changes I will put some thoughts into a consistent indicator we could use on all platforms.
Has there been any updates on this?
Blocks: 748802
No longer blocks: 748802
Depends on: 749390
Depends on: 749394
OS: Mac OS X → All
Hardware: x86 → All
Commit pushed to master at https://github.com/mozilla/addon-sdk https://github.com/mozilla/addon-sdk/commit/dde5e5600780b592cb1e90711f38e9df6ad615bc Update packages/api-utils/lib/private-browsing/utils.js mention bug 729865 in comments
Summary: UI for per-window private browsing → UI for per-window private browsing on desktop
Blocks: fxPBnGen
Depends on: 799001
Comment on attachment 599916 [details] [diff] [review] WIP - Add UI for per-window private browsing. My patches in bug 799001 do this and more.
Attachment #599916 - Attachment is obsolete: true
Attached image Windows 7 Aero mock-up (deleted) —
(Received these mock-ups from shorlander)
Attached image Windows Australis mock-up (deleted) —
Attached image Mac Australis mock-up (deleted) —
Blocks: 456884
Depends on: 816914
No longer blocks: 456884
Depends on: 456884
This work is subsumed by lots of other bugs.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Is it? My understanding is that we still wanted a new window styling before shipping per-window PB. Is that work happening in a different bug?
Yeah, that's bug 749394. I didn't notice that this one is acting as a tracking bug, so I'll mark that explicitly.
Status: RESOLVED → REOPENED
Keywords: uiwantedmeta
Resolution: WONTFIX → ---
Bug 823683 was marked a duplicate of this, but I'm not sure this is the correct bug, especially considering this is a meta bug for UI changes and bug 823683 was not about a UI problem. Bug 823683 comment 5 stated that changing the never remember history preference would require a restart, which would negate the problems I'm seeing. Is that what this bug is for, if not bug 823683 should be attached somewhere else.
(In reply to Michael Kraft [:morac] from comment #16) > Bug 823683 was marked a duplicate of this, but I'm not sure this is the > correct bug, especially considering this is a meta bug for UI changes and > bug 823683 was not about a UI problem. > > Bug 823683 comment 5 stated that changing the never remember history > preference would require a restart, which would negate the problems I'm > seeing. Is that what this bug is for, if not bug 823683 should be attached > somewhere else. I corrected my mistake there.
(In reply to Josh Matthews [:jdm] from comment #14) > Yeah, that's bug 749394. I didn't notice that this one is acting as a > tracking bug, so I'll mark that explicitly. FWIW this bug has outlived its usefulness, but I have no objection to keep it open until bug 749394 is fixed.
Component: General → Private Browsing
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: