WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
163407
Web Inspector: Call RuntimeAgent.disableControlFlowProfiler when Code Coverage Profiler is turned off
https://bugs.webkit.org/show_bug.cgi?id=163407
Summary
Web Inspector: Call RuntimeAgent.disableControlFlowProfiler when Code Coverag...
Nikita Vasilyev
Reported
2016-10-13 15:16:53 PDT
Disabling Code Coverage profiler by clicking [C] button should signal the backend to stop collecting the data by calling RuntimeAgent.disableControlFlowProfiler method. RuntimeAgent.disableControlFlowProfiler is currently unused.
Attachments
Patch
(1.59 KB, patch)
2016-11-10 11:28 PST
,
Nikita Vasilyev
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2016-10-13 15:17:09 PDT
<
rdar://problem/28764230
>
Nikita Vasilyev
Comment 2
2016-11-10 11:28:02 PST
Created
attachment 294390
[details]
Patch
Joseph Pecoraro
Comment 3
2016-11-10 11:30:56 PST
Comment on
attachment 294390
[details]
Patch It is unfortunate that we don't have any tests for these methods. Given the Type Profiler chance is probably going to be identical, is there any reason this is split into two bugs?
Nikita Vasilyev
Comment 4
2016-11-10 11:39:55 PST
> Given the Type Profiler chance is probably going to be identical, is there > any reason this is split into two bugs?
Yes, I have concerns about Type Profiler
https://bugs.webkit.org/show_bug.cgi?id=163408#c2
Nikita Vasilyev
Comment 5
2016-11-10 11:53:54 PST
(In reply to
comment #3
)
> Comment on
attachment 294390
[details]
> Patch > > It is unfortunate that we don't have any tests for these methods.
Should we test if RuntimeAgent.enableControlFlowProfiler() and RuntimeAgent.disableControlFlowProfiler() gets called on clicking the [C] icon? I haven't written any UI tests that use view wrappers, but I expect it to be feasible.
Joseph Pecoraro
Comment 6
2016-11-10 11:56:24 PST
(In reply to
comment #5
)
> (In reply to
comment #3
) > > Comment on
attachment 294390
[details]
> > Patch > > > > It is unfortunate that we don't have any tests for these methods. > > Should we test if RuntimeAgent.enableControlFlowProfiler() and > RuntimeAgent.disableControlFlowProfiler() gets called on clicking the [C] > icon?
We have no UI tests right now. I mean we don't even have tests for these protocol methods to ensure the backend does what we expect.
WebKit Commit Bot
Comment 7
2016-11-10 13:34:06 PST
Comment on
attachment 294390
[details]
Patch Clearing flags on attachment: 294390 Committed
r208561
: <
http://trac.webkit.org/changeset/208561
>
WebKit Commit Bot
Comment 8
2016-11-10 13:34:10 PST
All reviewed patches have been landed. Closing bug.
Saam Barati
Comment 9
2016-11-10 13:48:16 PST
(In reply to
comment #0
)
> Disabling Code Coverage profiler by clicking [C] button should signal the > backend to stop collecting the data by calling > RuntimeAgent.disableControlFlowProfiler method. > > RuntimeAgent.disableControlFlowProfiler is currently unused.
The downside of doing this is that if you ever want to toggle the button, you will loose information. What I did with the type profiler is ensure that the button was just a local toggle for the UI, not the actual JSC type profiler. That way, if a user wants to show and then hide and then show the UI, the user wouldn't loose type information. What's the motivation for not following this design here? (Note that I still think we should turn the profilers off when recording a timeline)
Nikita Vasilyev
Comment 10
2016-11-10 13:55:35 PST
(In reply to
comment #9
)
> (In reply to
comment #0
) > > Disabling Code Coverage profiler by clicking [C] button should signal the > > backend to stop collecting the data by calling > > RuntimeAgent.disableControlFlowProfiler method. > > > > RuntimeAgent.disableControlFlowProfiler is currently unused. > > The downside of doing this is that if you ever want to toggle the button, > you will loose information. What I did with the type profiler is ensure that > the button was just a local toggle for the UI, not the actual JSC type > profiler. That way, if a user wants to show and then hide and then show the > UI, the user wouldn't loose type information. > > What's the motivation for not following this design here? > > (Note that I still think we should turn the profilers off when recording a > timeline)
Here's a use case: 1. Turn Code Coverage off and on. 2. Perform some action on a web page. 3. See what got executed. Previously, we wouldn't be able to tell if the code was executed before performing that action or not. Now, turning off and on allows us to start with a clean slate.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug