New content blocking UI doesn't reflect EnableTrackingProtection policy
Categories
(Firefox :: Enterprise Policies, defect, P1)
Tracking
()
People
(Reporter: soeren.hentzschel, Assigned: ewright)
References
(Blocks 1 open bug)
Details
(Keywords: regression, Whiteboard: [anti-tracking][privacytriage])
Attachments
(1 file, 1 obsolete file)
47 bytes,
text/x-phabricator-request
|
lizzard
:
approval-mozilla-beta-
|
Details | Review |
STR:
- enable the EnableTrackingProtection policy
- open the privacy settings
Expected:
As in Firefox 64 the privacy settings should show that the tracking protection is always enabled. Firefox 65 has a new UI. It's expected that the "custom" settings are enabled where the "trackers" dropdown shows "in all windows".
Actual:
The "trackers" dropdown in the "custom" section shows "in all windows" in the new privacy settings but the "default" settings are selected, telling that tracking protection is enabled only in private windows which is wrong.
I didn't test if the policy works as expected and if it's only a visual bug. But even if it's only a visual bug it should be fixed of course. :)
Reporter | ||
Updated•6 years ago
|
Comment 1•6 years ago
|
||
Johann, is this something that you can look in to?
Updated•6 years ago
|
Comment 3•6 years ago
|
||
Johann, does this need to be uplifted to 66?
Updated•6 years ago
|
Comment 4•6 years ago
|
||
as per comment 3. johann, should we expect a patch for 66?
Comment 5•6 years ago
|
||
Please don't just assign people to bugs. Erica, can you take a look at this whenever you have time? Thanks!
Assignee | ||
Comment 6•6 years ago
|
||
Hi Soren, I tested this and it seems that it is strictly a visual bug. "standard" will detect the default value of the prefs, and since the EnableTrackingProtection policy changes the default the user is placed there. You are correct that when you click on "custom" you can see the correct policy, changing to "custom" does not change any of the prefs so you can use that to see what is actually applying.
We should however change the copy, or put the user in custom automatically for these cases. I'll start a conversation with UX about this.
Comment 7•6 years ago
|
||
This also seems like something that could easily be tested.
Comment 8•6 years ago
|
||
How's this going, Erica? Do you think we should expect anything for 66?
Assignee | ||
Comment 9•6 years ago
|
||
(In reply to Tim Spurway [:tspurway] from comment #8)
How's this going, Erica? Do you think we should expect anything for 66?
I talked with UX and the consensus was that the category should be matched with our pre-defined categories if it perfectly matches, otherwise, it should move into custom. We haven't talked about what disabled categories will look like.
I'll start working on this shortly. I'm not sure how long it will take yet.
Assignee | ||
Comment 10•6 years ago
|
||
Do not rely on default values when matching categories, enforce expected prefs.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 11•6 years ago
|
||
Enforce expected category prefs even if enterprise policy changes the defaults. Lock user in custom if one of the relevant policy prefs are locked.
Updated•6 years ago
|
Comment 12•6 years ago
|
||
Comment 13•6 years ago
|
||
bugherder |
Comment 14•6 years ago
|
||
Is this something we should uplift to 66 (noting that RC week is next week) or can it ride to release with 67?
Assignee | ||
Comment 15•6 years ago
|
||
Comment on attachment 9046489 [details]
Bug 1524862 - Enforce expected category prefs even if enterprise policy changes the defaults.
Beta/Release Uplift Approval Request
- Feature/Bug causing the regression: Bug 1501985
- User impact if declined: Users who have a custom policy set involving cookies or tracking protection will have misleading UI that may lead them to believe that their policy is not being correctly set.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): changes a superficial pref which affects the way the privacy preferences is displayed to the user. prevents misleading UI. These are strictly visual changes which better reflect how the setting are actually behaving.
- String changes made/needed: none
Assignee | ||
Comment 16•6 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #14)
Is this something we should uplift to 66 (noting that RC week is next week) or can it ride to release with 67?
sure, so long as it isn't too late.
Comment 17•6 years ago
|
||
I do feel it's a bit late for now. I might take it if we had some QA verification or if this were a bit earlier than the very last minute in the cycle. It looks like there are some string changes as well so this is probably best left to ride with 67.
Updated•6 years ago
|
Assignee | ||
Comment 18•6 years ago
|
||
(In reply to Liz Henry (:lizzard) (use needinfo) from comment #17)
I do feel it's a bit late for now. I might take it if we had some QA verification or if this were a bit earlier than the very last minute in the cycle. It looks like there are some string changes as well so this is probably best left to ride with 67.
Not a problem, thank you.
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Description
•