Closed Bug 1990514 Opened 8 months ago Closed 2 months ago

Promote ScreenAvail and TouchPoints to bFPP in Nightly

Categories

(Core :: Privacy: Anti-Tracking, enhancement)

enhancement

Tracking

()

RESOLVED FIXED
150 Branch
Tracking Status
firefox150 --- fixed

People

(Reporter: tjr, Assigned: tjr)

References

Details

(Keywords: perf-alert)

Attachments

(5 files)

No description provided.
Assignee: nobody → tom
Status: NEW → ASSIGNED
Pushed by tritter@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/9f73a342f2d8 https://hg.mozilla.org/integration/autoland/rev/3ccdb8650ba8 Support Nightly ifdefs in RFPTargetDefaults.inc r=timhuang https://github.com/mozilla-firefox/firefox/commit/725277f04f51 https://hg.mozilla.org/integration/autoland/rev/e04bec3ed954 Promote Screen Available Resolution and Touch Points on Desktop to Baseline FPP in Nightly r=timhuang
Pushed by abutkovits@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/d497e85e6201 https://hg.mozilla.org/integration/autoland/rev/6a6ac97cbbab Revert "Bug 1990514: Promote Screen Available Resolution and Touch Points on Desktop to Baseline FPP in Nightly r=timhuang" for causing bustages at nsRFPService.cpp.
Attachment #9515359 - Attachment description: Bug 1990514: Promote Screen Available Resolution and Touch Points on Desktop to Baseline FPP in Nightly r?timhuang → Bug 1990514: Promote Screen Available Resolution and Touch Points to Baseline FPP in Nightly r?timhuang
Pushed by agoloman@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/5db892a2175c https://hg.mozilla.org/integration/autoland/rev/2dc39fb96bed Revert "Bug 1990514: Promote Screen Available Resolution and Touch Points to Baseline FPP in Nightly r=timhuang" for causing build bustages @nsRFPService.cpp.

Backed out for causing build bustages @nsRFPService.cpp.

Geez I cannot get this to stick. New combinations of builds that require a different annotation... hopefully https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=156158 passes.

Flags: needinfo?(tom)
Pushed by smolnar@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/463df717bd52 https://hg.mozilla.org/integration/autoland/rev/8cdab195dc40 Revert "Bug 1990514: Promote Screen Available Resolution and Touch Points to Baseline FPP in Nightly r=timhuang" for causing build bustages & window resize related failures
Flags: needinfo?(tom)
Keywords: leave-open

To try and document the status here:

We had two types of failures resulting from two places:

Devtools broke: browser_window_sizing.js - While I haven't dug into this too deeply, this is probably Bug 1900845 and how Devtools interacts with fingerprinting resistance stuff. This would already be a problem in PBM when Devtools is open, we just don't test that situation. What parts of Devtools get the real value? Obviously the console and JS Debugger need the same (spoofed) values the page would see. But maybe something like RDM needs the real value. Maybe we should be outputting a warning to DevTools to say "Hey, does this value look weird to you, it's because of FPP [sumo link]"

Webdriver broke: from_minimized_window.py - this is coming from the webdriver heuristics to detect if a window is maximized. I need to dig in and try to understand why that happens.

If you go into Responsive Design Mode, the available screen resolution
doesn't make a whole lot of sense to begin with, so we will not lie about
it there.

This is needed because there is a heuristic that detects if a window is maximized,
and the fingerprinting protections break that heuristic when we lie about the
user's available screen resolution.

Attachment #9534031 - Attachment description: Bug 1990514: Disable bFPP for a test r?jgraham → Bug 1990514: Disable bFPP for a few tests r?jgraham
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/57744 for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot

When I open a pdf in nightly, a lot of identical messages appear in the console.
It's probably not a big deal to not have the correct values for availWidth & availHeight, even if I'd really prefer having them: they help to figure out when a page is partially rendered in order to improve performance (see https://github.com/mozilla/pdf.js/blob/ae9fc13d8fbe58603331b766b5339b211c4faf85/src/display/display_utils.js#L752).
That said having hundred messages identical messages is very likely useless and in the specific pdf.js case, I think we must remove them.

So could we have the correct values when we're in the pdf viewer or at least remove the message ?

Flags: needinfo?(tom)
Regressions: 2016747

We will back this out because of the perf regression.

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/57783 for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot
Depends on: 1918257

@Calixte, do you think that the excessive messages in the console should be fixed before we land this nightly only? Or, might they be OK to fix in a followup issue?

Flags: needinfo?(cdenizet)

(In reply to Iulian Moraru from comment #26)

Backout merged to central: https://hg-edge.mozilla.org/mozilla-central/rev/2ebe84e6b107

Perfherder has detected a talos performance change from push 2ebe84e6b107da0f9558febd8f7935a02ba56a09.

No action is required from the author; this comment is provided for informational purposes only.

Improvement Test Platform Options Absolute values [old vs new]
44% pdfpaint issue14982.pdf (doc) linux1804-64-shippable-qr e10s fission stylo webrender-sw 1,380.18 ms -> 774.15 ms
9% pdfpaint issue16485.pdf (doc) linux1804-64-shippable-qr e10s fission stylo webrender-sw 411.11 ms -> 376.09 ms
8% pdfpaint issue16485.pdf (doc) linux1804-64-shippable-qr e10s fission stylo webrender 443.24 ms -> 409.22 ms

Need Help or Information?

If you have any questions, please reach out to fbilt@mozilla.com. Alternatively, you can find help on Slack by joining #perf-help, and on Matrix you can find help by joining #perftest.

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests.

Keywords: perf-alert

:lizzard, I think it's mainly painful for web developers in general (that being said, they can be hidden in removing the "info" messages in the console) but it shouldn't be one for normal users so it can be fixed in a follow-up for sure.
:tjr, when the devtools are closed, can it impact performances ?

Flags: needinfo?(cdenizet)

(In reply to Calixte Denizet (:calixte) from comment #30)

:lizzard, I think it's mainly painful for web developers in general (that being said, they can be hidden in removing the "info" messages in the console) but it shouldn't be one for normal users so it can be fixed in a follow-up for sure.
:tjr, when the devtools are closed, can it impact performances ?

I changed it to only warn once

Flags: needinfo?(tom)

https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=182929

I'm not sure how to test that the perf fix is still active and working - maybe just the lack of the warning message is sufficient.

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/58234 for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot

Removing the leave-open tag since we have now landed everything relevant to the feature.

Tom, is this now clear for the bug to be closed? I don't think anything further is blocking it, the WIP patch should be moved to bug 2016273.

Flags: needinfo?(tschuster)

Considering that all of tjr's patches landed, I would close this.

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Flags: needinfo?(tschuster)
Resolution: --- → FIXED
Target Milestone: --- → 150 Branch
Keywords: perf-alert
QA Whiteboard: [qa-triage-done-c151/b150]
Blocks: 2032123
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: