yinxianwei / chromedevtools

Automatically exported from code.google.com/p/chromedevtools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Need API for evaluate_javascript command #20

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Currently the evaluate_javascript command is supported internally but not 
exposed as API. Attached is a 
patch to add an evaluateJavaScript() method to the org.chromium.SDK.BrowserTab 
interface. 

I took this approach because it seemed that the standalone v8 vm might not 
support it, so it could not be in 
a command interface. The idea is that a client would do a runtime instanceof 
check on 
org.chromium.sdk.JavascriptVm to see if it implements BrowserTab, and then cast 
to BrowserTab to invoke 
evaluateJavaScript().

Original issue reported on code.google.com by dpodwall on 16 Feb 2010 at 8:44

Attachments:

GoogleCodeExporter commented 8 years ago
The proposed API might not be generic enough. The evaluate command does not 
return 
result.

Please provide a rationale why there should be use-cases for such responseless 
method.

There is a reason behind the internal method not having response. Response 
includes 
object ref id, that is used further object property lookups. The ref id lives 
only 
during suspend-continue period. Thus without suspended state there is no way 
you can 
browse object's properties.

You also may use a work-around here:
javascriptVm.suspend()
...
debugContext.getGlobalEvaluateContext().evaluate...  // this API is in HEAD only
...
debugContext.continueVm();

Note that this API is fully available in HEAD only (hasn't made its way into 
release 
builds yet).

Original comment by peter.ry...@gmail.com on 16 Feb 2010 at 9:12

GoogleCodeExporter commented 8 years ago
From the ChromeDevTools protocol doc I'd understood that evaluate_javascript 
doesn't 
return any result, so the proposed API just matches that.

Here's my use case for the API. The desired scenario is that before starting a 
debug 
session, user may set a breakpoint in code that will be executed early, e.g. 
window.onload. We want the breakpoint to get hit the first time that code is 
executed, not 
require a refresh.

In order to initiate the debug session we need to target a tab which has a 
specified URL. If 
in starting up the browser we gave the URL for the user's page then their code 
would 
execute before we'd actually attached to the tab, so breakpoints could not get 
install.

So the approach we're using is to initially point the browser to a static 
startup page. Once 
we've successfully attached we use evaluate_javascript to get the browser to 
navigate to 
the user's page.

I'll try the workaround you've suggested. But that requires an extra suspend 
and continue. 
Since evaluate_javascript is in the protocol and works well for at least this 
use case it'd be 
nice to have the plugins support it. 

Thanks!

Original comment by dpodwall on 16 Feb 2010 at 9:48

GoogleCodeExporter commented 8 years ago
This bug should be covered by
http://code.google.com/p/chromedevtools/issues/detail?id=42

Original comment by peter.ry...@gmail.com on 7 Apr 2011 at 6:01