Hi Mario, The motivation of the change was to reduce the chatter between the WebProcess and UIProcess and reduce the amount of knowledge the UIProcess has about the internals of the WebProcess. We will also be removing the UIProcess' notion of the frame tree, for the same reason.
Going forward, if you need that kind of detailed knowledge, you should use the WebInspector or the protocol it is based on. -Sam On Jan 21, 2013, at 5:53 AM, Mario Sanchez Prada <[email protected]> wrote: > Hi, > > So it seems WebKit2GTK+ builds are broken since yesterday due to this commit > (as it was already predicted by EWS in [1]): > http://trac.webkit.org/changeset/140285 > > ... and it seems to me it’s not something easily fixable since it will > certainly require a certain amount of work (and maybe a certain amount of > re-design too) to get it back, as the WebKitWebResource API (as well as > certain parts in WebKitWebView API) did benefit of both WKResourceLoadClient > and WebResourceLoadClient. > > I’ve checked the related bug [1], but still haven’t been able to properly > understand what’s exactly the reason of this change and, more importantly, > what could be the best way to sort this out in the GTK port (an alternative > implementation using the Injected Bundle perhaps?). > > If anyone could drop some light on this issue or provide some pointers to > better understand the motivation of this change, I’d really appreciate that. > I understand rolling r140285 might be not the best option at this point, yet > I’d personally rather not keep the WebKit2GTK+ broken for too long. > > Thanks, > Mario > > [1] https://bugs.webkit.org/show_bug.cgi?id=107405 > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
