On Wed, May 1, 2013 at 8:41 PM, Martin Robinson
<martin.james.robin...@gmail.com> wrote:
> On Wed, May 1, 2013 at 5:32 PM, Eric Gregory <e...@yorba.org> wrote:
>> Taking a quick look at the new API, WebFrame has been replaced by WebPage,
>> which has a method to get the DOMDocument object:
>> http://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebPage.html#webkit-web-page-get-dom-document
>
> A WebPage corresponds to a WebView, but on the WebProcess side. The C
> API exposes frames, but we have not exposed them in the GObject API
> because we aren't sure if they will continue to be part of the
> internal UIProcess API. That decision is really up to the Apple
> developers -- who have said in the past they were thinking of ditching
> them entirely.
>
> I think what Niranjan is trying to accomplish should be possible with
> a combination of user scripts (which can be injected into all frames)
> and the injection of native JavaScript methods into the DOM. We hope
> to add both of these things to a future release.
Hi. Thanks a lot for your clarifications. I have one final
question/clarification concerning adding native JS methods.
Are you saying that currently with Webkit Gtk 2.0 with Webkit2 i
cannot define native methods to be used by client JS code?
For instance in our current wk1 application we define a 'log_debug()'
function on the window object that works just like 'console.log()' on
chrome and firefox, except the messages go to a normal text file. but
we also do more complex things so this is really important for us.
this is what you mean when you say "injecting native methods into the
DOM", right?
Currently with wk1 we do it like this, hooking the
'window-object-cleared' method, extracting the JSGlobalContext, then
getting the global object (window) and adding a method to it.
static void window_cleared_cb (WebKitWebView *web_view,
WebKitWebFrame *frame, gpointer context, gpointer arg3, gpointer
user_data) {
WebKitWebFrame *web_frame;
JSGlobalContextRef ctx;
JSObjectRef global, func;
JSStringRef func_name, script_str;
global_ctx = ctx = (JSGlobalContextRef) context;
global = JSContextGetGlobalObject(ctx);
func_name = JSStringCreateWithUTF8CString("log_debug");
func = JSObjectMakeFunctionWithCallback(ctx, NULL, log_debug_cb);
JSObjectSetProperty(ctx, global, func_name, func, 0, NULL);
}
static JSValueRef log_debug_cb(JSContextRef ctx, JSObjectRef function,
JSObjectRef thisObject, size_t argumentCount, const JSValueRef
arguments[], JSValueRef *exception) {
JSStringRef js_str;
char * c_str;
size_t c_str_len;
if(argumentCount != 1) {
log_message("ERROR: log_debug_cb: wrong number of arguments.
[%d]", argumentCount);
return JSValueMakeNull(ctx);
}
js_str = JSValueToStringCopy(ctx, arguments[0], NULL);
c_str_len = JSStringGetMaximumUTF8CStringSize(js_str);
c_str = calloc(1, c_str_len);
JSStringGetUTF8CString(js_str, c_str, c_str_len);
log_message("[DEBUG] %s", c_str);
free(c_str);
return JSValueMakeNull(ctx);
}
If i'm understanding things correctly from looking at the epiphany
plugin: It looks like I will be creating a plugin that runs in the
WebProcess and sends dbus messages to my main gtk process (or some
other process). what exactly is missing right now? for one thing: i
see that 'window-object-cleared' is not a valid signal for a
WebKitWebPage and there appears to be no other signal which will allow
me to hook into the right point in the page's life cycle.
Silly question: each page is its own process now, right? Does that
mean obtaining the handle I need could be as easy as calling
JSGlobalContextCreate(0)? Is a new signal itself the only thing
missing or does the signal also need to pass along a
JSGlobalContextRef gpointer like it did before?
I'm willing to be patient and keep using Wk1 while a solution is
worked out (we need continue using wk1 for other reasons related to
hardware video acceleration, but that's another story). Please keep up
the good work!
--christian
This electronic mail message is intended exclusively for the individual or
entity to which it is addressed. The information contained in this
communication is the property of SICOM Systems, Inc. and contains confidential
and privileged proprietary information intended only for the personal and
confidential use of the individual or entity to which it is addressed. If you
are not the addressee indicated in this message (or an agent responsible for
delivery of the message to such person), you are hereby notified that you have
received this communication in error and that any review, dissemination,
copying or unauthorized use of this message is strictly prohibited. In such
case, you should destroy this message and kindly notify the sender by reply
e-mail.
_______________________________________________
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk
