| 35 | | Drosera is currently not available on Windows. Much of Drosera is written in JavaScript and should require very little modifications to run on Windows. The Cocoa application wrapper is not portable will need to be rewritten using native Windows APIs. Hop onto [http://webkit.org/contact.html "our irc channel"] if you're interested in porting Drosera to Windows. |
| | 35 | Most of Drosera has been ported to windows and can now run and attach to a Safari on Windows instance. Drosera is not currently in a nightly and will need to be built from the source. |
| | 36 | |
| | 37 | == Design == |
| | 38 | === Drosera === |
| | 39 | Much of the design of Drosera on Windows is intentionally extremely similar to the design of Drosera on Mac, however, because of the many small differences, for clarity, this section will only focus on the design on Windows without identifying the divergences. |
| | 40 | |
| | 41 | The'''Drosera class''' initializes the UI, sets up its own WebView where it shows its JavaScript, and creates a DebuggerClient class which it polls repeatedly, waiting for the DebuggerClient to establish a connection with a WebKit app that can be debugged. |
| | 42 | |
| | 43 | The '''DebuggerClient''' primarily, acts as the UI and FrameLoad delegate for Drosera's main window and also the Console window. The DebuggerClient also passes UI Commands to the DebuggerDocument to be executed in Drosera's own JavaScript, and owns the DebuggerDocument. |
| | 44 | |
| | 45 | The '''DebuggerDocument''' is the object that interacts directly with the ServerConnection and Drosera's own JavaScript. The DebuggerDocument has a set of callbacks that Drosera's own JavaScript can call which then call platform-dependent versions of a given function to execute their request. The DebuggerDocument also has functions that allow other objects, like the ServerConnection object, to make calls into Drosera's own JavaScript. |
| | 46 | |
| | 47 | The '''ServerConnection''' object implements IWebScriptDebugListener and encapsulates all of the interactions with the remote WebKit server. |
| | 48 | |
| | 49 | === WebKit === |
| | 50 | This section describes the design of the parts of Webkit, and JavaScriptCore that exist to allow Drosera to interact with WebKit. |
| | 51 | |
| | 52 | In WebKit there is a '''WebScriptDebugServer''' which is started when WebKit starts and listens for a DCOM connection. Once a connection is made it will begin to interact with Drosera via Drosera's ServerConnection class. WebScriptDebugServer informs Drosera about every line of JavaScript executed. |
| | 53 | |
| | 54 | The '''WebScriptDebugger''' is also in WebKit and is told by JavaScript when a line of code is executed and keeps state information locally then informs the WebScriptDebugServer about the executing JavaScript. |
| | 55 | |
| | 56 | In JavaScriptCore there is a '''debugger class''' that only is instantiated if Drosera connects to the WebScriptDebugServer and if so it tells the WebScriptDebugger when JavaScript is executing. |
| | 57 | |
| | 58 | Two classes that WebScriptDebugger uses to keep track of the JavaScript state are '''WebScriptCallFrame''', which represents a JavaScript call frame and can process javascript with respect to that call frame, and '''WebScriptScope''', which provides the variable names and values for a given call frame. |
| | 59 | |
| | 60 | === Pause Example === |
| | 61 | When "pause" is selected from the toolbar command in the UI a message is received by the Drosera class which passes the command onto the DebuggerClient which uses the DebuggerDocument to directly call pause in Drosera's own JavaScript. Drosera's JavaScript set's a local variable and then tells the DebuggerDocument to pause by calling the appropriate callback method. This method calls the platform dependent version of pause which tells the ServerConnection object to pause, who, in turn, uses a remote procedure call to tell webkit it wishes to pause it. The WebScriptDebugServer sets an internal variable and then returns to normal execution. |
| | 62 | |
| | 63 | If JavaScript source is parsed, about to execute a statement or exiting a function, the JavaScriptCore debugger class will notify the WebScriptDebugger. The WebScriptDebugger will update it's internal state (increasing or decreasing the stack depth if necessary) and then call the appropriate WebScriptDebugServer function to represent what occurred in the JavaScript. The WebScriptDebugServer will notify any listeners it has of the even in JavaScript, which may or may not cause subsequent calls back into the WebScriptDebugServer from Drosera, or cause more JavaScript to be executed, but upon finishing the notification of listeners of the original JavaScript event the WebScriptDebugServer will check if it has been told to pause. If it has, it will stay in a look that only listens for new instructions from the remote debugger. Once Drosera tells the WebScriptDebugServer that it is no longer paused, WebKit's execution will continue as normal. |
