1018369 - "Add to homescreen" should remember private mode setting for tab

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect)

Description

[Wesley Johnston (:wesj)]

We've been kicking around some "always start in private mode" ideas. One simple way to support this would be to allow creating homescreen launcher icons that would kick off a link in private browsing.

There are more than a few other entry points into Fennec (we could have a separate intent handler for this, or a pref to control it...), but this seemed like a simple first step to see what we could do and build some base infrastructure.

Comment 1

[Wesley Johnston (:wesj)]

Attachment: Patch v1

What do you think of doing this mfinkle/ian? I added a method to nsIBrowserDOMWindow to support this (I wish it just took a flags argument instead, but this seemed simpler). Again, I'll iterate that there are other entry points we likely would want to hit if we did this, but this seemed like a simple first step.

There's a build with it at:
http://people.mozilla.com/~wjohnston/private.apk

It feels a bit weird to put something "private" on your homescreen, but you can use it on about:privatebrowsing and have a nice link to start private browsing...

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

Yes, we need to consider whether putting a private shortcut on the homescreen is a real use case. Maybe we should disable "Add to Home Screen" for private tabs instead?

Re: the patch
1. Let's try to use isPrivate" or just "private" instead of "privateMode" where we can
2. Why can't we just use a WHERE flag for this? We have OPEN_NEWTAB already, why not OPEN_NEWPRIVATETAB ?

Comment 3

[Wesley Johnston (:wesj)]

