[Webkit-unassigned] [Bug 157899] [GTK] Provide frame-related load signals in WebKitWebView

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=157899

--- Comment #7 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #0)
> While working on the Evolution port to the WebKit2, I realized that there is
> a problem when to attach DOM bindings, especially when the web view contains
> iframe-s (and these iframe-s can be formatted mail messages, which also
> contain iframe-s).

What do you mean by attach DOM bindings? DOM bindings live in the web process, so I don't understand how new API in the UI process can help with that.

> The only current way of noticing when the loading was
> finished is to listen to WebKitWebView::load-event and add the bindings when
> the load_event == WEBKIT_LOAD_FINISHED, but it's a matter of luck whether
> the internal iframe-s will be loaded or not at that time.
> 
> Due to this, I propose a new signal to be added to the WebKitWebView with a
> name "frame-loaded", with a prototype:
> 
>     void
>     frame_loaded (WebKitWebView *web_view,
>                   const gchar *frame_src, /* 'src' attribute content of the
> loaded (i)frame */
>                   const gchar *frame_id,  /* 'id' attribute content of the
> loaded (i)frame */
>                   gpointer user_data)
> 
> which will be called whenever any (i)frame will be in a state equivalent of
> the load_event == WEBKIT_LOAD_FINISHED of the main WebKitWebView.
> That way, the subscriber to this signal will know that everything is ready
> and the DOM bindings can be safely done on that particular frame.

The right place to use DOM bindings is WebKitWebPage::document-loaded in the web extensions API. It's true that is only available for the main frame, but if we need to grow the API to non main frames it has to be in the web process, probably adding WebKitFrame::document-loaded and webkit_frame_get_dom_document().

> I was told that you have a similar request from someone else already, but I
> didn't find it in the bugzilla (maybe I used wrong search term), thus I
> filled it myself.

We have tried hard not to expose frames in the UI process API, since it was very confusing in webkit1 and often misused, so we need a use case here to expose it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160524/9b3319dc/attachment.html>