Bug 162469 – Web Inspector: Immediately after enabling Code Coverage profiler all code should be grayed out

• Status: ASSIGNED
• Component: Web Inspector

[Nikita Vasilyev]

For the following code:

    function foo() {
        return 42;
    }
    foo();

Disabling Code Coverage profiler followed by enabling it should fade out everything.

Currently, there is no way to clear Code Coverage profiler "history" without reloading the page.

[Radar WebKit Bug Importer]

<rdar://problem/28436034>

[Nikita Vasilyev]

I expected this to work when I fixed bug 163407 "Web Inspector: Call RuntimeAgent.disableControlFlowProfiler when Code Coverage Profiler is turned off",
but there's something else going on that could be a backend bug.

After turning Code Coverage off and on, the front-end receives no basic blocks:

    this._script.target.RuntimeAgent.getBasicBlocks(sourceID, function(error, basicBlocks) {
        basicBlocks.length // 0
    }

Which is enough for the front-end to know that the whole script should be fade out.

However, when anything in that script gets executed, the front-end receives newly executed basic blocks AND
all the old ones (before the Code Coverage was disabled). It could be that the backend doesn't flush this data.

I'm investigating with Saam.

[Joseph Pecoraro]

> However, when anything in that script gets executed, the front-end receives
> newly executed basic blocks AND
> all the old ones (before the Code Coverage was disabled). It could be that
> the backend doesn't flush this data.

That sounds like what I would have expected. I don't think we had planned on code coverage disable clearing the data, so now that we want that behavior we would need to implement it.

[Saam Barati]

The behavior is actually more subtle than this. The data the Code Coverage Profiler gets does indeed get cleared, but it also uses data from another data structure, which doesn't get cleared. The other data it uses is from the FunctionHasExecutedCache. The reason we don't clear the data inside the FunctionHasExecutedCache is that it is used by the type profiler too. I think we can probably fix this by just teaching the FunctionHasExecutedCache that it has multiple consumers.

That said, weird things might happen once we claim to have no longer executed some program, but claim to execute a function inside it. I need to think about all the implications a bit more.