1196099 - Disabling "Tracking Protection" in private mode disables the feature in regular window as well

Status: RESOLVED DUPLICATE of bug 1145503

(Firefox :: Private Browsing, defect)

Description

[Avi L]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150812163655

Steps to reproduce:

1. go to a website that has FF show the "Tracking Protection" icon (make sure it set to block content)
2. open that website in private mode, change the setting to display content
3. refresh the regular window


Actual results:

the content is not blocked anymore


Expected results:

the content should remained blocked since the change was done in private mode

Comment 1

[:Gijs (he/him)]

When you say "tracking protection", do you mean mixed content blocking? (AIUI, tracking protection isn't finished or enabled by default in 40, only in later versions (are you really running Nightly and is the user agent string incorrect?))


Can you give an example website to test with?

Comment 2

[Avi L]

it's regarding the "privacy.trackingprotection.enabled" config, if enabled and you visit linkedin.com (for example) in private mode, disable for linkedin only and then visit in regular window (even after closing FF), it's still disabled for linkedin

and I'm using the release branch (40.0.2), I read about the feature a while back and enabled it manually.
I think it was like that in earlier versions like 39.0

Comment 3

[:Gijs (he/him)]

OK, thanks for clarifying.

I'm not up-to-date with our TP stuff, hopefully tanvi can check if this still happens on Nightly and if/how/when we fix this.

Comment 4

[Tanvi Vyas[:tanvi]]

(In reply to :Gijs Kruitbosch from comment #3)
> OK, thanks for clarifying.
> 
> I'm not up-to-date with our TP stuff, hopefully tanvi can check if this
> still happens on Nightly and if/how/when we fix this.

I believe I tested this on Nightly yesterday and when you decide to disable in pb mode doesn't affect regular mode and vice versa.  needinfo'ing Francois instead as he probably knows and can probably also tell you if this behavior changed between Firefox 40 and 42.

Comment 5

[François Marier [:francois]]

Yes, that was fixed in 42.