Status

()

Core
Layout
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: (dormant account), Assigned: froydnj)

Tracking

(Blocks: 1 bug)

unspecified
mozilla12
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Snappy:P1])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Bug 681535 added xul telemetry. Lets also add html reflow telemetry. This time do not report 0ms reflows. We need this to see how often we encounter pages that stall the browser in layout.
I'd appreciate it if you build on top of the patches in bug 709256!
(Assignee)

Comment 2

5 years ago
Is it worth doing something like what we did in bug 699051 by sending back URLs that take longer than $MAX_TIME in reflow?  (Possibly with MAX_TIME calculated based on some timing cleverness.)

Obviously there are significant privacy implications to doing that, but I'm not sure knowing "hey, 5% of pages stall the browser for longer than 5s" is going to help us that much, as we don't have STR from that data.  Willing to be corrected by the layout guys!
(Reporter)

Comment 3

5 years ago
(In reply to Nathan Froyd (:froydnj) from comment #2)
> Is it worth doing something like what we did in bug 699051 by sending back
> URLs that take longer than $MAX_TIME in reflow?  (Possibly with MAX_TIME
> calculated based on some timing cleverness.)

It would be cool, but sending back URL(or anything related to URL) is not going to fly
(Reporter)

Comment 4

5 years ago
Also good point about 5% of pages, can't skip 0ms reflows in this case.
(Assignee)

Comment 5

5 years ago
(In reply to Taras Glek (:taras) from comment #3)
> (In reply to Nathan Froyd (:froydnj) from comment #2)
> > Is it worth doing something like what we did in bug 699051 by sending back
> > URLs that take longer than $MAX_TIME in reflow?  (Possibly with MAX_TIME
> > calculated based on some timing cleverness.)
> 
> It would be cool, but sending back URL(or anything related to URL) is not
> going to fly

OK, then what can we do once these numbers are in hand?  Plot them for Talos (or similar measures) tests?  I'm not seeing how having just reflow ms in isolation is going to help us.
(Assignee)

Comment 6

5 years ago
Created attachment 587363 [details] [diff] [review]
HTML reflow telemetry

Simple enough, I guess.
Attachment #587363 - Flags: review?(bzbarsky)
(Assignee)

Comment 7

5 years ago
Created attachment 587365 [details] [diff] [review]
HTML reflow telemetry
Attachment #587363 - Attachment is obsolete: true
Attachment #587363 - Flags: review?(bzbarsky)
Attachment #587365 - Flags: review?(bzbarsky)
Comment on attachment 587365 [details] [diff] [review]
HTML reflow telemetry

r=me
Attachment #587365 - Flags: review?(bzbarsky) → review+
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
(Reporter)

Comment 9

5 years ago
Boris, how hard would it be to track reflow in background tabs?
In what sense?  The presshell knows whether it's in a background tab....
(Reporter)

Comment 11

5 years ago
(In reply to Boris Zbarsky (:bz) from comment #10)
> In what sense?  The presshell knows whether it's in a background tab....

that's what I wanted. I would like to know how much jank is caused by reflows in background tabs
The mIsActive member of presshell should be what you want, then.  Presumably just log reflows when !mIsActive to a separate histogram?
http://hg.mozilla.org/integration/mozilla-inbound/rev/103460516db6
Keywords: checkin-needed
Target Milestone: --- → mozilla12
https://hg.mozilla.org/mozilla-central/rev/103460516db6
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.