Closed Bug 1259299 Opened 4 years ago Closed 4 years ago

waterfall-breakdown is not displayed after recordings are cleared and recording performance again


(DevTools :: Performance Tools (Profiler/Timeline), defect, P1)



(firefox47 unaffected, firefox48 fixed)

Firefox 48
Tracking Status
firefox47 --- unaffected
firefox48 --- fixed


(Reporter:, Assigned: gregtatum)



(2 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160323030400

Steps to reproduce:

1. Start Nightly
2. Go to any sites (e.g. about:home)
3. Open Devtools > Performance
4. Start recording performance, and stop recording when something markers appear (waterfall-breakdown is displayed)
5. Click the Clear button
6. Start recording performance, and stop recording when something markers appear
(waterfall-breakdown is not displayed)

Actual results:

waterfall-breakdown is not displayed even if marker is in recording.

Regression range:

Expected results:

waterfall-breakdown should display if marker is in recording.
Has Regression Range: --- → yes
Has STR: --- → yes
Component: Untriaged → Developer Tools: Performance Tools (Profiler/Timeline)
Flags: needinfo?(vporof)
OS: Unspecified → All
Hardware: Unspecified → All
I am a waiting reply.
Flags: needinfo?(jsantell)
Flags: needinfo?(vporof)
This definitely looks strange -- thanks for the report and regression range! Pinging Greg on this, he's the point person on performance tools
Flags: needinfo?(jsantell) → needinfo?(gtatum)
Thanks magicp, I'll check this out.
Assignee: nobody → gtatum
Flags: needinfo?(gtatum)
Priority: -- → P1
The issue is that the markers are being cached in a weakmap, and that cache is set
any time the WaterfallView.render() method is being called. This can cause incomplete
lists of markers to be cached. This bug can also happen during a resize of the panel
during a recording. I added a check to see if the recording is actively recording.
Attachment #8741087 - Flags: review?(vporof)
Victor, jsantell suggested I hit you up on this for review. He said:

> 14:51 <jsantell> i think it has something to do with this patch
> 14:51 <jsantell> i think your patch may fix the issue but could break an assumption somewhere else
> 14:51 <jsantell> maybe victor would be a better reviewer :\
Attachment #8741087 - Flags: review?(vporof) → review+
Updating the reviewer on the patch.
Attachment #8741087 - Attachment is obsolete: true
Keywords: checkin-needed
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
I have reproduced this bug with Nightly 48.0a1 (2016-03-23) on Windows 7, 64 Bit!

The Bug's fix is verified on Latest Beta 48.0b9.

Build ID 	20160718142219
User Agent 	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
QA Whiteboard: [testday-20160722]
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.