Closed Bug 1394720 Opened 5 years ago Closed 5 years ago

6.07% remote-nytimes (android-4-4-armv7-api15) regression on push 4da1c8e2fc43 (Thu Aug 24 2017)


(Firefox for Android Graveyard :: General, defect)

Not set


(firefox55 unaffected, firefox56 unaffected, firefox57 fixed)

Firefox 57
Tracking Status
firefox55 --- unaffected
firefox56 --- unaffected
firefox57 --- fixed


(Reporter: igoldan, Assigned: jwu)



(Keywords: perf, regression, Whiteboard: [FNC][SPT57.3][INT])


(1 file)

We have detected an autophone (Android) regression from push:

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


  6%  remote-nytimes summary android-4-4-armv7-api15 opt      2,030.26 -> 2,153.40

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 jobs in a pushlog format.

To learn more about the regressing test(s), please see:
Component: Untriaged → General
Product: Firefox → Firefox for Android
Julian, I see you are the owner of bug 1366672. Could you please take a look over this regression?
Flags: needinfo?(walkingice0204)
As far as I know, Autophone will take screenshot to compare. In current design we need to apply an ending animation(300ms) to progress bar. So the screen is still in changing although page-loading finished. I think this is not a real performance regression?
Is there any could pass to java code then Animate-progress-bar could aware of that it is under autophone test? If so, I could disable ending animation in autophone test.
as a note, autophone does not do any form of screenshots- this test loads the page from the controller machine (over the network) and records the time to mozafterpaint.
:walkingice, are you working on this?  I would like to make sure we address or accept performance regressions in a timely manner- reading this bug, I am not clear on what the next steps are or progress.
No I am not working on this. I asked Jing-wei to help me to verify which part makes the performance drop.
Flags: needinfo?(walkingice0204) → needinfo?(
We've found some room to improve the performance for the new progress bar. Unfortunately I'm not sure the refactoring does correctly solve this regression, which means the modification doesn't correctly target on the root cause of performance drop.

Let's land the patch and check the treeherder report to see if we need investigate more for improvement.
Flags: needinfo?(
Comment on attachment 8906921 [details]
Bug 1394720 - Refactor AnimatedProgressBar for performance tuning.
Attachment #8906921 - Flags: review?(walkingice0204) → review+
Pushed by
Refactor AnimatedProgressBar for performance tuning. r=walkingice
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
I am not seeing any change in the graphs, but I will admit this is noisy and it might need more data.
Hi :jmaher,

Does the graph you check something like the link?,1543790,1,3

Just make sure we are on the same page that the platform name is changed from `android-4-4-armv7-api15` to `android-4-4-armv7-api16`. And since the result swings between 2000 and 2200ms, I'm afraid there are several different factors causing this situation. :(
Flags: needinfo?(jmaher)
thanks for pointing out the api 16 change, I had overlooked the fact that the original graph for the regression had no data since Aug 29th.
Flags: needinfo?(jmaher)
Assignee: nobody →
Whiteboard: [FNC][SPT57.3][INT]
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.