<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#c9">Comment # 9</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:cgarcia@igalia.com" title="Carlos Garcia Campos <cgarcia@igalia.com>"> <span class="fn">Carlos Garcia Campos</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=157899#c8">comment #8</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=157899#c7">comment #7</a>)
> > (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.
>
> 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 >
That's indeed not the right way to do it. The web extension should emit a signal when document loaded happens instead of relying on web view load events that have nothing to do with dom bindings.
<span class="quote">> > The right place to use DOM bindings is WebKitWebPage::document-loaded in the
> > web extensions API.
>
> I understood it as an equivalent of the WebKitWebView::load-changed signal.</span >
It's not.
<span class="quote">> 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 >
The UI process should wait for the document-loaded signal to allow the user click on that button, or send a message to the extension, and the extension should queue it until document-loaded happens.
<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.
>
> 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.</span >
This doesn't look like a valid use case for exposing frames in the UI process to me yet, but maybe I didn't understand it correctly.</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>