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

[Thiago Marcos P. Santos]

On Mon, Jan 21, 2013 at 4:32 PM, Claudio Saavedra <csaavedra at igalia.com> wrote:
> On Mon, 2013-01-21 at 15:27 +0100, Xan Lopez wrote:
>> On Mon, Jan 21, 2013 at 2:53 PM, Mario Sanchez Prada
>> <mario.prada at samsung.com> wrote:
>> > Hi,
>> >
>>
>> (...)
>>
>> >
>> > 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.
>>
>> As has been discussed in the list (see
>> http://lists.webkit.org/pipermail/webkit-dev/2013-January/023255.html)
>> the new development model for WebKit2 basically means this can happen
>> at any time, and the broken pieces are for each port to keep and put
>> back together. So I doubt reverting the patch is an option (in fact
>> this is essentially the intended result of the new policy), we just
>> need to figure out how to deal with this as fast as we can (which I
>> think will be "too long" by any reasonably standard, but such is
>> life).
>
> For the time being it looks to me that the only sensible thing to do is
> to just remove the WK2 API so that the port builds and then find a way
> to provide a replacement. Not an elegant solution but this is the brave
> new world we live in!
>

The solution for the EFL port was to remove the dead bits - including
one of our public APIs - and also skip some unit tests. Probably the
same idea applies for the GTK port + move the code that depends on
WKPageResourceLoadClient to a injected bundle.

Br,