[Webkit-unassigned] [Bug 30028] Web Inspector: Multiple calls to SetFrontendProxyObject can leave an InspectorTimelineAgent with a bad InspectorFrontend

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Oct 3 10:28:42 PDT 2009


https://bugs.webkit.org/show_bug.cgi?id=30028





--- Comment #2 from Pavel Feldman <pfeldman at chromium.org>  2009-10-03 10:28:41 PDT ---
(From update of attachment 40549)
> -    if (timelineEnabled.type() == Setting::BooleanType && timelineEnabled.booleanValue())
> +    if (m_timelineAgent.get() || (timelineEnabled.type() == Setting::BooleanType && timelineEnabled.booleanValue()))

Given that you initialize m_timelineAgent in the setFrontendProxyObject, it
will only collect the data while inspector is
opened (has been opened for the page at least once in case of WebKit). Is it so
by design?

I am asking because Inspector uses a bit different models for existing types of
inspected objects:
1) It tracks resources iff tracking is enabled, regardless of the frontend
state. It then dumps all the data collected
into the frontend upon its availability. When user enables this tracking for
the first time, page reload takes place in
order to gather the data.
2) There are explicit "start/stop profiling" buttons that start/stop collecting
data and dump results into the profiler page.
We are currently extending profiling tab so that it could gather different
types of profiles.

I think you should choose one of the models above to look consistent within
WebKit. If you think some users can have
timeline agent turned on constantly (it produces minimal overhead, there are
times when user would like to see what
has been happening without reloading the page), you should go (1). Otherwise,
if you consider your agent to be of a
profiling nature, you should choose (2). (2) implies that timeline agent
results are presented as a profile result on the
profiles page.

We can chat about it and discuss the ways you will push the gathered
information further into your framework. I'll
be happy to help you out with the WebKit frontend piece as well.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list