Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

shield changes in PT are propagating to regular tabs #15191

Closed
kjozwiak opened this issue Sep 12, 2018 · 4 comments
Closed

shield changes in PT are propagating to regular tabs #15191

kjozwiak opened this issue Sep 12, 2018 · 4 comments

Comments

@kjozwiak
Copy link
Member

kjozwiak commented Sep 12, 2018

Description

Shield settings that are being changed under PT are also affecting the shields of regular tabs which shouldn't be happening. The behaviour should be as follows:

  • shield changes in a regular tab will propagate into PT and other tab types
  • shield changes in PT should never propagate into regular tabs and other tab types

Test plan / Steps to Reproduce

  1. install & launch 0.23.205 81396b3
  2. open https://jsfiddle.net/bkf50r8v/13/ in a regular tab
  3. open https://jsfiddle.net/bkf50r8v/13/ in a PT tab
  4. within the PT tab, change FP to Allow all fingerprinting
  5. go back into the regular tab and refresh

Actual result:
Fingerprinting isn't working for the regular tab but is still enabled via the shields and Block 3rd Party is still enabled/selected.

ptshieldsissue

Expected result:

Changing shields via PT shouldn't be affecting none PT tabs.

Reproduces how often:
100% reproducible using the above STR.

Brave Version

about:brave info:

Brave: 0.23.205 
V8: 6.9.427.22 
rev: 81396b3a6454480382ffc476a8b8590fec73717e 
Muon: 8.1.4 
OS Release: 17.7.0 
Update Channel: Release 
OS Architecture: x64 
OS Platform: macOS 
Node.js: 7.9.0 
Brave Sync: v1.4.2 
libchromiumcontent: 69.0.3497.92

Reproducible on current live release:

No, not reproducible using 0.23.107 which is the current live release.

Additional Information

Reproduced by @srirambv and @LaurenWags on both Win 10 x64 & macOS x64.

@bsclifton
Copy link
Member

Issue confirmed... must be a Muon issue as there haven't been any changes to browser-laptop (other than the swipe fixes by @darkdh)
https://github.com/brave/browser-laptop/compare/0.23.x...0.23.x-c69?expand=1

@bsclifton bsclifton self-assigned this Sep 12, 2018
@bsclifton
Copy link
Member

There might be a bug in the C69 branch regarding session
https://github.com/brave/muon/pull/642/files

Basically in browser-laptop, userPref is being updated for the private tab. The code then gets the session object via partition and sets a userPref using ses.userPrefs.setDictionaryPref. It appears that this change is bleeding through to the other session/partition (the non-private tab)

bsclifton added a commit to brave/muon that referenced this issue Sep 13, 2018
With https://chromium.googlesource.com/chromium/src/+/f623bafe9c5b8cbd1d63c4d7c9b69de172552df5, the values were changed from an exclusion (ex: which values to NOT put in `OverlayUserPrefStore`) to an inclusion (ex: which values to PERSIST, even in an incognito profile)

Fixes brave/browser-laptop#15191
@bsclifton
Copy link
Member

bsclifton commented Sep 14, 2018

Fixed with brave/muon@a712524 in Muon and 5bfa436 in browser-laptop

@GeetaSarvadnya
Copy link
Collaborator

GeetaSarvadnya commented Sep 14, 2018

Verified on Windows 10 x64

  • 0.23.206 80a5ac1
  • Muon 8.1.5
  • libchromiumcontent 69.0.3497.92

Verified with macOS 10.12.6 using

  • 0.23.206 80a5ac1
  • Muon 8.1.5
  • libchromiumcontent 69.0.3497.92

Verified on Ubuntu 17.10 x64

  • 0.23.206 80a5ac1
  • Muon 8.1.5
  • libchromiumcontent 69.0.3497.92

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.