1543775 - Waterfall view not able to drill down to actual application code

Status: RESOLVED INVALID

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

Description

[Minkul]

Attachment: This screenshot compares FF waterfall with Safari's and Chrome's.

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

• Go to http://todomvc.com/examples/knockoutjs/
• Create a todo entry
• Open Firefox DevTools
• Go to Performance tab
• Start recording performance
• Hover over your created todo.
• Delete icon will appear at the right
• Click the delete icon
• Stop recording performance
• In waterfall timeline choose the area where 'click' event happened

Actual results:

• FF DevTools waterfall can only show the JS library file in call stack. It cannot drill down to show actual application code which is removing the todo item.
• Both Safari and Chrome DevTools can show full call stack. (Screenshot attached).

Expected results:

• Just like other DevTools, Firefox DevTools should be able to show full call stack in waterfall timeline inspector.

Comment 1

[Julien Wajsberg [:julienw]]

Thanks for your report!

There can be several reasons to this. One possible reason in this case is that Firefox is too fast (compare 4ms in Firefox vs 10ms in Chrome) and therefore the stack isn't captured in our sampling profiler.
Another possibility is that I think Chrome's view combines the waterfall view with a call tree view. I don't know if we do that.
But anyway we should see the full stack in the "waterfall" panel and I don't see it either in your case, possibly for the same reason.

Do you think you can change the case by inserting a long loop in the event handler, to force that it takes a long time?

Also note we're not working actively in this tool at the moment, instead we work on a completely new improved profiler that you can enable in Devtools' settings, or install the addon at https://profiler.firefox.com.
Here is what I got when trying this case: https://perfht.ml/2ItkMpE
In this case we see the full stack as appropriate.
The underlying system is the same but because we capture more things in the new profiler, things are also slower, and this might be why we're able to capture the stack in the new profiler.
Note that the new profiler isn't ready for prime time yet (it's quite too complicated for "normal" web developers without Gecko knowledge), but you may want to try it if you're doing this kind of job often.

Hope this helps!

Comment 2

[Minkul]

(In reply to Julien Wajsberg [:julienw] from comment #1)

Thanks Julien for your nice explanation. Hopefully better profiler will land in stable Firefox channel soon. However, from my little experience, I found the timeline inspector of Safari is the best among three, in terms of ease of use, capability and presentation of data. It doesn't take any training to get the most out of Safari timeline.

As you mentioned, the work on new Firefox profiler is still ongoing; from a user's point of view I hope the team behind profiler will take some inspiration from Safari timeline inspector.

Thanks

Comment 3

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I believe that this report is related to the old DevTools Profiler.
The Performance panel in DevTools now points to the new Firefox profiler available at profiler.firefox.com
Closing as Invalid bug