Investigate why an earlier first-paint notification results in Talos regressions

NEW
Unassigned

Status

()

Core
Layout
P1
normal
a year ago
3 months ago

People

(Reporter: jet, Unassigned)

Tracking

({stale-bug})

Trunk
All
Unspecified
stale-bug
Points:
---

Firefox Tracking Flags

(firefox50 affected)

Details

(Whiteboard: [perf])

(Reporter)

Description

a year ago
The fix for bug 1283302 results in Gecko firing the before-first-paint notification earlier than before. The before-first-paint notification initializes the APZC painting code. By design, APZC will paint an area beyond the viewport bounds, which may account for some of the startup hit here. 

However, Firefox would incur this startup cost anyway (after 250ms today) so it seems wrong for Talos to be testing page performance without the first-paint step. 

Filing this bug to track that down.
(Reporter)

Updated

a year ago
Blocks: 1283302
Hardware: Unspecified → All
Whiteboard: [perf]
added more alerts to this, we see this in Android as well, overall, I suspect whatever fixes we do for desktop will have the same effect on Android.
(Reporter)

Updated

a year ago
Priority: -- → P1
Comment hidden (obsolete)
Is it still P1?
You need to log in before you can comment on or make changes to this bug.