mac: Add support for asynchronous dictionary lookup

content/browser/renderer_host/render_widget_host_view_mac.mm

Index: content/browser/renderer_host/render_widget_host_view_mac.mm
diff --git a/content/browser/renderer_host/render_widget_host_view_mac.mm b/content/browser/renderer_host/render_widget_host_view_mac.mm
index f37a73fc85697e2a4611f723149f50f158701467..14b6a3bbc6e00ff672b803d3a6ed50b070c65061 100644
--- a/content/browser/renderer_host/render_widget_host_view_mac.mm
+++ b/content/browser/renderer_host/render_widget_host_view_mac.mm
@@ -2799,6 +2799,22 @@ void RenderWidgetHostViewMac::SendPendingSwapAck() {
   [responderDelegate_ touchesEndedWithEvent:event];
 }
 
+- (void)quickLookWithEvent:(NSEvent*)event {

[Avi (use Gerrit), 2014/03/12 04:55:40]

Can you note that this only will be invoked for >= 10.8?

[Andre, 2014/03/12 16:59:26]

Done.

+  NSPoint point = [self convertPoint:[event locationInWindow] fromView:nil];
+  TextInputClientMac::GetInstance()->GetStringAtPoint(
+      renderWidgetHostView_->render_widget_host_,
+      gfx::Point(point.x, NSHeight([self frame]) - point.y),
+      ^(NSAttributedString* string, NSPoint baselinePoint) {

[eseidel, 2014/03/12 04:48:36]

Woh, crazy.  Maybe things have changed, but I recalled one of the projects I
worked on banning block-functions similar to these because they required your
executable pages to be loaded as writeable (since they captured locals) which
was a security concern.  Maybe that wasn't Chromium, or maybe that wasn't this
particular block syntax.  Maybe it was probably SyncServices back at Apple... 
It's been a long time since I've written Obj-C professionally.

Then again, I'm probably remembering some ancient, retired block syntax which is
no longer used. :)

[Avi (use Gerrit), 2014/03/12 04:58:20]

I will be kind and attribute this to your weird historical experiences rather
than some particularly potent stuff. Blocks most certainly play well with W^X,
and we use them all over the place.

+          if (string && [string length] > 0) {

[Avi (use Gerrit), 2014/03/12 04:55:40]

Technically speaking you don't need to check string. If string were to be nil,
sending a message to it would result in a 0 return, disqualifying it on the
second condition here.

[Andre, 2014/03/12 16:59:26]

True, but my thinking was the extra check makes it clear to the reader that
string can be nil. Reduces the potential of wrong assumptions in future code
changes.
Also, I'm less comfortable relying on the return value of messaging nil when
it's
not an object type, such as comparing it to another integer.
But I don't mind changing it if you want.

[Avi (use Gerrit), 2014/03/12 17:10:54]

Please leave it alone. I don't mind redundancy in this way.

+            dispatch_async(dispatch_get_main_queue(), ^{

[Avi (use Gerrit), 2014/03/12 04:55:40]

Why the dispatch on the main thread? Are we really not guaranteed to get called
back already on the main thread? I commented in the api asking for explicit
documentation about that.

[Andre, 2014/03/12 16:59:26]

The callback happens on the IO/IPC thread.
I will document the api accordingly.

+                [self showDefinitionForAttributedString:string
+                                                atPoint:baselinePoint];
+            });
+          }
+      }
+  );
+}
+
 // This method handles 2 different types of hardware events.
 // (Apple does not distinguish between them).
 //  a. Scrolling the middle wheel of a mouse.