[Webkit-unassigned] [Bug 68085] [GTK] Loader client implementation for WebKit2 GTK+ API

Mon Sep 26 06:19:15 PDT 2011

https://bugs.webkit.org/show_bug.cgi?id=68085

--- Comment #19 from Carlos Garcia Campos <cgarcia at igalia.com>  2011-09-26 06:19:15 PST ---
(In reply to comment #18)
> Sorry, I didn't realize they were two different options, but yeah, I guess this one looks simpler and better overall.

No problem.

> (In reply to comment #17)

> > I'm not sure I understand what you mean, it says that you need to handle the signal to provide your own error page. Do you mean it can be used to not show any error page at all?
> 
> Yes, I mean can it be used to just not touch the page that is being shown? Since this is a provisional failure, you haven't committed yet, so you can remain at the already loaded page, right?

Yes, ou can just connect to the signal and simply return TRUE. Note that default behaviour is not implemented yet.

> > Do you mean adding a new signal in addition to the current ones or replace finished and failed signals by a single finished signal?
> 
> Not sure what's the best way, but I think the idea of simplifying detecting that the load has finished one way or another would be welcome. Maybe we should finished at the end regardless of whether it failed or not, then you can query the failure and final state from the loader client, what do you think? Adding a new signal sounds OK too.

I'm not sure, I think Martin wanted to map all callbacks to signals to give more control to the user over the loading process. With the previous patch it was more natural to have a single finish point, because it's how gio async pattern works.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.