<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK] Provide frame-related load signals in WebKitWebView"
href="https://bugs.webkit.org/show_bug.cgi?id=157899#c8">Comment # 8</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK] Provide frame-related load signals in WebKitWebView"
href="https://bugs.webkit.org/show_bug.cgi?id=157899">bug 157899</a>
from <span class="vcard"><a class="email" href="mailto:mcrha@redhat.com" title="Milan Crha <mcrha@redhat.com>"> <span class="fn">Milan Crha</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=157899#c7">comment #7</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=157899#c0">comment #0</a>)
> > 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.</span >
The evolution plays a ping-pong over D-Bus between the UI part (evolution) and the WebProcess part (webkit extension, to which the D-Bus is connected). Currently, in the webkit2 port branch of the evolution, the UI part listens for WebKitWebView::load-changed signal. Once it receives WEBKIT_LOAD_FINISHED event it asks the WebProcess part to attach DOM bindings. This goes through D-Bus and there is no guarantee when exactly it'll be delivered, thus, when the parts being meant already available in the DOM structure, are sometimes available and sometimes not, depending whether the WebKit had enough time to load also sub-frames of the main frame.
<span class="quote">> The right place to use DOM bindings is WebKitWebPage::document-loaded in the
> web extensions API.</span >
I understood it as an equivalent of the WebKitWebView::load-changed signal. The thing is that the DOM bindings are of a nature "button clicked", which the UI part responds to and does some UI magics for the user, when "the button" is clicked. That means that the UI part generates some HTML, then it asks the web extension to attach "click" event listener on the elements, and when they are clicked the D-Bus signal lets the UI part know. Interprocess communication is sort of nightmare.
<span class="quote">> 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.</span >
Okay, I would try to provide a test application, but as it involves the WebProcess extension, then it could be pretty complex, thus I hesitate to do it, unless really necessary.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>