Closed GoogleCodeExporter closed 9 years ago
So this only happens when you try to debug the startup URL. In CEFClient for
instance, if you switch from google.com to another app, you can debug that 2nd
app just fine.
Original comment by corey.lu...@gmail.com
on 11 Jun 2012 at 9:07
Basically seems that as long as you run dev tools in an alternate helper that
doesn't correspond to the same process of the page you are debugging it works
fine...
I'm not familiar enough with the CEF3 APIs to know how to open my devtools page
in it's own browser/helper instance though. Can someone provide cookbook code
for that?
Original comment by corey.lu...@gmail.com
on 11 Jun 2012 at 9:19
Looking into DevTools issues now. Stay tuned...
Original comment by magreenb...@gmail.com
on 11 Jun 2012 at 9:23
Windows 7 64bit
CEF3 revision 694
Revision 138497
(http://src.chromium.org/viewvc/chrome?view=rev&revision=138497) changed
DevToolsDelegate to use TCPListenSocket. As a result of this change I'm now
experiencing an interesting problem on Windows where no read requests for HTTP
resources are delivered after the WebSocket connection is accepted. The browser
doesn't hang, which is great, but at some point it stops receiving requests for
resources from the DevTools front-end. In the below example I'm using the
chrome-devtools scheme to host the DevTools resources but the same problem
occurs if I return true from BundlesFrontendResources so that resources are
handled directly using ResourceBundle.
I've added logging in TCPListenSocket and StreamListenSocket to further
understand the problem. After launching a new browser window with the DevTools
front-end I see the following behavior:
[0612/125642:INFO:stream_listen_socket.cc(250)]
StreamListenSocket::OnObjectSignaled() socket 620 ev.lNetworkEvents 8
[0612/125643:INFO:tcp_listen_socket.cc(81)] TCPListenSocket::Accept() conn 1352
[0612/125643:INFO:stream_listen_socket.cc(250)]
StreamListenSocket::OnObjectSignaled() socket 620 ev.lNetworkEvents 8
[0612/125643:INFO:tcp_listen_socket.cc(81)] TCPListenSocket::Accept() conn 1328
[0612/125643:INFO:stream_listen_socket.cc(250)]
StreamListenSocket::OnObjectSignaled() socket 1352 ev.lNetworkEvents 1
[0612/125644:INFO:stream_listen_socket.cc(169)] StreamListenSocket::Read()
socket 1352 len 475
[0612/125644:INFO:scheme_impl.cc(258)] CefUrlRequestManager hit for
chrome-devtools://devtools/devtools.html
[0612/125645:INFO:stream_listen_socket.cc(250)]
StreamListenSocket::OnObjectSignaled() socket 1352 ev.lNetworkEvents 1
[0612/125646:INFO:stream_listen_socket.cc(169)] StreamListenSocket::Read()
socket 1352 len 446
[0612/125646:INFO:scheme_impl.cc(258)] CefUrlRequestManager hit for
chrome-devtools://devtools/devTools.css
[0612/125648:INFO:stream_listen_socket.cc(250)]
StreamListenSocket::OnObjectSignaled() socket 1328 ev.lNetworkEvents 1
[0612/125648:INFO:stream_listen_socket.cc(169)] StreamListenSocket::Read()
socket 1328 len 430
[0612/125649:INFO:scheme_impl.cc(258)] CefUrlRequestManager hit for
chrome-devtools://devtools/DevTools.js
[0612/125652:INFO:stream_listen_socket.cc(250)]
StreamListenSocket::OnObjectSignaled() socket 1328 ev.lNetworkEvents 1
[0612/125653:INFO:stream_listen_socket.cc(169)] StreamListenSocket::Read()
socket 1328 len 457
[0612/125654:INFO:scheme_impl.cc(258)] CefUrlRequestManager hit for
chrome-devtools://devtools/Images/statusbarBackgroundChromium.png
[0612/125655:INFO:stream_listen_socket.cc(250)]
StreamListenSocket::OnObjectSignaled() socket 1352 ev.lNetworkEvents 1
[0612/125655:INFO:stream_listen_socket.cc(169)] StreamListenSocket::Read()
socket 1352 len 463
[0612/125656:INFO:scheme_impl.cc(258)] CefUrlRequestManager hit for
chrome-devtools://devtools/Images/statusbarBottomBackgroundChromium.png
[0612/125657:INFO:stream_listen_socket.cc(250)]
StreamListenSocket::OnObjectSignaled() socket 620 ev.lNetworkEvents 8
[0612/125657:INFO:tcp_listen_socket.cc(81)] TCPListenSocket::Accept() conn 1416
[0612/125657:INFO:stream_listen_socket.cc(250)]
StreamListenSocket::OnObjectSignaled() socket 1416 ev.lNetworkEvents 1
[0612/125658:INFO:stream_listen_socket.cc(169)] StreamListenSocket::Read()
socket 1416 len 280
[0612/125658:INFO:stream_listen_socket.cc(250)]
StreamListenSocket::OnObjectSignaled() socket 1416 ev.lNetworkEvents 1
[0612/125658:INFO:stream_listen_socket.cc(169)] StreamListenSocket::Read()
socket 1416 len 54
[0612/125658:INFO:stream_listen_socket.cc(250)]
StreamListenSocket::OnObjectSignaled() socket 1416 ev.lNetworkEvents 1
[0612/125659:INFO:stream_listen_socket.cc(169)] StreamListenSocket::Read()
socket 1416 len 60
[0612/125659:INFO:stream_listen_socket.cc(250)]
StreamListenSocket::OnObjectSignaled() socket 1416 ev.lNetworkEvents 1
[0612/125659:INFO:stream_listen_socket.cc(169)] StreamListenSocket::Read()
socket 1416 len 54
[0612/125659:INFO:stream_listen_socket.cc(250)]
StreamListenSocket::OnObjectSignaled() socket 1416 ev.lNetworkEvents 1
[0612/125700:INFO:stream_listen_socket.cc(169)] StreamListenSocket::Read()
socket 1416 len 45
[0612/125700:INFO:stream_listen_socket.cc(250)]
StreamListenSocket::OnObjectSignaled() socket 1416 ev.lNetworkEvents 1
[0612/125700:INFO:stream_listen_socket.cc(169)] StreamListenSocket::Read()
socket 1416 len 50
[0612/125700:INFO:stream_listen_socket.cc(250)]
StreamListenSocket::OnObjectSignaled() socket 1416 ev.lNetworkEvents 1
[0612/125701:INFO:stream_listen_socket.cc(169)] StreamListenSocket::Read()
socket 1416 len 63
[0612/125701:INFO:stream_listen_socket.cc(250)]
StreamListenSocket::OnObjectSignaled() socket 1416 ev.lNetworkEvents 1
[0612/125701:INFO:stream_listen_socket.cc(169)] StreamListenSocket::Read()
socket 1416 len 55
I've sent an email to Chromium devs associated with this change. We'll see what
they suggest.
Original comment by magreenb...@gmail.com
on 12 Jun 2012 at 5:09
Original comment by magreenb...@gmail.com
on 12 Jun 2012 at 5:11
Here's the thread related to comment#4 on chromium-dev:
http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/
cd3b382fb0323ae4
Original comment by magreenb...@gmail.com
on 12 Jun 2012 at 5:15
Is the Chromium issue actually related to the item I'm seeing? In the spirit of
workarounds, for the short term (and for my OSX issue), is there any easy way
to launch dev tools in another helper process (Browser instance) vs. using
window.open which I'm doing now? Kind of makes sense that break points won't
work when both share the same V8 instance right?
Original comment by corey.lu...@gmail.com
on 12 Jun 2012 at 5:24
@comment#7: It may be related (some issue with thread/message handling in
Chromium). Do breakpoints work for you in 3.1142.654?
Since the browser process if effectively your application, you would just need
to launch another instance of your application and point it at the URL returned
by CefBrowserHost::GetDevToolsURL().
Original comment by magreenb...@gmail.com
on 12 Jun 2012 at 5:34
Here is some more info on this bug:
* If you open the Dev Tools window and then navigate to a new URL, everything
works fine (as mentioned in comment 1)
* If you navigate to a new URL *before* opening the Dev Tools window, opening
Dev Tools shows a blank window and you get an "Unexpected response code: 500"
error in the console
Original comment by grue...@gmail.com
on 14 Jun 2012 at 2:36
I don't think we can star this particular bug enough. Debugging functionality
is obviously paramount to development. ;) At least in my case on OSX I can
use an external Chrome instance.
Original comment by corey.lu...@gmail.com
on 14 Jun 2012 at 3:02
I've been unsuccessful in identifying the revision that caused the deadlock in
comment #4. Furthermore, since there are no tests in Chromium for running the
DevTools remote debugging client and server in the same process, it's highly
likely that this usage would break again in the future.
Consequently, the recommendation at this time is to run the DevTools client in
a separate process (see comment #8 above). I'll update cefclient to demonstrate
this usage.
The longer term solution is to provide an alternate implementation of DevTools
that does not use remote debugging. See for example
chrome/browser/debugger/devtools_window.[cc|h]. This is now issue #659.
Original comment by magreenb...@gmail.com
on 25 Jun 2012 at 9:41
Revision 712 fixes the issue in comment#4. The problem was that, with recent
Chromium updates, the RenderView identifiers change. We need to update the
DevTools URLs to properly reflect the new identifier values. The following
console output led to the discovery of the problem:
[0626/115230:INFO:CONSOLE(0)] "Unexpected response code: 500", source:
http://localhost:8088 (0)
[0626/115230:INFO:CONSOLE(2855)] "[object Event]", source:
http://localhost:8088/devtools/DevTools.js (2855)
After setting a breakpoint in WebSocketHandshake::readServerHandshake we can
see the error returned by the WebSocket server in the the |header| parameter.
Original comment by magreenb...@gmail.com
on 26 Jun 2012 at 4:26
Revision 713 adds an example to cefclient of launching DevTools in an external
browser window and process (via "external-devtools" command line flag) using
new CefGetPath and CefLaunchProcess functions.
Original comment by magreenb...@gmail.com
on 26 Jun 2012 at 4:48
Original issue reported on code.google.com by
corey.lu...@gmail.com
on 11 Jun 2012 at 8:16