Closed Bug 1240180 Opened 4 years ago Closed 4 years ago

2-8% a11y/tart/tp5o/tresize windows* regression on Inbound (v.46) on Jan 13, from push a9f9b36c1a2e


(Core :: Widget: Win32, defect)

Not set



Tracking Status
firefox46 --- unaffected
firefox47 --- fixed


(Reporter: jmaher, Assigned: jfkthame)



(Keywords: perf, regression, Whiteboard: [talos_regression])


(1 file)

Talos has detected a Firefox performance regression from your commit a9f9b36c1a2eec7626e6b749e46ab0a8bf3323e2 in bug 1239007.  We need you to address this regression.

This is a list of all known regressions and improvements related to your bug:

On the page above you can see Talos alert for each affected platform as well as a link to a graph showing the history of scores for this test. There is also a link to a treeherder page showing the Talos jobs in a pushlog format.

To learn more about the regressing test, please see:

Reproducing and debugging the regression:
If you would like to re-run this Talos test on a potential fix, use try with the following syntax:
try: -b o -p win32 -u none -t other,svgr,tp5o  # add "mozharness: --spsProfile" to generate profile data

To run the test locally and do a more in-depth investigation, first set up a local Talos environment:

Then run the following command from the directory where you set up Talos:
talos --develop -e <path>/firefox -a a11yr,tart,tp5o,tresize

Making a decision:
As the patch author we need your feedback to help us handle this regression.
*** Please let us know your plans by Tuesday, or the offending patch will be backed out! ***

Our wiki page outlines the common responses and expectations:
a11y regressions:

tart regressions:

tp5o (not scroll or bytes);

tresize (appears to be win7 only):

I did a lot of retriggers on the original push and the previous push to give me confidence in this assessment:

I would be happy to bisect on try (I have a script for that) and find which part is causing the problems, or maybe help try out some patches.

:jfkthame, can you take ownership of this and confirm you are working on this or this is an expected regression and we need to live with it because <fill in the blank> by Tuesday?
Flags: needinfo?(jfkthame)
Yes, I'll be looking into this ASAP.

If you can bisect this down to a specific one of the changesets that landed in bug 890156, that would be really great -- thanks!
Assignee: nobody → jfkthame
Flags: needinfo?(jfkthame) → needinfo?(jmaher)
a11y and tp5o made a big change here:

I don't see one for tart, maybe that was noise that i mistook for a regression.  I didn't run tresize, but I would be happy to add that in if you would like.  It is pretty easy to spot the difference in a11y and tp5o.
AFAICS this should fix the talos regressions here: for the common single-display case, the need to scale theme metrics for a secondary display will not arise so we can skip querying the displays and computing the scale factor. Try results, compared to pre-bug 890156:
Attachment #8708963 - Flags: review?(VYV03354)
thanks for getting a patch up so quickly!
Attachment #8708963 - Flags: review?(VYV03354) → review+
Bug 1240180 - Optimize native theme scaling for the single-monitor case. r=emk
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
looking at the graphs, I see a lot of improvements.  Regarding a11y, these are improved, but about 75%, same for tp5o.  tart/tresize looks to be 100% recovered.

Overall, I think this is a win.  Thanks for fixing this!
Blocks: 1240174
Backed out of aurora-46, see bug 890156 comment 168. Bumping target milestone to 47.
Target Milestone: mozilla46 → mozilla47
Blocks: 1244255
You need to log in before you can comment on or make changes to this bug.