Closed Bug 1492576 Opened 2 years ago Closed 2 years ago

If no protection is enabled, don't offer the user the ability to disable protection or report a problem

Categories

(Firefox :: Protections UI, defect, P1)

63 Branch
defect

Tracking

()

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

People

(Reporter: tanvi, Assigned: johannh)

References

(Blocks 1 open bug)

Details

(Whiteboard: [privacy-panel-64][uplift])

Attachments

(1 file)

* User has FastBlock, Tracking Protection, and Third Party Cookies turned off in normal browsing mode.
* Go to cnn.com (or any page with trackers)
* Click the Control Center.

User is offered the "Disable Blocking for this site" and the "Report a problem" buttons.  But Firefox has not blocked anything.  The disable button will do nothing to fix the current page load.  The report will be bogus and unrelated to Content Blocking.

Hide these buttons in this case.

This needs to be uplifted to 63, or it will be the default case for most users.
Whiteboard: [privacy-panel-64][uplift]
Status: NEW → ASSIGNED
Comment on attachment 9010676 [details]
Bug 1492576 - If no protection is enabled, don't offer the user the ability to disable protection or report a problem. r=Ehsan

:Ehsan Akhgari has approved the revision.
Attachment #9010676 - Flags: review+
Pushed by jhofmann@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f139e12a965a
If no protection is enabled, don't offer the user the ability to disable protection or report a problem. r=Ehsan
https://hg.mozilla.org/mozilla-central/rev/f139e12a965a
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
Comment on attachment 9010676 [details]
Bug 1492576 - If no protection is enabled, don't offer the user the ability to disable protection or report a problem. r=Ehsan

Approval Request Comment
[Feature/Bug causing the regression]: Not really a regression, more an oversight
[User impact if declined]: Users can add content blocking exceptions and report breakage when no content was blocked, which isn't desired by UX
[Is this code covered by automated tests?]: Yes
[Has the fix been verified in Nightly?]: Not yet
[Needs manual test from QE? If yes, steps to reproduce]: Turn off all content blocking categories in about:preferences (but not content blocking itself). Go to a site with trackers. Open the control center. You should not see the "Disable Protection" button or the "Report Breakage" link.
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: No
[Why is the change risky/not risky?]: Updating a few lines of CSS to hide these items.
[String changes made/needed]: None
Attachment #9010676 - Flags: approval-mozilla-beta?
Comment on attachment 9010676 [details]
Bug 1492576 - If no protection is enabled, don't offer the user the ability to disable protection or report a problem. r=Ehsan

Minimal css patch ficing a P1 bug, uplift approved for 63 beta 9, thanks.
Attachment #9010676 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
I successfully reproduced the issue using Firefox Nightly 64.0a1 (2018-09-19) under Windows 10 (x64) using STR from Comment 0.

The issue is no longer reproducible on Firefox Beta 63.0b9 and latest Nightly 64.0a1 (2018-09-25). Tests were performed under Windows 10 (x64), Ubuntu 16.04 (x64) and macOS 10.13.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.