1485318 - Write tests that assert that content blocking is showing correctly with FastBlock and Cookie Restrictions

Status: RESOLVED DUPLICATE of bug 1487396

(Firefox :: Site Identity, enhancement, P2)

Description

[Johann Hofmann [:johannh]]

We currently always test the Content Blocking UI with Tracking Protection, because that's easiest to do. We should also test the same UI with FastBlock (which is also simple by setting the timeout pref to 0) and third party cookie restrictions.

Comment 1

[(no longer active)]

What kind of a test did you have in mind?  Just testing that setting the right prefs shows the right UI?  The fastblock and third-party cookies UI isn't really tied to the platform features besides just reflecting whether they're on/off.  Or did you mean to test that it reflects the state of the platform prefs correctly?

Comment 2

[Johann Hofmann [:johannh]]

I think it's enough to just replicate this test for all three variations (FB, TP, Cookies): https://searchfox.org/mozilla-central/source/browser/base/content/test/trackingUI/browser_trackingUI_state.js

This will assert that the content blocking UI is shown when the feature is active and that the pref state is reflected correctly.

Comment 3

[(no longer active)]

Attachment: Extend browser_trackingUI_state.js to cover all of the category items in the control centre

Comment 4

[Johann Hofmann [:johannh]]

Comment on attachment 9003293 [details] [diff] [review]
Extend browser_trackingUI_state.js to cover all of the category items in the control centre

Review of attachment 9003293 [details] [diff] [review]:
-----------------------------------------------------------------

Hm, I think this going in the right direction, but it is now checking the two other tracker types while TP is still active, which doesn't tell us whether those would show the Content Blocking UI on their own.

It would be much more helpful to test each individually, so we could do something like

browser_trackingUI_state_trackingprotection.js
browser_trackingUI_state_fastblock.js
browser_trackingUI_state_cookies.js

with the difference that they flip different prefs (and potentially visit different sites) to make the content blocking UI appear.

Most of it should just be copy-pasting the test. browser_trackingUI_state_fastblock.js and browser_trackingUI_state_cookies.js could potentially be simpler, since they don't need to test in private windows.

Do you think that makes sense?

(Yes, we probably also need to change the term "trackingUI" at some point).

Thanks!

Comment 5

[(no longer active)]

I think that makes sense.  I'm just not sure if you're asking this in addition to this change, or instead of.  I think it makes sense to do it in addition to, since that way we would be covering all of the possible combinations of the pref that can activate the UI elements and the events which may trigger them, what do you think?

Comment 6

[Johann Hofmann [:johannh]]

I don't think there are any downsides to checking the presence of the other blockers and their UI items, but I would only leave one enabled in each test, to be able to verify that it's really the blocker we're testing that is setting the UI state.

I agree that it would be interesting to also test combinations, e.g. FastBlock on and TP on, and if we find a smart way to do that it would be great, but I don't want to make this too complicated for you, either :)

Comment 7

[Johann Hofmann [:johannh]]

Would be nice to finish in the next release.

Comment 8

[(no longer active)]

I ended up writing some tests for this in bug 1487396.