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

After upgrade `Block cross-site trackers` should be disabled when ads & trackers are allowed in 0.67.125 #5753

Closed
GeetaSarvadnya opened this issue Aug 21, 2019 · 2 comments

Comments

@GeetaSarvadnya
Copy link
Collaborator

@GeetaSarvadnya GeetaSarvadnya commented Aug 21, 2019

Description

When I upgrade 0.67.125 to 0.68.131 without changing any global shield settings, the global shield settings for Block cross-site trackers is enabled, when global shield settings for Ads control is changed to Allow ads & trackers in 0.67.125 after upgrade Block cross-site trackers is still enabled, this should be disabled as blocking of ads and trackers is allowed in 0.67.125.

After upgrade to 0.68.131, If I disable the Block cross-site trackers setting, there won't be any changes in the opened sites, ads and trackers are still allowed for all the sites. If I enable it again, then ads and trackers are blocked. Looks like UI (Visual) bug, functionality is working as expected.

Steps to Reproduce

  1. Clean profile 0.67.125
  2. Open a few sites
  3. Change the global shield settings for Ads control to Allow ads & trackers
  4. Make sure global shield settings are retained for all the opened sites
  5. Upgrade to 0.68.131
  6. Make sure site shield settings are retained (same as in step4)
  7. Go to global shield settings and verify Block cross-site trackers state
  8. Block cross-site trackers is enabled instead of disabling

Actual result:

After upgrade Block cross-site trackers is enabled when ads and trackers are allowed in 0.67.125

Expected result:

After upgrade Block cross-site trackers should be disabled when ads & trackers are allowed in 0.67.125

Reproduces how often:

Always

Brave version (brave://version info)

Brave 0.68.131 Chromium: 76.0.3809.100 (Official Build) (64-bit)
Revision ed9d447d30203dc5069e540f05079e493fc1c132-refs/branch-heads/3809@{#990}
OS Windows 10 OS Version 1803 (Build 17134.523)

Version/Channel Information:

  • Can you reproduce this issue with the current release? No
  • Can you reproduce this issue with the beta channel? Yes
  • Can you reproduce this issue with the dev channel? Yes
  • Can you reproduce this issue with the nightly channel? Yes

Other Additional Information:

  • Does the issue resolve itself when disabling Brave Shields? NA
  • Does the issue resolve itself when disabling Brave Rewards? NA
  • Is the issue reproducible on the latest version of Chrome? NA

Miscellaneous Information:

@brave/legacy_qa @karenkliu @cezaraugusto

@GeetaSarvadnya GeetaSarvadnya added this to Untriaged / Incoming in Shields via automation Aug 21, 2019
@rebron rebron removed this from Untriaged / Incoming in Shields Aug 23, 2019
@rebron rebron added the priority/P2 label Aug 23, 2019
@cezaraugusto cezaraugusto self-assigned this Aug 23, 2019
@cezaraugusto
Copy link
Contributor

@cezaraugusto cezaraugusto commented Aug 23, 2019

self-assigned and set as needs-investigation as I think this is not a regression based on latest changes in this codebase.

@cezaraugusto
Copy link
Contributor

@cezaraugusto cezaraugusto commented Jan 21, 2020

I did some investigation, and it doesn't seem to be an issue anymore in current channels, so I'm going to close this for now and set as wontfix. @GeetaSarvadnya please feel free to re-open this if you think I'm wrong, and I'll re-evaluate. Thanks!

@cezaraugusto cezaraugusto added wontfix and removed priority/P2 labels Jan 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.