Promote ScreenAvail and TouchPoints to bFPP in Nightly
Categories
(Core :: Privacy: Anti-Tracking, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox150 | --- | fixed |
People
(Reporter: tjr, Assigned: tjr)
References
Details
(Keywords: perf-alert)
Attachments
(5 files)
| Assignee | ||
Comment 1•8 months ago
|
||
Updated•8 months ago
|
| Assignee | ||
Comment 2•8 months ago
|
||
Comment 5•8 months ago
|
||
Backed out for causing bustages at nsRFPService.cpp.
Backout link: https://hg-edge.mozilla.org/integration/autoland/rev/6a6ac97cbbab0ce76ad1a7b992dd411fee4def71
Failure log: https://treeherder.mozilla.org/logviewer?job_id=529248037&repo=autoland&task=Sw_MPWC2S7GL25YvYc8YeQ.0&lineNumber=14
Updated•8 months ago
|
Backed out for causing build bustages @nsRFPService.cpp.
| Assignee | ||
Comment 9•8 months ago
|
||
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.
Comment 10•8 months ago
|
||
Comment 11•8 months ago
|
||
Comment 12•8 months ago
|
||
Backed out for causing build bustages & window resize related failures
Backout link: https://hg.mozilla.org/integration/autoland/rev/8cdab195dc40910308bb65bbf13834a532460b03
| Assignee | ||
Updated•7 months ago
|
| Assignee | ||
Comment 13•7 months ago
|
||
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.
| Assignee | ||
Comment 14•5 months ago
|
||
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.
| Assignee | ||
Comment 15•5 months ago
|
||
| Assignee | ||
Comment 16•5 months ago
|
||
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.
Updated•4 months ago
|
Comment 17•3 months ago
|
||
Comment 19•3 months ago
|
||
| bugherder | ||
Comment 21•3 months ago
|
||
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 ?
Comment 22•3 months ago
|
||
We will back this out because of the perf regression.
Comment 23•3 months ago
|
||
Comment 24•3 months ago
|
||
backed out as requested: https://hg.mozilla.org/integration/autoland/rev/2ebe84e6b107da0f9558febd8f7935a02ba56a09
Comment 26•3 months ago
|
||
Backout merged to central: https://hg-edge.mozilla.org/mozilla-central/rev/2ebe84e6b107
Comment 28•3 months ago
|
||
@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?
Comment 29•3 months ago
|
||
(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.
Comment 30•3 months ago
|
||
: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 ?
| Assignee | ||
Comment 31•2 months ago
|
||
(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
| Assignee | ||
Comment 32•2 months ago
|
||
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.
Comment 33•2 months ago
|
||
Comment 35•2 months ago
|
||
| bugherder | ||
Comment 37•2 months ago
|
||
Removing the leave-open tag since we have now landed everything relevant to the feature.
Comment 38•2 months ago
|
||
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.
Comment 39•2 months ago
|
||
Considering that all of tjr's patches landed, I would close this.
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Description
•