Closed Bug 1487300 Opened Last year Closed Last year

Unchecking "All Detected Trackers" always makes "Only in private windows" selected

Categories

(Firefox :: Preferences, defect, P2)

defect

Tracking

()

VERIFIED FIXED
Firefox 64
Tracking Status
firefox63 --- verified
firefox64 --- verified

People

(Reporter: ehsan, Assigned: ehsan)

References

Details

(Whiteboard: [privacy-panel-64])

Attachments

(2 files)

STR:

1. Open about:preferences#privacy-trackingprotection.
2. Ensure All Detected Trackers is checked and under it, Always is checked.
3. Uncheck the checkbox.

Actual results: "Only in private windows" gets selected.

Expected results: the radio button selection shouldn't change.
Tanvi, how much do we care about this?  It's kinda edge casey, seems like I missed it while testing my patch...
Flags: needinfo?(tanvi)
Setting to P3 while Tanvi and Ehsan evaluate the importance of this.
Priority: -- → P3
Lets make it a P2, do it in 64 timeframe with potential to uplift.

Next week we are going to meet to figure out how to track these; in the meantime I'm creating a whiteboard flag "[privacy-panel-64]" for this.
Flags: needinfo?(tanvi)
Priority: P3 → P2
Whiteboard: [privacy-panel-64]
The problem here is that when we uncheck the checkbox, we set both the TP pref and the TP PBM pref to false, and we don't persist the state of the UI anywhere after this point.  From here on, when we restore the state of the radio group, we set its value to "never", but that value doesn't appear in any of the radio children so we fall back to the first radio child (Only in private windows).  And when the user clicks the checkbox again to turn All Detected Trackers back on, we now have the radiogroup still in the same state, hence the bug.

In order to fix this, we need a "backup preference" to write the state of the prefs before entering the "never" state, which we can use to restore the state of the radiogroup properly when needed.
Assignee: nobody → ehsan
I'm seeing an issue that might be related: the checkbox isn't visibly toggling.  The radio buttons are activated or not, as is the pref, but the checkbox doesn't show a check mark.
(In reply to Martin Thomson [:mt:] from comment #6)
> I'm seeing an issue that might be related: the checkbox isn't visibly
> toggling.  The radio buttons are activated or not, as is the pref, but the
> checkbox doesn't show a check mark.

What build is that?  That sounds bug 1488013 which is fixed in the latest Nightly.  (This UI is under heavy development, so you really want to be on the *latest* Nightly for testing.)
Ahh, that is it.  Thanks.  I always check before doing the long search and filing process, but it must have taken too long for the build to make it through.

FWIW, you now have two "Change block list" links, and the second is non-functional.  (64.0a1 (2018-09-04) (64-bit))
(In reply to Martin Thomson [:mt:] from comment #8)
> Ahh, that is it.  Thanks.  I always check before doing the long search and
> filing process, but it must have taken too long for the build to make it
> through.
> 
> FWIW, you now have two "Change block list" links, and the second is
> non-functional.  (64.0a1 (2018-09-04) (64-bit))

Bug 1488436 :)
Comment on attachment 9006409 [details]
Bug 1487300 - Restore the state of the tracking protection menu when All Detected Trackers is checked after being previously unchecked; r=johannh

Johann Hofmann [:johannh] has approved the revision.
Attachment #9006409 - Flags: review+
Pushed by eakhgari@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/fd88ac1e5391
Restore the state of the tracking protection menu when All Detected Trackers is checked after being previously unchecked; r=johannh
Comment on attachment 9006409 [details]
Bug 1487300 - Restore the state of the tracking protection menu when All Detected Trackers is checked after being previously unchecked; r=johannh

Approval Request Comment
[Feature/Bug causing the regression]: This isn't a regression, but an improvement to a new UI in 63.
[User impact if declined]: comment 0.
[Is this code covered by automated tests?]: Yes.
[Has the fix been verified in Nightly?]: Landed now.
[Needs manual test from QE? If yes, steps to reproduce]: No.
[List of other uplifts needed for the feature/fix]: None.
[Is the change risky?]: No.
[Why is the change risky/not risky?]: The code is rather trivial and disabled by default.
[String changes made/needed]: None.
Attachment #9006409 - Flags: approval-mozilla-beta?
https://hg.mozilla.org/mozilla-central/rev/fd88ac1e5391
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
Comment on attachment 9006409 [details]
Bug 1487300 - Restore the state of the tracking protection menu when All Detected Trackers is checked after being previously unchecked; r=johannh

Uplift approved for 63 beta 5
Attachment #9006409 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
I have verified this issue in the latest Nightly v64.0a1 (2018-09-10). 
Also, this issue does not appear as valid for the Beta version of the browser (v63.0b3 / v63.0b4) because the design of the changeable options from the tracking protection section does not allow for the issue to reproduce. 
Please see the attachment below. Am I missing anything?
Flags: needinfo?(ehsan)
(In reply to Bodea Daniel [:danibodea] from comment #16)
> I have verified this issue in the latest Nightly v64.0a1 (2018-09-10). 
> Also, this issue does not appear as valid for the Beta version of the
> browser (v63.0b3 / v63.0b4) because the design of the changeable options
> from the tracking protection section does not allow for the issue to
> reproduce. 
> Please see the attachment below. Am I missing anything?

You need to set the browser.contentblocking.ui.enabled pref to true in order to see the new version of the UI.
Flags: needinfo?(ehsan)
This issue is now verified in v63.0b5. 
Uplift successful.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.