1330109 - Turn Tracking Protection Blocklist selector into a radio group instead of a 2 element tree

Status: NEW

(Firefox :: Settings UI, defect, P5)

Description

[Mike Conley (:mconley) (:⚙️)]

From Slide 11 of https://bugzilla.mozilla.org/attachment.cgi?id=8819509

The two element tree is wayyyyyyy overkill for 2 elements. Unless we're planning on shipping more blocklists for TP (which I don't think we are for now), we should switch to a simpler radio group within the dialog.

Comment 1

[Matthew N. [:MattN]]

(In reply to Mike Conley (:mconley) - Backed up on review / needinfo's from comment #0)
> The two element tree is wayyyyyyy overkill for 2 elements. Unless we're
> planning on shipping more blocklists for TP (which I don't think we are for
> now), we should switch to a simpler radio group within the dialog.

We were planning to do this and we were also going to allow selecting more than one list which is why it's checkboxes instead of radio so we should double-check that before spending time on this.

Peter/François, do you know if there are any plans to add new visible TP lists?

Comment 2

[François Marier [:francois]]

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #1)
> Peter/François, do you know if there are any plans to add new visible TP
> lists?

No plans that I know of at the moment, but it keeps coming up, often in the context of parity with Focus. It has also come up in the context of letting Web Extensions add new lists.

I personally think it would be worth our UI reflecting how the lists are actually split. We no longer offer a "strict" list and a "basic" list that users have to choose between. Instead what we have now is:

- the base list, which contains the bulk of the trackers
- the "content" list which only contains trackers for which blocking means a big usability cost

Our UI is currently emulating the old lists by selecting "base+content" when you pick the "strict" list.

If we change the labels and make the checkboxes act like checkboxes (i.e. not mutually exclusive), then we can simplify the frontend logic, resolve the UI inconsistency and allow for future expansion of the lists (either shipped by us or by extensions).

Comment 3

[Peter Dolanjski [:pdol]]

Philipp, can you take a look at this and see what your thoughts are on updating the UI? 
There is a team of students that will likely be implementing the proposed preferences changes, so we may be able to include this change in their scope.

Comment 4

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

I think when this was introduced, the current UI was chosen because it was the easiest to implement.

The UI proposal in the linked PDF (with radio buttons) makes sense to me, given that
a) using checkboxes would mean that a user could select no list
b) with the current options, I think it is easier to explain two distinct options in plain language
c) the scenario where a user would _only_ want to enable the blocklist that deteriorates usability seems unlikely

That being said, I would rate the priority of changing this as fairly low, seeing how hidden away it is (and for a good reason).

Comment 5

[François Marier [:francois]]

(In reply to François Marier [:francois] from comment #2)
> No plans that I know of at the moment, but it keeps coming up, often in the
> context of parity with Focus.

The kind of UI discussed in comment 2 would be needed to account for the new lists to be introduced by bug 1335646.