1487240 - Include "block cookies from unvisited websites" and "block all cookies" UI in content blocking UI to avoid user confusion

Status: RESOLVED DUPLICATE of bug 1501985

(Firefox :: Settings UI, defect, P3)

Description

[Eiichi]

Attachment: screenshot.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180829191827

Steps to reproduce:

From Bug 1486181:

1. Selecting "All cookies (will cause website to break)" of "Cookies and Site Data" section in the privacy preferences.
2. See "Third-Party Cookies" part of the "Content Blocking" section.


Actual results:

"Third-Party Cookies" part of the "Content Blocking" section is unchecked and "All cookies are currently blocked" warning is shown.
This gives users that "All cookies are blocked" but why "Third-Party Cookies are NOT blocked.


Expected results:

If selecting "All cookies" of "Cookies and Site Data" section in the privacy preferences, "Third-Party Cookies" and "All third-party cookies (may cause website to break)" parts of the "Content Blocking" section shoud be checked.

Comment 1

[Tanvi Vyas[:tanvi]]

We have to investigate here and figure out what we want to do, if anything, to alleviate this confusion.

The problem I think is being reported is this:

User selects to block "All cookies (will cause website to break)" of "Cookies and Site Data" section in the privacy preferences.
Then they go to the Control Center UI and see "Third-Party Cookies    Add Blocking...".  It doesn't make sense to offer them an option to block third party cookies when all cookies are already blocked.

This is an edge case.  We can consider during 64 and prioritize accordingly.

Comment 2

[(no longer active)]

FWIW I think the choice of excluding "block cookies from unvisited websites" and "block all cookies" from content blocking is one we should revisit for 64.  That will take care of a lot of UX inconsistencies including this one.

Comment 3

[:Gijs (he/him)]

