[webkit-reviews] review denied: [Bug 5701] would like target name along with frame in element dictionary : [Attachment 4760] patch to add WebElementLinkTargetNameKey to elementAtPoint: dictionary

[bugzilla-request-daemon at opendarwin.org]

Darin Adler <darin at apple.com> has denied Terrence Talbot
<ttalbot at karelia.com>'s request for review:
Bug 5701: would like target name along with frame in element dictionary
http://bugzilla.opendarwin.org/show_bug.cgi?id=5701

Attachment 4760: patch to add WebElementLinkTargetNameKey to elementAtPoint:
dictionary
http://bugzilla.opendarwin.org/attachment.cgi?id=4760&action=edit

------- Additional Comments from Darin Adler <darin at apple.com>
Without this change, it's easy for a WebKit program to get the target frame
name. You can use WebElementDOMNodeKey to get a pointer to a DOMNode, then is
isKindOfClass to check if it's a DOMHTMLAnchorElement, then call the target
method.

So we have to be sure this is a worthwhile feaure. I think that a flag
indicating that the element will open in a new window *might* be worthwhile,
because it's probably unreasonable to expect clients to figure out what the
behavior is for the various special frame names.

A change to a public header requires API review at Apple. Because of this, new
features like this one need to start out in private headers, so it should be in
WebViewPrivate.h.

The new symbol does need to be added to the .exp file.

It would be slightly better to not autorelease the frame name -- we've been
learning that each autorelease costs, so a regular copy/release pair would be a
minor improvement even though it requires a local variable.