[webkit-dev] WebKit2GTK+ breakage due to removal of WKPageResourceLoadClient

[Carlos Garcia Campos]

El lun, 21-01-2013 a las 17:57 -0800, Sam Weinig escribió:
> 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.

Now that you guys can break other ports at any time, would it be
possible that those changes are announced in advance here so that we
have some time to prepare for the change? I don't mean all changes that
might break the build and are easy to fix, but changes like that one
that break the C API, remove functionality, etc. that require a lot of
work adapting to them.

> Going forward, if you need that kind of detailed knowledge, you should
> use the WebInspector or the protocol it is based on.

The GTK+ API depends on the WebResource API, so WebInspector is not a
solution, 14 unit test are timing out now that resources don't work at
all. We'll rework it using injected bundle, but I'm afraid the injected
bundle API could be removed too, are there any plans in that regard or
can we safely use the injected bundle API?

> -Sam
> 
> On Jan 21, 2013, at 5:53 AM, Mario Sanchez Prada <mario.prada at samsung.com> 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
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 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
> <mario.prada at samsung.com> 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
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3