[chromium-dev] Re: WebKitApi (test_shell) and DevTools, JS debugging
Hi, It seems I've already found an answer - JS debugger is viable under test_shell after a small change: Index: WebViewImpl.cpp === --- WebViewImpl.cpp (revision 53449) +++ WebViewImpl.cpp (working copy) @@ -234,7 +234,11 @@ 0)); m_page->backForwardList()->setClient (&m_backForwardListClientImpl); -m_page->setGroupName(pageGroupName); + +char pageGroupNameCurr[100]; +static int i = 1; +sprintf(pageGroupNameCurr, "default%d", i++); +m_page->setGroupName(pageGroupNameCurr); } WebViewImpl::~WebViewImpl() There is a short description: When hitting a breakpoint, WebKit pauses all active DOM elements in the current "Page group". Chrome uses only one page group for all pages, that's why WebKit pauses all active DOM elements including these one that belong to DevTools page. Ideally, I think it would be better to provide an ability to set Page Group name through WebKit API and set custom "Page group" name for DevTools page. As far as one of WebKit API goals is to allow third-party developers to build their own apps on it, do you think it will be useful to extend WebKit API in this way? Regards, Vadim Ridosh On Jan 18, 7:16 pm, vridosh wrote: > Hi, > > I'm going to start my project based on WebKit API and planning to use > test_shell as a reference implementation. I also want to use DevTools > to allow end-user to debug HTML and especially JavaScript. > > Could you please tell how viable is the JS debugger in test_shell/ > WebKit API? > > As far as I understand, in case of breakpoint V8 debugger stops the > script execution on the whole process. That problem could be easy > reproduced while running Chrome in single-process mode (AFAIR, this > mode is obsolete for modern Chromium browser) - trying to pause script > execution pauses all JS code, including DevTools JS code too, which > causes "deadlock" - script couldn't be resumed anymore. As far as I > understand, that's why Debugger tab was not available in test_shell in > early Chromium builds. But when I tried to use current test_shell > build, I was able to pause JS execution on breakpoint and then resume > JS again. From the other hand, while staying on JS breakpoint not all > parts of DevTools debugger works well - f.e. I couldn't execute JS in > console. Also, as I got, pausing JS in any custom place (I mean, left > button just above watch expressions and call stack) not implemented > yet it all. > > So, the main question is - is it possible at all to make DevTools JS > debugger in test_shell to work correctly? > > I'd appreciate any suggestions. > > Regards, > Vadim Ridosh -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: WebKitApi (test_shell) and DevTools, JS debugging
Hi Peter Thank you for your response, but probably I was unclear in my question. I'm not very interesting in test_shell future - I'm forced to use it as a reference implementation simply because for now I have no alternatives (except, probably, the whole Chromium code). What I'm most curious about - is it possible or not to use DevTools JS debugger in single-process environment (like WebKit's WebInspector JS debugger)? I used to be sure it is not possible at all because of V8 architecture, but now I see at least some features work. I'm reading V8 code now, but may be someone could give me a quick answer whether this solution viable or not? Thanks again for your answer. Regards, Vadim Ridosh On Jan 19, 2:22 am, Peter Kasting wrote: > On Mon, Jan 18, 2010 at 9:16 AM, vridosh wrote: > > As far as I > > understand, that's why Debugger tab was not available in test_shell in > > early Chromium builds. > > Probably the real reason is because test_shell isn't meant to be a reference > implementation of everything and we never bothered to spend any time on it. > > So, the main question is - is it possible at all to make DevTools JS > > > debugger in test_shell to work correctly? > > AFAIK test_shell is obsolete and is going to die when we implement > DumpRenderTree atop the WebKit API. Darin or Dimitri or someone can correct > me if I'm wrong. > > I would definitely not depend on or look at test_shell for any serious > project. > > PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] WebKitApi (test_shell) and DevTools, JS debugging
Hi, I'm going to start my project based on WebKit API and planning to use test_shell as a reference implementation. I also want to use DevTools to allow end-user to debug HTML and especially JavaScript. Could you please tell how viable is the JS debugger in test_shell/ WebKit API? As far as I understand, in case of breakpoint V8 debugger stops the script execution on the whole process. That problem could be easy reproduced while running Chrome in single-process mode (AFAIR, this mode is obsolete for modern Chromium browser) - trying to pause script execution pauses all JS code, including DevTools JS code too, which causes "deadlock" - script couldn't be resumed anymore. As far as I understand, that's why Debugger tab was not available in test_shell in early Chromium builds. But when I tried to use current test_shell build, I was able to pause JS execution on breakpoint and then resume JS again. From the other hand, while staying on JS breakpoint not all parts of DevTools debugger works well - f.e. I couldn't execute JS in console. Also, as I got, pausing JS in any custom place (I mean, left button just above watch expressions and call stack) not implemented yet it all. So, the main question is - is it possible at all to make DevTools JS debugger in test_shell to work correctly? I'd appreciate any suggestions. Regards, Vadim Ridosh -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: CEF past and future
Hi PhistucK, Chrome Frame is a good starting point for creating new CEF. Unfortunately, it works only under Windows. And, as far as I understand, there is no plans to support Chrome Frame for other OSes. I investigated code a bit - as far as I got, Chromium Frame uses Chrome Automation interface for communicating with Chrome process. Chrome Automation interface seems to be wide enough to implement most of currently exisiting CEF functionality. In theory, we can try to port Chrome Frame to Mac/Linux - but it use approach with embedding window from one process into another process' window. This works in Windows, but I doubt it will work on Mac/Linux. Regards, Vadim Ridosh On 17 Грд, 18:25, PhistucK wrote: > Actually, I may be thinking foolishly, but, is not Chrome Frame kind of like > CEF, in a way? > And with the future direction you are thinking about, I guess you can merge > the two, or use it extensively to make your work much easier. > > Am I wrong? > > ☆PhistucK > > On Wed, Dec 16, 2009 at 21:43, Marshall Greenblatt > wrote: > > > > > Hi All, > > > Thanks to the wonderful support of the Chromium development community the > > Chromium Embedded Framework (CEF) has survived to see its first birthday :-) > > > In the hopes of keeping CEF alive for many years to come I've written up my > > future development plan. Comments and suggestions are welcome. > > >http://magpcss.org/ceforum/viewtopic.php?f=10&t=69 > > > Regards, > > Marshall > > > -- > > Chromium Developers mailing list: chromium-dev@googlegroups.com > > View archives, change email options, or unsubscribe: > >http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
