On Fri, Jan 27, 2012 at 5:56 AM, Carlos Garcia Campos <[email protected]> wrote: > That also made me think about how to expose HitTestResult in the API. In > WebKit1 it's only used by webkit_web_view_get_hit_test_result() (it > sounds like a getter, but it actually performs a hit test and returns > the result). In WK2 there's no API to make a hit test from the UI > process, and I'm not sure it's actually needed. However, I think a > HitTestResult object can be useful in the API, probably with a different > name WebKitWebElement or something like that. This could be passed as an > argument to the WebKitWebView::hovering-over-element signal, and it > could be used for the context menu API.
I think this is a good idea, but we should use a name that reflects the fact that it's not an actual DOM object. For instance HitTestResult or CursorTargetInformation or something like that. > We could use a similar approach than WK1 HitTestResult object, it has > flags to get information about the hoevered thing (whether it's a link, > or image, or text selected, whether the area is editable, etc.) and the > uri or the image, link or media. It also has the inner node, we can add > later once we have DOM bindings in WK2. I don't think we should count on being able to do DOM bindings in the UI process yet. It's a pretty big unsolved problem and it may be easier in the end to do them in the WebProcess. --Martin _______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