(In reply to :Ehsan Akhgari from comment #2)
> FWIW I think the choice of excluding "block cookies from unvisited websites"
> and "block all cookies" from content blocking is one we should revisit for
> 64.  That will take care of a lot of UX inconsistencies including this one.

This seems fine, but that's not something we can do for 63, and AIUI we're shipping the current state in 63.

(In reply to Eiichi from comment #0)
> If selecting "All cookies" of "Cookies and Site Data" section in the privacy
> preferences, "Third-Party Cookies" and "All third-party cookies (may cause
> website to break)" parts of the "Content Blocking" section shoud be checked.

Would this make sense, and is this something we can do for 63? Alternatively, could we hide these sections completely from the 'content blocking' page if the user has "manually" turned off cookies entirely?

Comment 4

[(no longer active)]

(In reply to :Gijs (he/him) from comment #3)
> (In reply to :Ehsan Akhgari from comment #2)
> > FWIW I think the choice of excluding "block cookies from unvisited websites"
> > and "block all cookies" from content blocking is one we should revisit for
> > 64.  That will take care of a lot of UX inconsistencies including this one.
> 
> This seems fine, but that's not something we can do for 63, and AIUI we're
> shipping the current state in 63.

That is right, which is why I said "we should revisit for 64".  The current way the UI work is intentional, even if some of us disagree with the decisions made.  The decision maker is Tanvi, I believe.

> (In reply to Eiichi from comment #0)
> > If selecting "All cookies" of "Cookies and Site Data" section in the privacy
> > preferences, "Third-Party Cookies" and "All third-party cookies (may cause
> > website to break)" parts of the "Content Blocking" section shoud be checked.
> 
> Would this make sense, and is this something we can do for 63?

No, that is not even desirable, since the union of those two options does *not* equate disabling all cookies.  Furthermore, those two elements are radio buttons, which means they are used to represent choices which are mutually exclusive in the UI, as I'm sure you know!

> Alternatively, could we hide these sections completely from the 'content
> blocking' page if the user has "manually" turned off cookies entirely?

We disable them already, and show a message stating that the settings made in the Cookies and Site Data UI prevent further changes to the settings exposed here.  You can see this behavior in Nightly.  That is what we (including UX) have decided to ship for 63.

Is there a reason why you consider this behavior to be insufficient and hiding the UI instead of disabling it in the way we currently do to be a superior solution?

Comment 5

[Eiichi]

(In reply to :Ehsan Akhgari from comment #4)

> We disable them already, and show a message stating that the settings made
> in the Cookies and Site Data UI prevent further changes to the settings
> exposed here.  You can see this behavior in Nightly.  That is what we
> (including UX) have decided to ship for 63.

If I can start from the basic beginning;
- when I select "All cookies" of "Cookies and Site Data" section in the privacy preferences, aren't "Third-Party Cookies" blocked at all?
- to protect "Third-Party Cookies" should I change "Cookies and Site Data" setting?

Comment 6

[Eiichi]

For reference, I realized as an average user that:

- "All cookies" include "Third-Party Cookies"
   i.e.
　"All cookies (will cause website to break)" > "All third-party cookies (may cause website to break)" > "Trackers (recommended) "
- thus blocking "All cookies" will automatically block "Third-Party Cookies".
 
So I'm confused.

Comment 7

[(no longer active)]

(In reply to Eiichi from comment #5)
> (In reply to :Ehsan Akhgari from comment #4)
> 
> > We disable them already, and show a message stating that the settings made
> > in the Cookies and Site Data UI prevent further changes to the settings
> > exposed here.  You can see this behavior in Nightly.  That is what we
> > (including UX) have decided to ship for 63.
> 
> If I can start from the basic beginning;
> - when I select "All cookies" of "Cookies and Site Data" section in the
> privacy preferences, aren't "Third-Party Cookies" blocked at all?

Third-party cookies are a subset of all cookies, obviously.  So when you block all cookies, every single one of them, including the third-party ones will be blocked.  This does NOT mean that we should be activating UI elements which are *intended* to turn on third-party cookie blocking, since those elements have a more specialized meaning.

> - to protect "Third-Party Cookies" should I change "Cookies and Site Data"
> setting?

The cookie controls under Cookies and Site Data are considered *advanced* UI controls which should only be changed when the user is fully aware of the implications of such changes.  Users who would like more common options, such as blocking third-party cookies only can do so under Content Blocking, by clicking the checkbox next to Third-Party Cookies.

(In reply to Eiichi from comment #6)
> For reference, I realized as an average user that:
> 
> - "All cookies" include "Third-Party Cookies"
>    i.e.
> 　"All cookies (will cause website to break)" > "All third-party cookies (may
> cause website to break)" > "Trackers (recommended) "

That relationship does NOT hold.  Again, these are advanced controls, and the meanings behind these options can be confusing.

It is hard to draw a comparison in the way you have between these settings.  All I can say is that "All cookies" blocks more than either "Trackers" or "All third-party cookies" or "Cookies from unvisited websites".  Also, "All third-party cookies" blocks more than either "Trackers" or "Cookies from unvisited websites".  Whether "blocking more" is a good thing or a bad thing depends on the context, and the degree of blocking.  For example, for many users blocking all third-party cookies may be a relatively safe thing to do, but blocking all cookies almost definitely will break all of their browsing experience.

> - thus blocking "All cookies" will automatically block "Third-Party Cookies".

Sure, but again it doesn't mean that we should activate UI indicating Third-Party Cookies are blocked when All Cookies are being blocked.

If this doesn't convince you, we have to agree to disagree, I'm afraid.  :-)

Please note that here I am describing to you how the current UI is designed to work.  I *personally* find the current UI very confusing and disagree with the decisions made when designing it, so it's a bit hard for me to "defend" these decisions here.  But our time for Firefox 63 development has come to and end, and while we can debate this to no end, as I have mentioned repeatedly we aren't planning to change the design for 63.  Again, also, as I've mentioned repeatedly, I am hoping to talk to Tanvi and hopefully get her to agree with comment 2 for Firefox 64 and that would address all of your concerns here.  I'd appreciate if you paid some attention to me repeating this over and over here...

Comment 8

[Eiichi]

(In reply to :Ehsan Akhgari from comment #7)

Thanks a lot for your in-depth explanation.
I will follow this bug attentively.

Comment 9

[Eiichi]

Attachment: Gray Out Model

If I might offer you a word of advice, this is one of models.

Attaching "Gray Out Model".

Comment 10

[:Gijs (he/him)]

(In reply to :Ehsan Akhgari from comment #4)
> > Alternatively, could we hide these sections completely from the 'content
> > blocking' page if the user has "manually" turned off cookies entirely?
> 
> We disable them already, and show a message stating that the settings made
> in the Cookies and Site Data UI prevent further changes to the settings
> exposed here.  You can see this behavior in Nightly.  That is what we
> (including UX) have decided to ship for 63.
> 
> Is there a reason why you consider this behavior to be insufficient and
> hiding the UI instead of disabling it in the way we currently do to be a
> superior solution?

I think those reasons are in comment #0...

It seems right now you have:

[ ] Third-party cookies (greyed out)

  /!\ All cookies are blocked

    () greyed-out radio option
    () greyed-out radio option


It seems to me that having the first checkbox ticked (instead of unticked - but continue to have it greyed out), and the radio group hidden, would render clearer UI (third-party cookies are blocked, because all cookies are blocked, and it's not possible to change this except by going back to the cookie settings and picking something other than 'block all cookies').

In other words, fundamentally I disagree with:

(In reply to :Ehsan Akhgari from comment #7)
> Third-party cookies are a subset of all cookies, obviously.  So when you
> block all cookies, every single one of them, including the third-party ones
> will be blocked.  This does NOT mean that we should be activating UI
> elements which are *intended* to turn on third-party cookie blocking, since
> those elements have a more specialized meaning.

The "more specialized meaning" doesn't really make sense to me. Third-party cookies *are* blocked when all cookies are blocked. I guess you're saying that having the checkbox ticked and greyed out would imply that first-party-cookies aren't being blocked (while they *are* of course blocked, because 'block all cookies' is turned on), but that's why you have the warning underneath it, right? The tickbox unchecked with the warning IMO leaves more confusion than having the tickbox checked with the warning.

Anyway, it sounds like this should be P2 given the desire to fix in 64 but not 63...

Comment 11

[Eiichi]

For confirmation,
I originaly filed Bug 1486181, but that bug was marked as "fixed" though the original isuue still exsists.
Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1486181#c13 and https://bugzilla.mozilla.org/show_bug.cgi?id=1486181#c15.

This is why I persist in "Third-party cookies" checked.

Comment 12

[(no longer active)]

(In reply to :Gijs (he/him) from comment #10)
> I think those reasons are in comment #0...
> 
> It seems right now you have:
> 
> [ ] Third-party cookies (greyed out)
> 
>   /!\ All cookies are blocked

No, the warning reads:

  "Your settings in Cookies and Site Data are preventing changes to Third-Party Cookies settings."

>     () greyed-out radio option
>     () greyed-out radio option
> 
> 
> It seems to me that having the first checkbox ticked (instead of unticked -
> but continue to have it greyed out),

What is the "first checkbox"?  If you mean Third-Party Cookies, it _is_ ticked when we disable these controls.

> and the radio group hidden, would
> render clearer UI (third-party cookies are blocked, because all cookies are
> blocked, and it's not possible to change this except by going back to the
> cookie settings and picking something other than 'block all cookies').
> 
> In other words, fundamentally I disagree with:
> 
> (In reply to :Ehsan Akhgari from comment #7)
> > Third-party cookies are a subset of all cookies, obviously.  So when you
> > block all cookies, every single one of them, including the third-party ones
> > will be blocked.  This does NOT mean that we should be activating UI
> > elements which are *intended* to turn on third-party cookie blocking, since
> > those elements have a more specialized meaning.
> 
> The "more specialized meaning" doesn't really make sense to me. Third-party
> cookies *are* blocked when all cookies are blocked. I guess you're saying
> that having the checkbox ticked and greyed out would imply that
> first-party-cookies aren't being blocked (while they *are* of course
> blocked, because 'block all cookies' is turned on),

No, that is what happens on Nightly.  What I was saying was that we should not be activating the "All third-party cookies (may cause websites to break)" radio button and leave it enabled when the user has selected blocking all cookies (and for that matter, I don't think we should select it and disable it either, I think we should not touch the selection at the level of the radio buttons under "Third-Party Cookies", as Nightly behaves now.)

> but that's why you have
> the warning underneath it, right? The tickbox unchecked with the warning IMO
> leaves more confusion than having the tickbox checked with the warning.

Can you please test the behavior on Nightly?  I think you're criticizing a behavior that we don't have...

Also I'd appreciate if you can bring up the rest of your objections with Tanvi, I feel like I have nothing more to add here.   Sorry.

Comment 13

[(no longer active)]

(In reply to Eiichi from comment #11)
> For confirmation,
> I originaly filed Bug 1486181, but that bug was marked as "fixed" though the
> original isuue still exsists.

Yes, I know! (https://bugzilla.mozilla.org/show_bug.cgi?id=1486181#c5)

> Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1486181#c13 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=1486181#c15.
> 
> This is why I persist in "Third-party cookies" checked.

Yes, that UI now links to a disabled checkbox, which is one of the inconsistencies I mentioned in comment 2.

Comment 14

[:Gijs (he/him)]

(In reply to :Ehsan Akhgari from comment #12)
> (In reply to :Gijs (he/him) from comment #10)
> > I think those reasons are in comment #0...
> > 
> > It seems right now you have:
> > 
> > [ ] Third-party cookies (greyed out)
> > 
> >   /!\ All cookies are blocked
> 
> No, the warning reads:
> 
>   "Your settings in Cookies and Site Data are preventing changes to
> Third-Party Cookies settings."
> 
> >     () greyed-out radio option
> >     () greyed-out radio option
> > 
> > 
> > It seems to me that having the first checkbox ticked (instead of unticked -
> > but continue to have it greyed out),
> 
> What is the "first checkbox"?  If you mean Third-Party Cookies, it _is_
> ticked when we disable these controls.

OK, so both of these changed since the screenshot attached in comment #0, then? That wasn't obvious...

I think we can dupe this to whatever bug changed the behavior/labels here, or mark as WFM. I'll leave that for Johann.

Comment 15

[(no longer active)]

(In reply to :Gijs (he/him) from comment #14)
> (In reply to :Ehsan Akhgari from comment #12)
> > (In reply to :Gijs (he/him) from comment #10)
> > > I think those reasons are in comment #0...
> > > 
> > > It seems right now you have:
> > > 
> > > [ ] Third-party cookies (greyed out)
> > > 
> > >   /!\ All cookies are blocked
> > 
> > No, the warning reads:
> > 
> >   "Your settings in Cookies and Site Data are preventing changes to
> > Third-Party Cookies settings."
> > 
> > >     () greyed-out radio option
> > >     () greyed-out radio option
> > > 
> > > 
> > > It seems to me that having the first checkbox ticked (instead of unticked -
> > > but continue to have it greyed out),
> > 
> > What is the "first checkbox"?  If you mean Third-Party Cookies, it _is_
> > ticked when we disable these controls.
> 
> OK, so both of these changed since the screenshot attached in comment #0,
> then? That wasn't obvious...

Yeah, the strings were changed in bug 1480900, not quite sure about when the checkbox behavior changed (AFAIK it was always as I described above)...  I thought perhaps you had checked Nightly.

> I think we can dupe this to whatever bug changed the behavior/labels here,
> or mark as WFM. I'll leave that for Johann.

I think the core issue the reporter has been complaining about is still unaddressed and will be addressed with comment 2, but the discussion here has derailed things from that part a bit.  I'd be happy to file another bug specifically about that if you all want to close this one.

Comment 16

[:Gijs (he/him)]

I've updated the summary based on comment #15 / comment 2, but then I also think the priority can be lowered further (at least from a Preferences perspective).

I'll add that the duplication that'd cause with the existing preferences UI for cookies seems suboptimal, but perhaps that means we can remove that UI (and replace with a button/link that takes you to the content blocking UI or something?). I'll leave that for UX, but either way it doesn't seem nearly as bad as the screenshot from comment #0 looked to me. Apologies for the confusion.

Comment 17

[(no longer active)]

(In reply to :Gijs (he/him) from comment #16)
> I'll add that the duplication that'd cause with the existing preferences UI
> for cookies seems suboptimal, but perhaps that means we can remove that UI
> (and replace with a button/link that takes you to the content blocking UI or
> something?).

Yes, that matches what I have in my mind too (and I think similarly for Bryan Bell).

> I'll leave that for UX, but either way it doesn't seem nearly
> as bad as the screenshot from comment #0 looked to me. Apologies for the
> confusion.

NP, sorry I didn't realized the screenshot may have caused the confusions earlier, must have suspected it...

Comment 18

[Eiichi]

Attachment: Screen Shot of Nightly 64.0a1.png

I'm sorry the screenshot may have caused the confusions.
If you feel the 1st screenshot to be superfluous, please delete it.

For the purposes of accuracy I'm attaching the screenshot of the latest Nightly: 64.0a1 (2018-09-06).

Comment 19

[:Gijs (he/him)]

Comment on attachment 9005036 [details]
screenshot.png

No worries, I'm sure the screenshot was what you saw, so it made sense to post it. :-)

I've marked it obsolete now.

Comment 20

[Johann Hofmann [:johannh]]

Yes, unfortunately the cookie restrictions UI in about:preferences introduced some very annoying conflicts with the site data section (which we had just reimplemented...), to the point where I fully agree this is not a state that we can maintain in the long term.

Seeing that the "privacy-panel" project seems to be going on for a little longer now, Ehsan and I should discuss with the UX team how this UI can be fundamentally changed to avoid the duplication and confusion here.

We can probably just leave this at P3 for now.

Comment 21

[Johann Hofmann [:johannh]]

Duping forward to bug 1501985, where this problem will be resolved.