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

[bugzilla-daemon at webkit.org]

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


Martin Robinson <mrobinson at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrobinson at webkit.org




--- Comment #3 from Martin Robinson <mrobinson at webkit.org>  2011-09-20 06:56:49 PST ---
(In reply to comment #2)
> Created an attachment (id=107985)
 --> (https://bugs.webkit.org/attachment.cgi?id=107985&action=review) [details]
> New patch
> 
> - It still uses the glib/gio async pattern, but it removes the load progress callback
> - It adds load-progress-changed and load-status-changed signals to notify about the load progress. I'm using signals instead of properties in this case, because progress and load-status only make sense while the view is loading, so they are passed as parameters to the signal callbacks, but they are not saved and there's no API to get them.
> - It adds is-loading property.
> - It adds all API docs missing in previous patch.

I think the progress signal is a very friendly API and I'm not too bothered by the fact that network traffic may have ceased at any given time. I think it's sufficient to say something like "If the value of progress is 1.00, all network traffic for initial load of the page has ceased. Progress does not track the status of any asynchronous loading that happens on the page."

I don't really like the idea of the is-loading property, because the page may still be "loading" in a sense -- constructing the DOM, loading XHR, etc even after progress is 1. Progress really only tracks network traffic of the initial load. I think the API should be clear about that distinction.

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