On Sep 16, 2009, at 10:47 PM, Darin Fisher wrote:
By the way, to be clear these ads aren't on the critical path for
link clicks. A navigation occurs, and the ad just observes unload.
During unload it presumably tries to send home some data (ad
impression time, perhaps?). I'm not sure how a redirect could be
used to report such information.
<a ping> is a useful tool nonetheless because you could dynamically
create one, and dispatch a click event to it.
OK, so it sounds like what these sites (or ad networks) want is
departure auditing, not hyperlink auditing. It sounds to me like
guaranteeing completion of I/O started in unload (without blocking the
next page load) would be a better solution for this than <a ping>.
Here's why:
1) What these sites want to do is not actually hyperlink auditing, so
why make them use a strange workaround? Their desired outcome seems
totally unrelated to the normal use of <a ping>.
2) Dispatching a click event manually to an <a> element is way more
awkward than other ways of doing this, compare the following to the
trivial new Image() one-liner:
var link = document.createElement("a");
link.href = "http://example.com/";;
link.ping = "http://ping-site.com";;
var evt = document.createEvent("MouseEvent");
evt.initMouseEvent("click", true, true, window, 1, 0, 0, 0, 0,
false, false, false, false, 0, null);
link.dispatchEvent(evt);
3) Dispatching a click event to a manually created link link from an
unload handler has weird and inconsistent results in current browsers:
a) Dispatching a click event as outlined above works in Safari
and Opera, but not in Firefox (even outside unload).
b) Dispatching a click event as above in the unload handler
crashes current Safari (oops! will file bug), actuates the hidden link
in Opera resulting in navigation to yahoo.com, and does nothing in
Firefox.
4) Per HTML5, clicking on an <a> element without an href does nothing,
and activating a link with an href always actually follows the link,
with no exception for the unload handler. Synthetic clicks are allowed
to work, except in the case of frame targetting. So if all browsers
did everything per spec, you couldn't use the "manually create <a
ping>" trick without redirecting the navigation. As far as I can tell,
per HTML5 there is no circumstance in which the ping is issued without
also actuating a navigation.
The combination of these factors makes me think that <a ping> will not
address the problem, and we should guarantee completion for I/O
started in unload. The advantage is that if sites start the I/O before
doing a busy loop, it will still work, so they'll have no incentive to
start a busy loop arms race.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
