Disable Cookie Banner Handling and hide preferences UI in Fenix
Categories
(Firefox for Android :: Privacy, task, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox138 | --- | fixed |
People
(Reporter: emz, Assigned: rebecatudor273)
References
Details
(Whiteboard: [fxdroid][group2])
Attachments
(1 file)
Since the future of cookie banner handling is currently unclear we've decided to disable the feature in pre-release channels (it was never enabled in release).
I'm updating prefs for desktop in Bug 1940275.
GeckoView / Fenix will need an extra patch to both disable the prefs by default (set to 0) and remove the preferences UI.
From some search-foxing I can see https://searchfox.org/mozilla-central/rev/f53c09a22edc700ab1a9eaaf4da0f0dd9f11bff3/mobile/android/geckoview_example/src/main/java/org/mozilla/geckoview_example/GeckoViewActivity.java#759
and https://searchfox.org/mozilla-central/rev/f53c09a22edc700ab1a9eaaf4da0f0dd9f11bff3/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/ContentBlocking.java#385-392
|
Reporter | |
Updated•1 year ago
|
When implementing this, please also don't forget about bug 1865561 (see comment 2 in particular), so that we can actually re-enable the cookie banner blocker in about:config manually after the corresponding checkbox is removed from the settings screen in Firefox Beta/Nightly for Android.
|
||
Updated•1 year ago
|
|
Assignee | |
Updated•1 year ago
|
|
|
Assignee | |
Comment 2•1 year ago
|
||
May I ask you to take another look at this and reconsider the approach? What exactly are the expectations for this bug?
When I first discovered this particular bug a few months ago, I pointed out in comment 1 that because the cookie banner handling feature is controlled by Nimbus, users like me have no way to permanently enable, disable, or adjust the parameters of this feature, even on channels that give the user normal access to about:config on Android (such as beta), because any deviation from the default values is automatically reset on the next sync (which happens on every Firefox launch?), making the cookie banner handling feature effectively unusable in the long run.
This reminds me a lot of what happened with the new tab hover preview feature in desktop Firefox. It was gradually rolled out in version 129, became the default in 131, and then caused issues like bug 1914756, which seems to have been overlooked and had to be addressed separately in bug 1914781.
I would really like to avoid repeating the same mistakes as with the tab hover previews and having to file yet another bug report, which is why I raised this concern a few months ago and again today. Unfortunately, the proposed solution in the attached patch, in my view, is heading in the wrong direction. Since the automatic cookie banner handling feature appears to be in limbo, and I haven't seen any public signs suggesting that it will change in the near future, what is the point of keeping the related Nimbus recipe if no rollout is planned anytime soon? Wouldn't it make more sense to just remove the Nimbus recipe altogether and rely on static prefs instead (or whatever the Android equivalent is)? That way, users on supported channels (beta and earlier) could freely tweak the cookie banner settings to fit their needs.
|
||
Comment 5•1 year ago
|
||
| bugherder | ||
|
|
Assignee | |
Comment 6•1 year ago
|
||
(In reply to kanapa1 from comment #4)
May I ask you to take another look at this and reconsider the approach? What exactly are the expectations for this bug?
When I first discovered this particular bug a few months ago, I pointed out in comment 1 that because the cookie banner handling feature is controlled by Nimbus, users like me have no way to permanently enable, disable, or adjust the parameters of this feature, even on channels that give the user normal access to
about:configon Android (such as beta), because any deviation from the default values is automatically reset on the next sync (which happens on every Firefox launch?), making the cookie banner handling feature effectively unusable in the long run.This reminds me a lot of what happened with the new tab hover preview feature in desktop Firefox. It was gradually rolled out in version 129, became the default in 131, and then caused issues like bug 1914756, which seems to have been overlooked and had to be addressed separately in bug 1914781.
I would really like to avoid repeating the same mistakes as with the tab hover previews and having to file yet another bug report, which is why I raised this concern a few months ago and again today. Unfortunately, the proposed solution in the attached patch, in my view, is heading in the wrong direction. Since the automatic cookie banner handling feature appears to be in limbo, and I haven't seen any public signs suggesting that it will change in the near future, what is the point of keeping the related Nimbus recipe if no rollout is planned anytime soon? Wouldn't it make more sense to just remove the Nimbus recipe altogether and rely on static prefs instead (or whatever the Android equivalent is)? That way, users on supported channels (beta and earlier) could freely tweak the cookie banner settings to fit their needs.
Hi! So this ticket was created to just make the feature unavailable for users. Not to remove it completely from code. So now by default the feature is disabled/hidden.
The UI parts that user could could use to control the preferences for private mode are hidden as well (example: the switch button from settings).
Even if the feature is disabled by default, yes, you can still enable it through about:config for a session, but these configurations values resets when you launch again the app. As a note even if you enable it from there, the UI will not be displayed too. (The same behavior like the Desktop app)
As for the bugs you mentioned even if i am not familiar with the desktop situation from the tickets i can tell in bug 1914756 was a rollout experiment issue as mentioned in one of the comments(didn't require changes in code). And for bug 1914781 the nimbus code was removed because the feature was not gonna be controlled through it anymore as it became a default feature, which is a different situation for now for this ticket.
Maybe i didn't get to answer your worry? Let me know.
Description
•