New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 646928 link

Starred by 4 users
Status: Archived
Owner:
alph@chromium.org
Closed: Dec 4
Cc:
█ owe...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature



Sign in to add a comment

Make it easier to debug timers in devtools

Reported by bmau...@fb.com, Sep 14 2016 
In devtools it is often difficult to understand how timeouts work in a large codebase. Consider this timer:

1) the backtrae of when the timer was installed only has a single function. Especially if your codebase has a wrapper around set timeout (which facebook does), this makes it hard to understand who installed the timeout
2) You don't know when the timer was installed. Often you want to navigate to that point in time to understand the context around it
3) You don't know the duration of the timer. This is useful for understanding what the timer is / how it is intended to be used.
4) You don't know the delay on the timer firing. Often it's useful to understand the queueing time of the timer. IE if the timer should have fired at 1000 ms but fired at 1100 ms because the main thread was busy that may impact the UX.
Screen Shot 2016-09-14 at 10.50.05 AM.png
76.5 KB View Download

Comment 1 by chenwilliam@chromium.org, Sep 14 2016

Labels: -Type-Bug OS-All Type-Feature
Owner: alph@chromium.org
Status: Assigned (was: Untriaged)

Comment 2 by bmau...@fb.com, Feb 16 2017

Cc: owe...@chromium.org
@Owen -- can you help us get traction on this? We're pushing people to do a lot more debugging of interaction performance and I frequently see people get tripped up by timers. We wrap all of our setTimeout calls in layers of abstraction so the point to where the timer is added is often not super helpful.
Project Member

Comment 3 by bugdroid1@chromium.org, Feb 17 2017 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9ebc141b455c199fdb81b59bbb361b438ba2ed8d

commit 9ebc141b455c199fdb81b59bbb361b438ba2ed8d
Author: alph <alph@chromium.org>
Date: Fri Feb 17 16:34:01 2017

DevTools: Show pending duration for TimerFired events

BUG= 646928 

Review-Url: https://codereview.chromium.org/2692273009
Cr-Commit-Position: refs/heads/master@{#451317}

[modify] https://crrev.com/9ebc141b455c199fdb81b59bbb361b438ba2ed8d/third_party/WebKit/Source/devtools/front_end/timeline/TimelineUIUtils.js

Comment 4 by alph@chromium.org, Feb 17 2017 

Ben, feel free to ping me directly if you need something timeline/performance related.

Comment 5 by bmau...@fb.com, Feb 18 2017 

@alph -- Just tested this out in canary. The pending for is super useful. I find that on Facebook (which has pretty complex stack traces) The reveal button is pretty hard to use -- you have to zoom in really far for it to be helpful at all and even then i often find there are multiple events and I have to match up the IDs. Workable, but takes some effort to use

Comment 6 by alph@chromium.org, Feb 23 2017 

Yeah, I also noticed that. I have some ideas how to fix that. Stay tuned.
Project Member

Comment 8 by bugdroid1@chromium.org, Mar 31 2017 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1459bd0dc4107bcde17077387bd5705097d51c44

commit 1459bd0dc4107bcde17077387bd5705097d51c44
Author: alph <alph@chromium.org>
Date: Fri Mar 31 03:35:31 2017

DevTools: Show top level event initiator when a child is selected.

BUG= 646928 

Review-Url: https://codereview.chromium.org/2779253003
Cr-Commit-Position: refs/heads/master@{#461015}

[modify] https://crrev.com/1459bd0dc4107bcde17077387bd5705097d51c44/third_party/WebKit/Source/devtools/front_end/timeline/TimelineFlameChartDataProvider.js

Comment 10 by pfeldman@chromium.org, Dec 4

Status: Archived (was: Assigned)
Archiving feature requests that we are unlikely to address during the next 18 months.
►

Sign in to add a comment