Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The "Content Blocking" setting is not reset to the previous one after the end of the study #8

Open
SoftVision-CarmenFat opened this issue Feb 27, 2019 · 4 comments

Comments

@SoftVision-CarmenFat
Copy link

[Affected versions]:

  • Firefox 66.0b11

[Affected Platforms]:

  • All Windows
  • All Mac
  • All Linux

[Prerequisites]

[Steps to reproduce]:

  1. Open Firefox browser with the profile from prerequisites.
  2. Set the system date and time 365 days in the future (e.g. 2020 March).
  3. Restart the browser.
  4. Navigate to "about:preferences#privacy" page.
  5. Observe the Content blocking setting.

[Expected result]:

  • The "Standard" setting is selected.

[Actual result]:

  • The "Custom" setting remains selected.

[Notes]:

  • All the 3 prefs remain with the values that the add-on changed:
    -> network.cookie.cookieBehavior to 4
    -> urlclassifier.trackingAnnotationTable to test-track-simple,base-track-digest256,content-track-digest256
    -> browser.contentblocking.category to custom
  • This is also reproducible with the "Control" branch.
  • Here is a screen recording of the issue:

setting exp

ericawright referenced this issue in 0c0w3/enhanced-tracking-protection-study Mar 7, 2019
@ericawright
Copy link
Contributor

When you move the time forward by one year, you are now testing the shield study utils, and that it unenrolls correctly, it does not. However, we are planning on having Normandy do the actual unenrolling/uninstalling of the addon.
I have tested this with the Normandy tools, and it uninstalls and cleans up correctly. As a precaution, to prevent a race condition, we are going to add in an extra unenrollListener. This listener can also only be tested with the normandy dev tools.

@SoftVision-CarmenFat
Copy link
Author

Thanks @ericawright ! We will wait for the build with the unenrollListener so we can perform another round of testing. Also we will try this out using the Normandy stage server.

@ericawright
Copy link
Contributor

The signed xpi is posted here: https://bugzilla.mozilla.org/show_bug.cgi?id=1522309
it has the changes with the new unenroll listener as well as is compatible with firefox version 67+

@SoftVision-CosminMuntean

I have retested this issue using the latest add-on (cookie-restrictions-strict-list-study@shield.mozilla.org-1.4-signed-testing.xpi) version using Normandy stage server tools with the following methods:

  1. Created a opt-out recipe with the latest add-on. After the recipe was executed on the targeted profile, I have removed the study from the "about:studies" page.
  2. Created a opt-out recipe with the latest add-on. After the recipe was executed on the targeted profile, I have disabled the recipe from Delivery Console and restarted the browser.
  3. Created a opt-out recipe that expires after a set time. After the recipe was executed on the targeted profile, I have verified if the add-on is uninstalled and the prefs are reset after the recipe automatically expired.

After testing each mentioned method the add-on was uninstalled and the prefs were correctly reset to the default ones.

However, it seems that the "study_state": "user-disable" ping is sent after the recipe is disabled from the Delivery Console or the recipe automatically expires after a set time. Is this the right behavior, or the "study_state": "expired" ping should be sent instead.

@erica Please let us know if you have any methods using Normandy in mind so we can verify this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants