Closed Bug 1998435 Opened 2 months ago Closed 2 months ago

The fingerprinting protection state cleaner shouldn't clear the global zoom

Categories

(Toolkit :: Data Sanitization, defect, P2)

defect

Tracking

()

RESOLVED FIXED
146 Branch
Tracking Status
firefox-esr115 --- unaffected
firefox-esr140 --- fixed
firefox144 --- wontfix
firefox145 --- wontfix
firefox146 --- fixed

People

(Reporter: pierov, Assigned: pierov)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

When clearing the fingerprinting state, the default zoom is also cleared: https://searchfox.org/firefox-main/rev/cb52781342cc905eda923d009fc0b678f3a8c8c6/toolkit/components/cleardata/ClearDataService.sys.mjs#458-468
While zoom can be used for linkability, we think that this is an accessibility setting that shouldn't be cleared in this way.

I agree, that seems unexpected.

Component: Privacy: Anti-Tracking → Data Sanitization
Product: Core → Toolkit

Set release status flags based on info from the regressing bug 1975753

:fkilic, since you are the author of the regressor, bug 1975753, could you take a look?

For more information, please visit BugBot documentation.

Flags: needinfo?(mozbugzilla)

Clearing the NI for Fatih, as we already reached the consensus to remove this.
I'll try to do it later today.

Assignee: nobody → pierov
Flags: needinfo?(mozbugzilla)

Setting as S2 due to accessibility severity

Severity: -- → S2
Priority: -- → P2
Pushed by abutkovits@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/21fb33016fbf https://hg.mozilla.org/integration/autoland/rev/41d7609a1566 Revert "Bug 1998435 - Do not reset the default zoom when clearing the FFP state. r=manuel" for causing failures at browser_bug1975753_site_specific_zoom_level.js.

Oh! It seems setGlobal is async, but it can take an optional callback parameter.
Let me add that to promisify the change of global zoom.

Flags: needinfo?(pierov)
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 146 Branch

The patch landed in nightly and beta is affected.
:pierov, is this bug important enough to require an uplift?

For more information, please visit BugBot documentation.

Flags: needinfo?(pierov)
Flags: needinfo?(pierov)
See Also: → 1999527
QA Whiteboard: [qa-triage-done-c147/b146]

Is this something we should uplift to ESR140?

Flags: needinfo?(pierov)
Flags: in-testsuite+

Yes please, let me create an uplift request.

Flags: needinfo?(pierov)

firefox-esr140 Uplift Approval Request

  • User impact if declined: This patch fixes another patch that was uplifted and contains code which might unexpectedly reset an accessibility option. It will be useful to Tor Browser.
  • Code covered by automated testing: yes
  • Fix verified in Nightly: yes
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing: -
  • Risk associated with taking this patch: low
  • Explanation of risk level: Unsupported configuration (RFP/FFP)
  • String changes made/needed: No
  • Is Android affected?: no
Attachment #9527638 - Flags: approval-mozilla-esr140?

does bug 1998730 have to be uplifted as well?

Flags: needinfo?(pierov)

No, it seems the Bug was created before the initial attempt was landed.
There's another bug to prevent potential TV failures (Bug 1999527), but as a matter of fact we've never hit those, so I don't think that needs to be uplifted either.

Flags: needinfo?(pierov)
Attachment #9527638 - Flags: approval-mozilla-esr140? → approval-mozilla-esr140+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: