Closed Bug 1511751 Opened 6 years ago Closed 5 years ago

Cookies subview is confusing

Categories

(Firefox :: Protections UI, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Firefox 65
Tracking Status
firefox-esr60 --- unaffected
firefox63 --- unaffected
firefox64 --- unaffected
firefox65 + verified
firefox66 --- verified

People

(Reporter: dao, Assigned: johannh)

References

Details

(Whiteboard: [privacy65])

Attachments

(3 files)

[Tracking Requested - why for this release]:

E.g. here on Bugzilla, the main view tells me "Tracking Cookies Blocked", and when I open the subview I only see "From This Site: https://bugzilla.mozilla.org", which I assume wasn't actually blocked. Or was it? If it wasn't, what other cookies were blocked as "Tracking Cookies Blocked" suggests? I really can't tell from the UI.
Not sure if tracking is appropriate but we should talk about it in our meetings.

FYI, "Tracking Cookies Blocked" refers to the global preference state and not whether that actually happened. I can understand that's slightly confusing at first, though. Maybe we should change the wording to "Blocking Tracking Cookies?"
Flags: needinfo?(bmikel)
Whiteboard: [privacy65][triage]
(In reply to Johann Hofmann [:johannh] from comment #1)
> Not sure if tracking is appropriate but we should talk about it in our
> meetings.
> 
> FYI, "Tracking Cookies Blocked" refers to the global preference state and
> not whether that actually happened.

That's very misleading especially with the past tense.

> I can understand that's slightly
> confusing at first, though. Maybe we should change the wording to "Blocking
> Tracking Cookies?"

That's slightly better... as in, it's ambiguous rather than straight on wrong. Generally the panel is about what's happening on the current site, so I'd say it's still misleading.
Note about "Blocked" vs "Blocking", this distinction is probably going to be completely lost in certain localizations.  For example, in an example Persian localization of this UI I think the same confusion would remain whether the localizers start from "Tracking Cookies Blocked" or "Blocking Tracking Cookies" because in both cases the localizer would need to translate the concept that tracking cookies are being blocked in the present (whether we're talking about the effect, aka the cookies being blocked or the process, aka the cookies being blocked) and the confusion is with the underlying concept, not with whether the effect or the process is being talked about.

(Not every language makes so much distinction between the effect and the process as much as English does...)
Thanks Dao for your report!
To reiterate the problem... The Control Center shows "Cookies" when cookies are present on the page.  On the right hand side, it shows the blocking level for that user (ex: Tracking Cookies Blocked".  When the user drills down into the subpanel, there may be no third party cookies present on the page and hence nothing blocked on the page.
(Example: go to https://www.mozilla.org/en-US/ and see the subpanel.  There is only one first party cookie.  So the Control Center says "Tracking Cookies Blocked" when there are no tracking cookies to block on the page).

There are some simple things we could do to try to alleviate this problem now.  Here is a proposal:

1) Add a "Tracking Cookies" section to the subpanel that will always be present.  When there are Tracking Cookies, list them there (we already do this).  When there are no Tracking Cookies, still list the category name with "None" underneath it.


2) Change the text in the Control Center as follows:
"Tracking Cookies Blocked" to "Block Tracking Cookies"
"Third-Party Cookies Blocked" to "Block Third-Party Cookies"

"All Cookies Blocked" could remain the same (since at least one cookie would have to be detected in order for us to show this section in the control center and since that one cookie would likely show as blocked), or it could be "Block All Cookies". (up to Betsy)

"Unvisited Site Cookies Blocked" could remain the same (since there is no subsection for it), or it could be "Block Unvisited Site Cookies". (up to Betsy)


Note, this doesn't alleviate the concern Ehsan has in Comment 3 about different locals.  For that, I can only offer my suggestion (1) above, without making substantial changes.

Betsy, please review and provide your thoughts.  Thanks!
How about we only say "Tracking Cookies Blocked" when we actually did so, and "No Tracking Cookies Detected" otherwise?
Resolution discussed with Bryan and Johann.

In subpanel, show all three labels. If there are none detected, Add string: None detected on this site.

For the case of https://www.mozilla.org/en-US/, it would read:

From This Site
https://www.mozilla.org

Tracking Cookies
None detected on this site

Third-Party Cookies
None detected on this site
Flags: needinfo?(bmikel)
In case this wasn't clear, in comment 5 I was referring to the main view which seems to be the primary source of the confusion – that wasn't clear to me when I filed the bug and underlines just how suboptimal this is.
Change these strings:
"Tracking Cookies Blocked" to "Blocking Tracking Cookies"
"Third-Party Cookies Blocked" to "Blocking Third-Party Cookies"
"All Cookies Blocked" to "Blocking All Cookies"
"Unvisited Site Cookies Blocked" to "Blocking Unvisited Site Cookies"


Also, add a pref to remove this label next to Cookies on the main panel.
Priority: -- → P1
This can happen when we annotate trackers with the strict list but block based on the
basic list, and it is confusing users.
Assignee: nobody → jhofmann
Status: NEW → ASSIGNED
Pushed by jhofmann@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0f146f383c82
Part 1 - Remove the "Blocked" labels of content blocking categories and put them behind a pref. r=ewright
https://hg.mozilla.org/integration/autoland/rev/142c41711e58
Part 2 - Always show all categories in the cookies subpanel and note if they are empty. r=ewright
https://hg.mozilla.org/integration/autoland/rev/a4c37fbac068
Part 3 - Put up a note when the trackers subpanel is shown but no trackers are present. r=ewright
Whiteboard: [privacy65][triage] → [privacy65]
Flags: qe-verify+
QA Contact: ciprian.georgiu
[testday-20181221] 

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
OS:  Windows 7 (64bit)
Status: Fixed & Verified 

Steps to reproduce: 
1) Visit this websites https://www.mozilla.org/en-US/ or https://bugzilla.mozilla.org
2) In subpanel, it show all three labels like Connections, Content blocking & Permissions
3) Click on Cookies below the Content Blocking label
4) You will find the Cookies and site data like below one: 

From This Site
https://bugzilla.mozilla.org

Tracking Cookies
None detected on this site

Third-Party Cookies
None detected on this site

From This Site
https://www.mozilla.org/en-US/

Tracking Cookies
None detected on this site

Third-Party Cookies
None detected on this site

I have Reproduced the bug & The bug has been fixed.
Hello, 
This issue is confirmed verified fixed on the latest Nightly and Beta Builds(65.0b6) and 66.0a1 (2018-12-26.
Verified on Windows 10x64 and macOS 10.12.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: