It doesn't make sense to show these in the timeline, at least for inspector^1. They only really show up when debugging, they generate a lot of profile data, and are sort of irrelevant for the purpose of profiling user content.
I can think of some uses for seeing injected scripts in the timeline for inspector^2 and above. But, I'm not quite sure how to distinguish that from inside the engine (look at the PageGroup or something?)
Good point. We do hide the InjectedScript from backtraces in the Debugger. We should be able to do it for the profiler too.
It would make sense to show it for Inspector^2. That would be via the PageGroup identifier.
(In reply to comment #2)
> Good point. We do hide the InjectedScript from backtraces in the Debugger. We should be able to do it for the profiler too.
> It would make sense to show it for Inspector^2. That would be via the PageGroup identifier.
The profiler can distinguish different page group ids, but I don't think the inspector "level" is exposed anywhere outside of UIProcess. What's a good way to expose that? WebInspectorClient?
My WIP patch has a ProfileGenerator::setSuspended flag that is set and unset under the InspectorController will/didCallInjectedScript.
Created attachment 238621 [details]
Comment on attachment 238621 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=238621&action=review
Makes sense to me.
> - InspectorInstrumentationCookie cookie = InspectorInstrumentation::willCallFunction(scriptExecutionContext, scriptName, scriptLine);
Yeah I never understood why this was instrumented.
Created attachment 238895 [details]
Attachment 238895 [details] did not pass style-queue:
Total errors found: 1 in 7 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 238895 [details]
Clearing flags on attachment: 238895
Committed r174095: <http://trac.webkit.org/changeset/174095>
All reviewed patches have been landed. Closing bug.