(In reply to Mark Finkle (:mfinkle) from comment #2)
> 1. Let's try to use isPrivate" or just "private" instead of "privateMode" where we can
Yeah. "private" is a reserved keyword often enough. Feels better to avoid it.

> 2. Why can't we just use a WHERE flag for this? We have OPEN_NEWTAB already,
> why not OPEN_NEWPRIVATETAB ?

I started to move this way and decided it was overly complex. i.e. to cover the full spectrum of options here we'd need:

OPEN_DEFAULTWINDOW // Default, use the user's prefs to decide what to do
OPEN_CURRENTWINDOW // Open in whatever window/tab goes with aOpener?
OPEN_NEWWINDOW     // Open in a new window. On Fennec this is a new tab.
OPEN_NEW_PRIVATE_WINDOW // Open in a new private window. On Fennec this is a new private tab.
OPEN_NEWTAB // New tab.
OPEN_NEW_PRIVATE_TAB // New private tab
OPEN_SWITCHTAB // Switch to a private or non-private tab if it exists, otherwise its the same as new tab.
OPEN_PRIAVTE_SWITCHTAB // Switch to a private tab if it exists, otherwise make a new private tab
OPEN_NON_PRIAVTE_SWITCHTAB // Switch to a non-private tab if it exists, otherwise make a new tab
// Plus whatever other odd options I'm not thinking of...

This is dumb and complex because we're conflating orthogonal things. I'd rather make WHERE a bitmask, but I wanted to avoid large changes to every other implementer, plus likely extension bustage on desktop. A new method felt clean.

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Wesley Johnston (:wesj) from comment #3)

> > 2. Why can't we just use a WHERE flag for this? We have OPEN_NEWTAB already,
> > why not OPEN_NEWPRIVATETAB ?
> 
> I started to move this way and decided it was overly complex. i.e. to cover
> the full spectrum of options here we'd need:
> 
> OPEN_DEFAULTWINDOW // Default, use the user's prefs to decide what to do
> OPEN_CURRENTWINDOW // Open in whatever window/tab goes with aOpener?
> OPEN_NEWWINDOW     // Open in a new window. On Fennec this is a new tab.
> OPEN_NEW_PRIVATE_WINDOW // Open in a new private window. On Fennec this is a
> new private tab.
> OPEN_NEWTAB // New tab.
> OPEN_NEW_PRIVATE_TAB // New private tab
> OPEN_SWITCHTAB // Switch to a private or non-private tab if it exists,
> otherwise its the same as new tab.
> OPEN_PRIAVTE_SWITCHTAB // Switch to a private tab if it exists, otherwise
> make a new private tab
> OPEN_NON_PRIAVTE_SWITCHTAB // Switch to a non-private tab if it exists,
> otherwise make a new tab
> // Plus whatever other odd options I'm not thinking of...
> 
> This is dumb and complex because we're conflating orthogonal things. I'd
> rather make WHERE a bitmask, but I wanted to avoid large changes to every
> other implementer, plus likely extension bustage on desktop. A new method
> felt clean.

A new method that your patch stubs out everywhere else is not so clean. And it's basically a duplicate of openURI (not even a different return type). Why not lobby to make aContext be a bit flag (it only has values for 1 and 2 so far). It feels OK to OR aContext flags: OPEN_EXTERNAL | OPEN_PRIVATE

Comment 5

[Wesley Johnston (:wesj)]

I looked at that at one point. aContext describes itself as:

"the context in which the URI is being opened. This is used only when aWhere == OPEN_DEFAULTWINDOW."

but more importantly it tries to describe the context the request is coming from. This would be changing its meaning significantly to describe the context we want the link to open in (i.e. the same thing the WHERE parameter is trying to describe).

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

I see PRIVATE being more of a CONTEXT than a WHERE

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Wesley Johnston (:wesj) from comment #5)
> I looked at that at one point. aContext describes itself as:
> 
> "the context in which the URI is being opened. This is used only when aWhere
> == OPEN_DEFAULTWINDOW."

Don't we already violate that?

Comment 8

[Wesley Johnston (:wesj)]

(In reply to Mark Finkle (:mfinkle) from comment #7)
> (In reply to Wesley Johnston (:wesj) from comment #5)
> > I looked at that at one point. aContext describes itself as:
> > 
> > "the context in which the URI is being opened. This is used only when aWhere
> > == OPEN_DEFAULTWINDOW."
> 
> Don't we already violate that?

I have no idea. We can make aContext work here if you want. Or we could just throw an [options] aFlags parameter on the end of the method.

Ping UX? Any feedback here?

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 8431784 [details] [diff] [review]
Patch v1

Let's decide on the approach first. We might not want to allow private tabs to be added to the homescreen.

Comment 10

[Ian Barlow (:ibarlow)]

Hey Wes, sorry it took a while to respond. 

So just to step back for a minute, it sounds like what we're trying to do in this bug is give people the option to quickly launch into a private session with their browser, without going through the effort of opening Firefox in normal browsing first and creating a new private tab. 

I tried the build you posted, this doesn't really feel like the way I would present this to a user. Using the bookmarks menu to add a private tab to the home screen as a shortcut feels like... well, it feels like we're using infrastructure that was meant for something else to solve a problem it wasn't meant to solve. Bookmarking isn't really on a user's mind at all when they are in a context where they don't want their browsing information saved.

This feels like something that should exist more in the context of a user's flow in Private Browsing. Perhaps a way to create a shortcut from about:privatebrowsing? Perhaps an item in our new tab tray menu being built in bug 817716 that would add a shortcut? And maybe instead of it looking like a bookmark shortcut, maybe it should actually look like a private instance of Firefox, so like an all dark Firefox icon or something? 

--------------

I also wonder though, what other needs are we (or should we be) trying to fulfill here?

Are we just trying to create a shorter path to private browsing? Are we trying to support users who want to cover their browsing tracks 100% of the time? And if that's the case, what else would we need to do to fulfill that? A way to make Firefox always work in private browsing? A way to let users choose how external links get opened (private vs normal)?

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

Wes and I talked a bout this yesterday. I agree that this approach is not good as a way to get people to quickly enter a Private Browsing session from a shortcut. We need a different approach for that.

What this patch might be useful to do is fix a bug: When a user is looking at a site in a private tab and they "Add to Home Screen", a shortcut to the site is added to the Android homescreen. Later, when the user taps on that shortcut a tab is opened in Firefox... but the tab is a normal tab, not a private one.

Comment 12

[Ian Barlow (:ibarlow)]

(In reply to Mark Finkle (:mfinkle) from comment #11)

> What this patch might be useful to do is fix a bug: When a user is looking
> at a site in a private tab and they "Add to Home Screen", a shortcut to the
> site is added to the Android homescreen. Later, when the user taps on that
> shortcut a tab is opened in Firefox... but the tab is a normal tab, not a
> private one.

Yeah, that is a good point.

Comment 13

[Kevin Brosnan [Ex-Mozilla]]

Note we previously wontfixed this in bug 820481.

Comment 14

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.