Re: [webkit-dev] WebKit2GTK+ breakage due to removal of WKPageResourceLoadClient
[Replying both Carlos and Sam's mail at once] Hi, > 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. Ok, I understand it better now. Thanks for the clarification. > 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. I agree with Carlos here. Even though there's a policy in place to drive the development of WebKit2 in an specific way from now on, I would find very interesting and useful that an announcement was made in webkit-dev whenever the breakage is going to be this severe. I don't mean having to announce it like weeks in advance, I guess 2-3 days before pushing the change might be good enough, to avoid at least situations like this one. > > 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. Yes, exactly. > 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? Good question, although I guess the InjectedBundle has more possibilities to survive since it's what some helper tools like WKTR use anyway, and because it doesn't cause any extra IPC after all. Thanks, Mario ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit2GTK+ breakage due to removal of WKPageResourceLoadClient
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 > 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@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 > 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@lists.webkit.org > > http://lists.webkit.org/mailman/listinfo/webkit-dev > > > ___ > webkit-dev mailing list > webkit-dev@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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/
Re: [webkit-dev] WebKit2GTK+ breakage due to removal of WKPageResourceLoadClient
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 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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit2GTK+ breakage due to removal of WKPageResourceLoadClient
On Mon, Jan 21, 2013 at 4:32 PM, Claudio Saavedra 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 >> 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, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit2GTK+ breakage due to removal of WKPageResourceLoadClient
On Mon, 2013-01-21 at 15:27 +0100, Xan Lopez wrote: > On Mon, Jan 21, 2013 at 2:53 PM, Mario Sanchez Prada > 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! Claudio ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit2GTK+ breakage due to removal of WKPageResourceLoadClient
On Mon, Jan 21, 2013 at 2:53 PM, Mario Sanchez Prada 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). Xan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] WebKit2GTK+ breakage due to removal of WKPageResourceLoadClient
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@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
