Closed Bug 774385 Opened 9 years ago Closed 9 years ago

disable social features during private browsing

Categories

(Firefox Graveyard :: SocialAPI, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 807217

People

(Reporter: mixedpuppy, Assigned: mixedpuppy)

References

Details

Attachments

(1 file)

Should we be disabling during private browsing?  We don't send data to the provider without user action, and the only place that happens is the recommend button.
disable/enable based on private browsing
Attachment #642668 - Flags: review?(gavin.sharp)
Attachment #642668 - Flags: review?(gavin.sharp) → feedback?(gavin.sharp)
Comment on attachment 642668 [details] [diff] [review]
private browsing patch

the global private-browsing notification is going away (bug 463027)
Attachment #642668 - Flags: feedback-
OS: Mac OS X → All
Hardware: x86 → All
Summary: disable during private browsing → disable social features during private browsing
I don't think we should disable in private-browsing mode. We could make sharing a two-step process if we really think users are going to be doing this on accident, but the other features of the SocialAPI do not share what a user is doing.

On the other hand, if a user is in private browsing, they may still want to view updates from their friends as well as chat with them.
Comment on attachment 642668 [details] [diff] [review]
private browsing patch

I agree with Jared - I don't think the "user might accidentally share something" scenario is one we really need to worry about. And if we do want to worry about it, that's best done with an isolated fix (e.g. disable just the share button).
Attachment #642668 - Flags: feedback?(gavin.sharp) → feedback-
Depends on: 782712
Whiteboard: [Fx17]
After talking with Jared, this sounds like too much of a technical hurdle for this late in the v1 game.  It is gonna be creepy to have my mom "looking over my shoulder" when I'm "private browsing" though.
Whiteboard: [Fx17]
MattN also pointed out that some people only log in to social networks in PB mode, so getting this right will be tricky.

A simpler fix may be hiding the sidebar by default in PB mode, but I'm not sure if anyone will have time available before Monday to get to this.
I think a user should be able to use Social in Private Browsing but that it should not be exposed to the normal browsing session. In other words, private social data is private and public social data is public.

How do we currently handle Private Browsing for authenticated sessions? For example, if I'm logged into GMail in normal mode vs private mode. I would expect the UX to be the same.
I think we can probably close this as the interaction with private browsing seems correct - no login state is carried when moving in or out of PB mode, but the feature remains available in either case.

Anyone disagree?
SocialAPI isn't working quite as expected when interacting with Private Browsing mode yet.

STR:
1. Go to http://www.facebook.com/about/messenger-for-firefox and click Turn On.
2. Log into Facebook.
3. Start Private Browsing mode.
4. Click on the Login button in the sidebar.

When entering Private Browsing, the user is logged out of the sidebar, but the sidebar stays open. This leads the user to think that he can log into another account that will only stay open while in PB. 

When the user clicks the Login button in PB, he is taken to facebook.com but his new login is not registered in the sidebar. 

Moreover, when exiting Private Browsing, the data for the  initial account is not reloaded in the sidebar (it is reloaded when performing the same steps, without step 4).

As long as using this feature in Private Browsing is not in scope, you could try to hide the sidebar or deactivate the Login button in it when entering PB mode.
Due to some last-minute concerns with the private browsing/social interaction, we're going to fix this in bug 807217.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 807217
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.