Open Bug 1616047 Opened 2 years ago Updated 1 year ago

20.09% tscrollx (linux64-shippable) regression on push 503f96afd632f6e506a7bd7d8dbdae73b72a9147 (Fri February 14 2020)


(Core :: Layout, defect, P5)




Tracking Status
firefox-esr68 --- unaffected
firefox73 --- unaffected
firefox74 --- unaffected
firefox75 --- wontfix
firefox76 --- fix-optional


(Reporter: Bebe, Unassigned)




(4 keywords)


(1 file)

Talos has detected a Firefox performance regression from push:

As author of one of the patches included in that push, we need your help to address this regression.


20% tscrollx linux64-shippable opt e10s stylo 0.54 -> 0.65

You can find links to graphs and comparison views for each of the above tests at:

On the page above you can see an 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(s), please see:

For information on reproducing and debugging the regression, either on try or locally, see:

*** Please let us know your plans within 3 business days, or the offending patch(es) will be backed out! ***

Our wiki page outlines the common responses and expectations:

Component: Performance → Layout
Flags: needinfo?(bugs)
Product: Testing → Core
Version: Version 3 → unspecified


== Change summary for alert #24966 (as of Mon, 17 Feb 2020 12:47:30 GMT) ==


12% tscrollx linux64-shippable opt e10s stylo 0.62 -> 0.54

For up to date results, see:

Investigating. Changes to perf numbers aren't surprised at all.
Bug 1506376 helps with responsiveness in certain cases, and thus may regress metrics which don't care about
responsiveness but only simple absolute numbers.

Flags: needinfo?(bugs)

ahaa, based on the test is totally artificial.
'layout.frame_rate': 0.
That is not a type of scrolling web pages could trigger, or anything, since it sets a pref to an unexpected value.
I'm Inclined to say WONTFIX for this.

Closed: 2 years ago
Resolution: --- → WONTFIX

...but I'm still considering if either the test should be changed, or if RefreshDriver should explicitly let one to bypass all the normal handling when
layout.frame_rate is 0.

== Change summary for alert #24965 (as of Mon, 17 Feb 2020 12:46:02 GMT) ==


8% tp5o_scroll linux64-shippable opt e10s stylo 1.15 -> 1.24
5% tp5o_scroll linux64-shippable opt e10s stylo 1.15 -> 1.21

For up to date results, see:

Resolution: WONTFIX → ---

== Change summary for alert #24973 (as of Tue, 18 Feb 2020 06:26:08 GMT) ==


4% raptor-tp6m-allrecipes-geckoview-cold loadtime android-hw-g5-7-0-arm7-api-16 pgo 6,486.75 -> 6,750.83
1% raptor-tp6m-allrecipes-geckoview-cold loadtime android-hw-g5-7-0-arm7-api-16 pgo 6,567.75 -> 6,646.38


2% raptor-motionmark-animometer-firefox linux64-shippable-qr opt 50.21 -> 51.24

For up to date results, see:

Olli, do you have any updates on this bug and your patch?

Flags: needinfo?(bugs)

Not really, other than it being quite expected when the test doesn't test anything realistic.

Deprioritizing based on comment 3 and comment 10.

Priority: P3 → P5

I don't think we're going to do anything here, given that the test isn't doing anything realistic.
(Doing some end-of-year needinfo clearance )

Flags: needinfo?(bugs)
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.