[webkit-dev] virtual destructor annotations in subclasses
Hi all,
This question came up in a code review where I annotated subclass's
destructor with 'override':
class SuperClass {
public:
virtual ~SuperClass() {}
};
class Subclass : public SuperClass {
public:
~Subclass() *override*;
};
The style guide recommends
annotating overriden methods with either 'override' or 'final'. At the same
time with a very few exceptions, the vast majority of the subclasses in
WebKit annotate their destructors with 'virtual' keyword. It might be
because some of the code predates c++11 and virtual was the default
choice back then. In any case it prevents the compiler from generating
errors when super destructor is accidentally not made virtual.
So my question is if there is a reason to exempt destructors from the above
rule and mark them virtual in subclasses or they should be annotated with
override/final similar to other virtual methods?
In the latter case we could update existing code once by automatically
generating fix with clang-tidy.
--
Thanks,
Yury
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit memory instrumentation
On Tue, Jul 24, 2012 at 12:47 AM, Maciej Stachowiak m...@apple.com wrote: On Jul 23, 2012, at 8:09 AM, Yury Semikhatsky yu...@chromium.org wrote: * First option we consider is to define a class with the same set of fields as the instrumented one, then have a compile time assert that size of the reference class equals to the size of the instrumented one. See https://bugs.webkit.org/attachment.cgi?id=153479action=review for more details. Pros: compile time error whenever size of an instrumented class changes with the appropriate modifications to the instrumentation function. Cons: it will require each committer to adjust the reference class and the instrumentation on any modification that affects size of the instrumented class. Changes that don't affect size of the class will go unnoticed. * What is the advantage of this approach compared to just using the sizeof operator on the relevant classes? Regards, Maciej Summing up sizeof type of each field and parent class and comparing it to sizeof the class would do the same thing except that we would need sometimes to manually handle alignment discrepancies on different platforms. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] WebKit memory instrumentation
*Hi WebKit, Almost all developers would like to know why the render process takes so much memory. We are trying to address this problem by providing an information on how much memory is consumed by some high-level WebKit parts(DOM, CSS, JavaScript etc) . Currently there is a real-time chart in Web Inspector that shows the render process memory broken down into several components: To achieve that we instrumented several classes in WebCorehttp://code.google.com/searchframe#search/q=reportMemoryUsage%20package:chromiumtype=csto report an estimation of their memory footprint. The main problem with that approach is that it can be easily broken by changes to the instrumented clasess. We need a way to guard from such changes that would automatically validate the instrumentation and make sure it matches current class structure. We see several ways of doing that. First option we consider is to define a class with the same set of fields as the instrumented one, then have a compile time assert that size of the reference class equals to the size of the instrumented one. See https://bugs.webkit.org/attachment.cgi?id=153479action=review for more details. Pros: compile time error whenever size of an instrumented class changes with the appropriate modifications to the instrumentation function. Cons: it will require each committer to adjust the reference class and the instrumentation on any modification that affects size of the instrumented class. Changes that don't affect size of the class will go unnoticed. The second option is to write a tool/script/llvm-plugin and use it on a build-bot to monitor the relevance of instrumentation and update it on when a new field is added to an already instrumented class. However, a question remains who and how often would do this. Pros: a committer may not need to update the instrumentation immediately. Cons: the instrumentation may be behind the actual memory usage. An addifitional effort required to create the tooling. We would like to know what you think about it and will greatly appreciate any ideas and suggestions. Regards, Yury, Alexei, Ilya * ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit memory instrumentation
On Mon, Jul 23, 2012 at 8:07 PM, Zoltan Horvath zol...@webkit.org wrote: Hi there, On Mon, 23 Jul 2012 17:09:19 +0200, Yury Semikhatsky yu...@chromium.org wrote: *Hi WebKit, Almost all developers would like to know why the render process takes so much memory. We are trying to address this problem by providing an information on how much memory is consumed by some high-level WebKit parts(DOM, CSS, JavaScript etc) . Currently there is a real-time chart in Web Inspector that shows the render process memory broken down into several components: To achieve that we instrumented several classes in WebCorehttp://code.google.**com/searchframe#search/q=** reportMemoryUsage%20package:**chromiumtype=cshttp://code.google.com/searchframe#search/q=reportMemoryUsage%20package:chromiumtype=cs to report an estimation of their memory footprint. The main problem with that approach is that it can be easily broken by changes to the instrumented clasess. We need a way to guard from such changes that would automatically validate the instrumentation and make sure it matches current class structure. The goals are cool! Have you talked about how much code would be introduced/changed by this approach? We need to add one method for each interesting class that would report its structure. So far we've instrumented about 20 classes and got a pretty good coverage (unknown part is ~10-40% depending on the site). We see several ways of doing that. First option we consider is to define a class with the same set of fields as the instrumented one, then have a compile time assert that size of the reference class equals to the size of the instrumented one. See https://bugs.webkit.org/**attachment.cgi?id=153479**action=reviewhttps://bugs.webkit.org/attachment.cgi?id=153479action=reviewfor more details. Pros: compile time error whenever size of an instrumented class changes with the appropriate modifications to the instrumentation function. Cons: it will require each committer to adjust the reference class and the instrumentation on any modification that affects size of the instrumented class. Changes that don't affect size of the class will go unnoticed. I think we can't demand this from the committers. Although it seems a trivial task to do the modification, it's too much effort to take care of these individually. Can't we just automatize it somehow (or support the modifications) with a clever script? We considered putting the code collecting memory data separately from the instrumented classes and generating it but given that we needed to access private fields we preferred current approach. The tool described as the second option could generate a possible fix for the instrumentation if there is an error. That code can be manually committed then. The second option is to write a tool/script/llvm-plugin and use it on a build-bot to monitor the relevance of instrumentation and update it on when a new field is added to an already instrumented class. However, a question remains who and how often would do this. Pros: a committer may not need to update the instrumentation immediately. Cons: the instrumentation may be behind the actual memory usage. An addifitional effort required to create the tooling. This sounds a bit better for me, I think the effort that we put on tooling will save time later. Since we can tell that when the change and its instrumentation were introduced, the delay shouldn't be a big trouble. We would like to know what you think about it and will greatly appreciate any ideas and suggestions. Done. :) Regards, Yury, Alexei, Ilya * Cheers, Zoltan __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo/webkit-devhttp://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit memory instrumentation
On Mon, Jul 23, 2012 at 11:21 PM, Ryosuke Niwa rn...@webkit.org wrote: This is somewhat tangential but once we've solved this problem, can we expose the data via testRunner or internals object so that we may use it in our performance tests? It'll be very valuable to be able to monitor changes in these metrics. At the moment the data are only accessible through the Web Inspector protocol but I don't see any issues with exposing it via internals object. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Single location for people wanting to learn to use dev tools WAS: Blog post draft: dealing with exceptions using Web Inspector
On Thu, Apr 14, 2011 at 1:06 AM, Ojan Vafai o...@chromium.org wrote: Do we have a single page to point people to for learning to use the inspector? We have Chromium DevTools documentations page which covers most of the inspector functionality. There is a link to it at the end of the blog post (http://code.google.com/chrome/devtools/). Unfortunately we don't have such documentation at webkit.org Would be nice if there were a page that just linked to all the blog posts. In fact there is one( http://code.google.com/chrome/devtools/docs/blog-posts.html) on the DevTools documentation site. it contains links to all Web Inspector blog posts. On Wed, Apr 13, 2011 at 2:02 AM, Yury Semikhatsky yu...@chromium.orgwrote: Including the draft content inline for those who don't have post permissions. Thanks, Yury Web Inspector: Understanding Stack Traceshttp://www.webkit.org/blog/?p=1544 Posted by *Yury Semikhatsky* on Wednesday, April 13th, 2011 at 1:44 am Finding errors in JavaScript code both during application development and when it’s already released is an important part of web development. We’ve recently added a mechanism for handling uncaught JavaScript exceptions and made some improvements in the tools that allow you to work with stack traces. Now it’s a good time to summarize the ways one can deal with exceptions and stack traces in WebKit. Tracking exceptions When something goes wrong, you open the Web Inspector console (Ctrl+Shift+J / Cmd+Option+J) and find a number of JavaScript error messages there. Each message has a link to the file name with the line number you can navigate to. However, there might be several execution paths that lead to the error and it’s not always obvious which one of them has happened. Since recently, once Web Inspector window is opened, exceptions in the console are accompanied with the complete JavaScript call stacks. You can expand these console messages to see the stack frames and navigate to the corresponding locations in the code: You may also want to pause JavaScript execution next time exception is thrown and inspect its call stack, scope variables and state of your app. A tri-state stop button at the bottom of the Scripts panel enables you to switch between different exception handling modes: you can choose to either pause on all exception or only on the uncaught ones or you can ignore exceptions altogether. Printing stack traces Printing log messages to the Web Inspector console is also very helpful in understanding how your application behaves. Now you can make the log entries even more informative by including associated stack traces. There are several ways of doing that. - You can instrument your code with console.trace() calls that would print current JavaScript call stacks: - There is also a way to place assertion in your JavaScript code. Just call console.assert() with the error condition as the first parameter. Whenever this expression evaluates to false you will see a corresponding console record: Handling exceptions at runtime using window.onerror Recently we’ve added support for setting a handler function to window.onerror. Whenever a JavaScript exception is thrown in the window context and is not caught by any try/catch block, the function will be invoked with the exception’s message, the URL of the file where the exception was thrown and the line number in that file passed as three arguments in that order. You may find it convenient to set an error handler that would collect information about uncaught exceptions and report it back to your server. Note that for more information on the recent features of the Web Inspector, you can visit the Chrome DevToolshttp://code.google.com/chrome/devtools/docs/overview.html documentation page. You can follow any responses to this entry through the RSS 2.0http://www.webkit.org/blog/?p=1544/feed/ feed. Both comments and pings are currently closed. Edit this entry.http://www.webkit.org/blog/wp-admin/post.php?action=editpost=1544 Comments are closed. On Wed, Apr 13, 2011 at 10:35 AM, Yury Semikhatsky yu...@chromium.orgwrote: Hello everyone, I've prepared a blog post draft( http://www.webkit.org/blog/?p=1544preview=true) that gives an overview of various ways of dealing with JavaScript stack traces and exceptions using Web Inspector. Your comments and suggestions are welcome. Thanks, Yury ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Single location for people wanting to learn to use dev tools WAS: Blog post draft: dealing with exceptions using Web Inspector
On Thu, Apr 14, 2011 at 1:28 AM, Oliver Hunt oli...@apple.com wrote: On Apr 13, 2011, at 2:06 PM, Ojan Vafai wrote: Do we have a single page to point people to for learning to use the inspector? Would be nice if there were a page that just linked to all the blog posts. On Wed, Apr 13, 2011 at 2:02 AM, Yury Semikhatsky yu...@chromium.orgwrote: I don't see this stack trace in the inspector when i try it :-/ Good point, I should have probably added a notice that I used a slightly modified version of the hovercard example from the Closure library to get the errors in a real code. Do you think it would be appropriate? Alternatively I could serve the sources from localhost to avoid the confusion on screenshots. Note that for more information on the recent features of the Web Inspector, you can visit the Chrome DevToolshttp://code.google.com/chrome/devtools/docs/overview.html documentation page. It seems like it would be good to get inspector details onto webkit.org A while ago there was a discussion about open sourcing Apple Safari's Web Inspector documentation and having non-Apple contributors working on it. But publishing that documentation at webkit.org would require an approval from Apple's legal team which would likely take for indefinitely long time. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blog post draft: dealing with exceptions using Web Inspector
Including the draft content inline for those who don't have post permissions. Thanks, Yury Web Inspector: Understanding Stack Traceshttp://www.webkit.org/blog/?p=1544Posted by *Yury Semikhatsky* on Wednesday, April 13th, 2011 at 1:44 am Finding errors in JavaScript code both during application development and when it’s already released is an important part of web development. We’ve recently added a mechanism for handling uncaught JavaScript exceptions and made some improvements in the tools that allow you to work with stack traces. Now it’s a good time to summarize the ways one can deal with exceptions and stack traces in WebKit. Tracking exceptions When something goes wrong, you open the Web Inspector console (Ctrl+Shift+J / Cmd+Option+J) and find a number of JavaScript error messages there. Each message has a link to the file name with the line number you can navigate to. However, there might be several execution paths that lead to the error and it’s not always obvious which one of them has happened. Since recently, once Web Inspector window is opened, exceptions in the console are accompanied with the complete JavaScript call stacks. You can expand these console messages to see the stack frames and navigate to the corresponding locations in the code: You may also want to pause JavaScript execution next time exception is thrown and inspect its call stack, scope variables and state of your app. A tri-state stop button at the bottom of the Scripts panel enables you to switch between different exception handling modes: you can choose to either pause on all exception or only on the uncaught ones or you can ignore exceptions altogether. Printing stack traces Printing log messages to the Web Inspector console is also very helpful in understanding how your application behaves. Now you can make the log entries even more informative by including associated stack traces. There are several ways of doing that. - You can instrument your code with console.trace() calls that would print current JavaScript call stacks: - There is also a way to place assertion in your JavaScript code. Just call console.assert() with the error condition as the first parameter. Whenever this expression evaluates to false you will see a corresponding console record: Handling exceptions at runtime using window.onerror Recently we’ve added support for setting a handler function to window.onerror. Whenever a JavaScript exception is thrown in the window context and is not caught by any try/catch block, the function will be invoked with the exception’s message, the URL of the file where the exception was thrown and the line number in that file passed as three arguments in that order. You may find it convenient to set an error handler that would collect information about uncaught exceptions and report it back to your server. Note that for more information on the recent features of the Web Inspector, you can visit the Chrome DevToolshttp://code.google.com/chrome/devtools/docs/overview.html documentation page. You can follow any responses to this entry through the RSS 2.0http://www.webkit.org/blog/?p=1544/feed/ feed. Both comments and pings are currently closed. Edit this entry.http://www.webkit.org/blog/wp-admin/post.php?action=editpost=1544 Comments are closed. On Wed, Apr 13, 2011 at 10:35 AM, Yury Semikhatsky yu...@chromium.orgwrote: Hello everyone, I've prepared a blog post draft( http://www.webkit.org/blog/?p=1544preview=true) that gives an overview of various ways of dealing with JavaScript stack traces and exceptions using Web Inspector. Your comments and suggestions are welcome. Thanks, Yury ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebCore: Exposing exceptions through WebFrameImpl::executeScriptAndReturnValue and ScriptController::executeScript.
On Wed, Dec 22, 2010 at 7:22 PM, Tom Rathbone tom.rathb...@gmail.comwrote:
From my experiments calling executeScriptAndReturnValue function
foo() { } foo(); will also return an empty handle meaning that this
can't reliably be used to detect errors. Is there another way to
distinguish non values from errors?
I see, the problem is that 'undefined' value is converted into an empty
ScriptValue in ScriptController::evaluate:
http://codesearch.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/third_party/WebKit/WebCore/bindings/v8/ScriptController.cppq=::executeScriptAndReturnValue%5C(gs=cpp:WebCore::ScriptController::executeScript(const%2520WebCore::ScriptSourceCode%2520amp;,%2520enum%2520ShouldAllowXSS)@chrome/trunk/src/third_party/WebKit/WebCore/bindings/v8/ScriptController.h%257Cdeclgsn=executeScriptd=5l=260http://codesearch.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/third_party/WebKit/WebCore/bindings/v8/ScriptController.cppq=::executeScriptAndReturnValue%5C(gs=cpp:WebCore::ScriptController::executeScript(const%2520WebCore::ScriptSourceCode%2520,%2520enum%2520ShouldAllowXSS)@chrome/trunk/src/third_party/WebKit/WebCore/bindings/v8/ScriptController.h%257Cdeclgsn=executeScriptd=5l=260
Not sure what this conversion is used for.
Yury
On Wed, Dec 22, 2010 at 2:35 PM, Yury Semikhatsky yu...@chromium.org
wrote:
Hi Tom,
In case of uncaught JS exception returned v8::Handle will always be empty
(v8::Handlev8::Value::IsEmpty() will return true) while in case of
successful
evaluation the result is always non-empty. Also uncaught JS exception
will
be
reported to the console object(see Console.cpp) which will propagate them
to
InspectorController and ChromeClient.
Thanks,
Yury
On Wed, Dec 22, 2010 at 12:58 PM, Tom Rathbone tom.rathb...@gmail.com
wrote:
Hi Guys,
I was wondering if it would be possible to expose v8 exceptions
through WebFrameImpl::executeScriptAndReturnValue and
ScriptController::executeScript, perhaps as an output reference
argument.
The effected methods would be:
v8::Handlev8::Value WebFrameImpl::executeScriptAndReturnValue(const
WebScriptSource source)
ScriptValue ScriptController::executeScript(const ScriptSourceCode
sourceCode, ShouldAllowXSS shouldAllowXSS)
ScriptValue ScriptController::evaluate(const ScriptSourceCode
sourceCode, ShouldAllowXSS shouldAllowXSS)
v8::Localv8::Value V8Proxy::evaluate(const ScriptSourceCode source,
Node* node)
If I've read the source correctly V8 exceptions are caught in
V8Proxy::evaluate and swallowed. This means clients calling
executeScriptAndReturnValue have no easy way of determining what went
wrong or of responding to script errors.
Maybe...
v8::Handlev8::Value WebFrameImpl::executeScriptAndReturnValue(const
WebScriptSource source, bool exceptionReturned)
If others think these changes are worthwhile then I'll have a go at
crafting a patch.
Thanks,
Tom.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebCore: Exposing exceptions through WebFrameImpl::executeScriptAndReturnValue and ScriptController::executeScript.
On Wed, Dec 22, 2010 at 8:28 PM, Tom Rathbone tom.rathb...@gmail.comwrote:
Sounds like this conversion might be being done in the wrong place, it
doesn't feel like this should be the responsibility of this method
since undefined is a valid return value from any JavaScript call.
I agree, this looks like a bug and proper fix would be to remove this
conversion
from that place. We need to double check that this won't break Chromium's
code.
On Wed, Dec 22, 2010 at 4:41 PM, Yury Semikhatsky yu...@chromium.org
wrote:
On Wed, Dec 22, 2010 at 7:22 PM, Tom Rathbone tom.rathb...@gmail.com
wrote:
From my experiments calling executeScriptAndReturnValue function
foo() { } foo(); will also return an empty handle meaning that this
can't reliably be used to detect errors. Is there another way to
distinguish non values from errors?
I see, the problem is that 'undefined' value is converted into an empty
ScriptValue in ScriptController::evaluate:
http://codesearch.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/third_party/WebKit/WebCore/bindings/v8/ScriptController.cppq=::executeScriptAndReturnValue%5C(gs=cpp:WebCore::ScriptController::executeScript(const%2520WebCore::ScriptSourceCode%2520amp
;,%2520enum%2520ShouldAllowXSS)@chrome/trunk/src/third_party/WebKit/WebCore/bindings/v8/ScriptController.h%257Cdeclgsn=executeScriptd=5l=260
Not sure what this conversion is used for.
Yury
On Wed, Dec 22, 2010 at 2:35 PM, Yury Semikhatsky yu...@chromium.org
wrote:
Hi Tom,
In case of uncaught JS exception returned v8::Handle will always be
empty
(v8::Handlev8::Value::IsEmpty() will return true) while in case of
successful
evaluation the result is always non-empty. Also uncaught JS exception
will
be
reported to the console object(see Console.cpp) which will propagate
them
to
InspectorController and ChromeClient.
Thanks,
Yury
On Wed, Dec 22, 2010 at 12:58 PM, Tom Rathbone
tom.rathb...@gmail.com
wrote:
Hi Guys,
I was wondering if it would be possible to expose v8 exceptions
through WebFrameImpl::executeScriptAndReturnValue and
ScriptController::executeScript, perhaps as an output reference
argument.
The effected methods would be:
v8::Handlev8::Value WebFrameImpl::executeScriptAndReturnValue(const
WebScriptSource source)
ScriptValue ScriptController::executeScript(const ScriptSourceCode
sourceCode, ShouldAllowXSS shouldAllowXSS)
ScriptValue ScriptController::evaluate(const ScriptSourceCode
sourceCode, ShouldAllowXSS shouldAllowXSS)
v8::Localv8::Value V8Proxy::evaluate(const ScriptSourceCode
source,
Node* node)
If I've read the source correctly V8 exceptions are caught in
V8Proxy::evaluate and swallowed. This means clients calling
executeScriptAndReturnValue have no easy way of determining what went
wrong or of responding to script errors.
Maybe...
v8::Handlev8::Value WebFrameImpl::executeScriptAndReturnValue(const
WebScriptSource source, bool exceptionReturned)
If others think these changes are worthwhile then I'll have a go at
crafting a patch.
Thanks,
Tom.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] !ENABLE(INSPECTOR)
I don't think there is a particular person who maintains that option. Instead if you cannot find the change which broke it and file a bug against the author you could file a bug against the web inspector component( webkit.org/new-inspector-bug) and we'll take care of it. In this particular case it was my change http://trac.webkit.org/changeset/71515 that broke it. I didn't see the failure because I tried to build webkit with --minimal option(and it was fine) which is usually enough but apparently not in this case. Yury On Sun, Nov 14, 2010 at 2:38 AM, Patrick Gansterer par...@paroga.comwrote: I filed bug 49500 (including patch). But I'm still interested if there is someone who maintains the ENABLE(INSPECTOR) option. Simon Fraser: Please file a bugzilla bug on this issue. Simon On Nov 13, 2010, at 8:15 AM, Patrick Gansterer wrote: Hi, Does anybody compile WebKit with inspector disabled? It's not possible with the current trunk (since weeks). I'm not sure what's the correct solution to fix this. The main problem is that Console.cpp (e.g. at [1]) uses ScriptCallStack and ScriptCallStackFrame, but this classes should go into a #if ENABLE(INSPECTOR) section IMHO. Otherwise they must not use any classes from InspectorValues (e.g. at [2]). Can someone fix this (or at least point me to the right solution)? [1] http://trac.webkit.org/browser/trunk/WebCore/page/Console.cpp?rev=71966#L171 [2] http://trac.webkit.org/browser/trunk/WebCore/inspector/ScriptCallStack.cpp?rev=71515#L77 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] InspectorDebuggerAgent::didPause function
Hi Tomasz, There is no need to differentiate between pause due to an exception and due to a breakpoint hit and there are no means to determine that in InspectorDebuggerAgent::didPause. Detailed information about the break event is available in WebCore/bindings/v8/ScriptDebugServer::handleV8DebugEvent(I believe it can be retrieved in WebCore/bindings/js/ScriptDebugServer too) where we can say whether it was an exception or not, we just don't push it to InspectorDebuggerAgent since we don't need it in the front-end. -yury On Tue, Oct 19, 2010 at 5:01 PM, Tomasz Morawski t.moraw...@samsung.comwrote: Hi, Is there any way to get know if InspectorDebuggerAgent::didPause call was due to an exception or not? I have tried to use scriptState-hadException() inside this function but it seems that the hadException function always returns false. Thanks, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
