Closed
Bug 1511751
Opened 6 years ago
Closed 5 years ago
Cookies subview is confusing
Categories
(Firefox :: Protections UI, defect, P1)
Firefox
Protections UI
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.
Assignee | ||
Comment 1•5 years ago
|
||
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]
Reporter | ||
Comment 2•5 years ago
|
||
(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.
Comment 3•5 years ago
|
||
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...)
Comment 4•5 years ago
|
||
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!
Reporter | ||
Comment 5•5 years ago
|
||
How about we only say "Tracking Cookies Blocked" when we actually did so, and "No Tracking Cookies Detected" otherwise?
Comment 6•5 years ago
|
||
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)
Reporter | ||
Comment 7•5 years ago
|
||
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.
Comment 8•5 years ago
|
||
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.
Updated•5 years ago
|
Assignee | ||
Comment 9•5 years ago
|
||
Updated•5 years ago
|
Priority: -- → P1
Assignee | ||
Comment 10•5 years ago
|
||
Assignee | ||
Comment 11•5 years ago
|
||
This can happen when we annotate trackers with the strict list but block based on the basic list, and it is confusing users.
Assignee | ||
Updated•5 years ago
|
Assignee: nobody → jhofmann
Status: NEW → ASSIGNED
Comment 12•5 years ago
|
||
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
Assignee | ||
Updated•5 years ago
|
Whiteboard: [privacy65][triage] → [privacy65]
Comment 13•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0f146f383c82 https://hg.mozilla.org/mozilla-central/rev/142c41711e58 https://hg.mozilla.org/mozilla-central/rev/a4c37fbac068
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 65
Updated•5 years ago
|
Flags: qe-verify+
Updated•5 years ago
|
QA Contact: ciprian.georgiu
Comment 14•5 years ago
|
||
[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.
Comment 15•5 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•