[webkit-reviews] review requested: [Bug 42432] Enable Web Timing for GTK : [Attachment 84869] Patch 1: Implementation

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Mar 5 09:35:19 PST 2011


Zan Dobersek <zandobersek at gmail.com> has asked	for review:
Bug 42432: Enable Web Timing for GTK
https://bugs.webkit.org/show_bug.cgi?id=42432

Attachment 84869: Patch 1: Implementation
https://bugs.webkit.org/attachment.cgi?id=84869&action=review

------- Additional Comments from Zan Dobersek <zandobersek at gmail.com>
This patch brings (incomplete) support for the Navigation Timing specification
to the Gtk port.

I consider the support incomplete because the domain lookup times are not set.
Libsoup at this moment does not offer signals we could connect to in order to
get notified when domain lookup starts or ends. As/If they're added, the
implementation should be properly updated.

Another small hack this implementation utilizes is setting the connectEnd time
when we receive response. Dan Winship recommended on the libsoup mailing
list[1] this could be done by connecting to SoupConnection's notify::state
signal which is emitted when state of the connection changes. When state would
change from SOUP_CONNECTION_CONNECTING to any other it would mean that
connection has ended (successfully or unsuccessfully, it does not matter in
this case) and the connectEnd attribute should be assigned the current time.

This proved unusable when testing. Because the SoupConnection object is
'semi-private API' (and is on its way to be replaced by a more 'gio-oriented
API', explained in the message by Dan) there is no reasonable way to add the
SoupConnection to a ResourceHandle so we could disconnect signal handlers when
ResourceHandle is deleted. This was shown in testing by crashes when trying to
access ResourceLoadTiming object of the ResourceHandle's response. I'd like to
see this properly implemented when libsoup makes the change in the API, though.


[1] https://mail.gnome.org/archives/libsoup-list/2011-February/msg00004.html


More information about the webkit-reviews mailing list