Provide the ability to enter private browsing from within Firefox Metro

RESOLVED INVALID

Status

Tracking
Metro Operations
P1
normal
RESOLVED INVALID
6 years ago
3 years ago

People

(Reporter: bbondy, Unassigned)

Tracking

({feature, meta})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [story])

Attachments

(2 obsolete attachments)

(Reporter)

Description

6 years ago
Firefox Metro currently does not have private browsing.  This task is to add an option and keyboard shortcut to enter private browsing when in Metro XUL Fennec.

The Metro browser should simply be restarted in private browsing mode for now.

I couldn't find an option in IE10 to enter private browsing when in Metro mode, but I could find an option to do this in Metro Chrome.

Comment 1

6 years ago
Why would we want to restart Firefox for this?
(Reporter)

Comment 2

6 years ago
I figured simply restarting the browser with firefox.exe -private would be a straightforward and fast implementation, but if you have a better suggestion please share. 

I'm not familiar with private browsing code yet, but I know you are :)

Comment 3

6 years ago
I think we want to get per-window PB working here first, and then just set the flag on the docshell.
Depends on: 463027
(Reporter)

Comment 4

6 years ago
There is only 1 Window in Metro mode.

Comment 5

6 years ago
(In reply to comment #4)
> There is only 1 Window in Metro mode.

Yes.  What I meant was that it would be way easier to implement this on top of the infrastructure that we're working on for per-window PB.
(Reporter)

Comment 6

6 years ago
Is there enough of that new infrastructure landed already that I (or someone else) can work on this? If not, do you know when that will be ready?

Comment 7

6 years ago
(In reply to comment #6)
> Is there enough of that new infrastructure landed already that I (or someone
> else) can work on this? If not, do you know when that will be ready?

Not yet.  The timeline is not clear.  We currently don't have anybody working on this, and are getting contributions from the community.  Chris Lord wanted to work on this as a prerequisite for the mobile PB mode, but I think he's now pulled off into other projects.  :(
(Reporter)

Comment 8

6 years ago
Are you opposed to me filing another bug to do the post new infrastructure work in a new bug, and using this one to restart the browser in PB mode?

Comment 9

6 years ago
(In reply to comment #8)
> Are you opposed to me filing another bug to do the post new infrastructure work
> in a new bug, and using this one to restart the browser in PB mode?

Yes, I don't think that's the direction that we want to take.  I'm fine with you landing your changes here hidden behind MOZ_PER_WINDOW_PRIVATE_BROWSING which is not defined yet.  Not sure how much that helps you.

What's the timeline for this work from a Firefox Metro perspective?
(In reply to Ehsan Akhgari [:ehsan] from comment #7)
> (In reply to comment #6)
> > Is there enough of that new infrastructure landed already that I (or someone
> > else) can work on this? If not, do you know when that will be ready?
> 
> Not yet.  The timeline is not clear.  We currently don't have anybody
> working on this, and are getting contributions from the community.  Chris
> Lord wanted to work on this as a prerequisite for the mobile PB mode, but I
> think he's now pulled off into other projects.  :(

I must apologise for jumping the gun a bit, I assumed that my work on bug 758620 would be over pretty quickly, but the problems it caused/exposed took a while to sort out. I'm hoping that with bug 769541 looking like it's finally fixed, I'll actually be able to start work on this properly, but I'll be away for a week and a half from Wednesday, so I won't seriously be able to start before then.

Until then, don't let me block anything, but I really ought to be able to start working on this properly come August 6th.
Personally, I'm inclined to let Brian implement PB mode however he wants to at the moment. I'm not convinced per-window will make it in time for 17.
(Reporter)

Comment 12

6 years ago
> What's the timeline for this work from a Firefox Metro perspective?

There's no detailed requirements.  I think Windows 8 should be released at the end of October.  The goals list have alpha/beta by the end of the year. https://wiki.mozilla.org/Firefox/Roadmap


> I'm fine with you landing your changes here hidden behind 
> MOZ_PER_WINDOW_PRIVATE_BROWSING which is not defined yet.

I'd rather wait in that case.

Comment 13

6 years ago
According to https://wiki.mozilla.org/RapidRelease/Calendar, shipping something in beta by the end of the year corresponds to Firefox 18, so we still have a bit of time.  But if/when this becomes a priority, please check back with me, as we might need to get somebody working on this full-time (assuming that Chris would get pulled into other projects...)

Sorry for being so strict here, but I don't want us to resort to a hack (restarting the browser) until we absolutely have to... :/
(Reporter)

Comment 14

6 years ago
np! Thanks for the info.
(Reporter)

Comment 15

6 years ago
Would we need multi window support in order to consume the new work being done for private browsing per window?  Can we do it per tab easily?

Comment 16

6 years ago
(In reply to comment #15)
> Would we need multi window support in order to consume the new work being done
> for private browsing per window?  Can we do it per tab easily?

The new API is per-docshell.  While Firefox Desktop would not have the UI for this, it is possible to get it to work per-tab.
(Reporter)

Updated

6 years ago
Assignee: netzen → nobody

Updated

6 years ago
Component: Private Browsing → General
Product: Firefox → Firefox for Metro
Version: unspecified → Trunk
(Reporter)

Updated

5 years ago
Duplicate of this bug: 801095
(Reporter)

Updated

5 years ago
Whiteboard: [metro-mvp] [LOE:2]
(Reporter)

Comment 18

5 years ago
This can be implemented now right Ehsan?
Absolutely.

Comment 20

5 years ago
(In reply to comment #18)
> This can be implemented now right Ehsan?

Yeah, but I'd like us to sit down some time and have a chat about this so that everybody knows where we're going and what we need to do.

Comment 21

5 years ago
We won't block shipping Metro on private browsing. We can get to this in a v2. For v1, if a user needs private browsing, she can use the desktop version.
Whiteboard: [metro-mvp] [LOE:2] → [metro-mvp-] [LOE:2]

Updated

5 years ago
Duplicate of this bug: 771174

Updated

5 years ago
Blocks: 842686
Whiteboard: [metro-mvp-] [LOE:2]

Updated

5 years ago
Component: General → Components

Updated

5 years ago
Blocks: 861680

Updated

5 years ago
No longer blocks: 842686
Keywords: feature, meta
Whiteboard: [story]
Depends on: 957165
For scoping/estimating purposes, front-end work will include:
* Creating a private tab
* Displaying private tabs in the tab strip
* Custom "new tab" experience for private tabs
* Inheriting private status when opening links/searches in new tabs
* Preserving (or not?) state when switching between desktop and Metro
Created attachment 8356806 [details] [diff] [review]
prototype code

Here's a patch that adds a "new private tab" button in the Metro tab strip.  This is nowhere close to the final UX, and it is missing some vital privacy pieces like integration with sessionstore.  However, it could be useful if you want to test how the platform feature works when running in the Metro UI.

Comment 25

4 years ago
Note that private tabs do not work 100% correctly.  We have been operating under the assumption that once a docshell is private, all of its child docshells are private.
Created attachment 8358579 [details] [diff] [review]
WIP

Here's a slightly more complete patch, which adds proper session store support, a keyboard shortcut, makes new tabs inherit the private state from the parent tab if there is one, and adds a pref to hide the (incomplete) UI by default.
Attachment #8356806 - Attachment is obsolete: true
Blocks: 961285
Depends on: 962212
Depends on: 962214
Depends on: 962217
Comment on attachment 8358579 [details] [diff] [review]
WIP

I moved this patch to bug 962212, and filed some additional bugs for remaining work (see this bug's dependency list).
Attachment #8358579 - Attachment is obsolete: true
Depends on: 962260

Updated

4 years ago
No longer depends on: 957165

Comment 28

4 years ago
moving [story] bugs over to tracking product.
Component: Components → Metro Operations
OS: Windows 8 Metro → Windows 8.1
Product: Firefox for Metro → Tracking
Version: Trunk → ---

Updated

4 years ago
Priority: -- → P1

Updated

4 years ago
Priority: P1 → --

Updated

4 years ago
Priority: -- → P1
(Reporter)

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.