[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 #9 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #8)
> (In reply to comment #7)
> > (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 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.

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.

> > 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.

It's not.

> 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.

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.

> > 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.

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.

-- 
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/117888df/attachment.html>