Really good to trace these and when they are taking too long. Right now you just get a lone "Function Call" with no idea why we entered JS.

I think this is just a particular instance of bug 1050500.

No, I think this is good to have as a separate bug because it lets us know *why* we entered JS, while bug 1050500 only tells us *which* JS function we entered. It could be useful to differentiate from setTimeout or DOM events, for example.

(In reply to On vacation until May 17th from comment #2) > No, I think this is good to have as a separate bug because it lets us know > *why* we entered JS, while bug 1050500 only tells us *which* JS function we > entered. > > It could be useful to differentiate from setTimeout or DOM events, for > example. I didn't want to close this again without your say-so, but please take a look at the results from the first part of bug 1050500. Screenshot: https://bug1050500.bugzilla.mozilla.org/attachment.cgi?id=8594882 Patch: https://bugzilla.mozilla.org/attachment.cgi?id=8594763&action=diff It seems to me that the entry reason provided there is exactly what this bug is about.

We do currently have Function Call markers with "FrameRequestCallback" causes from rAF, FWIW. So I do think this is already completed

What do we not have currently in our rAF markers that this bug is referring to?

I think we can close this bug, there's been a bunch of changes and what I wanted is generally available now.