Fix processing of mouse events on MacViews.

ui/views/cocoa/bridged_content_view.h

Index: ui/views/cocoa/bridged_content_view.h
diff --git a/ui/views/cocoa/bridged_content_view.h b/ui/views/cocoa/bridged_content_view.h
index f6952a25e80dd9c7a712cc9e24458632e715e6c1..2589451350f360555e6c0a01fa6e7db20ed91742 100644
--- a/ui/views/cocoa/bridged_content_view.h
+++ b/ui/views/cocoa/bridged_content_view.h
@@ -68,15 +68,14 @@ class View;
 // Clear the hosted view. For example, if it is about to be destroyed.
 - (void)clearView;
 
-// Process a mouse event captured while the widget had global mouse capture.
-- (void)processCapturedMouseEvent:(NSEvent*)theEvent;
-
 // Mac's version of views::corewm::TooltipController::UpdateIfRequired().
 // Updates the tooltip on the ToolTipBaseView if the text needs to change.
 // |locationInContent| is the position from the top left of the window's
 // contentRect (also this NSView's frame), as given by a ui::LocatedEvent.
 - (void)updateTooltipIfRequiredAt:(const gfx::Point&)locationInContent;
 
+- (void)hideTooltipIfRequired;
+

[Avi (use Gerrit), 2016/10/25 15:34:50]

This seems unrelated.

[snake, 2016/10/25 15:46:18]

On mouse exit, we should hide tooltip, in other case, it can be shown in
incorrect place (outside browser bounds), this is also related to processing
mouseexit event.

[tapted, 2016/10/26 00:57:00]

Is this related to http://crbug.com/592085 ? Perhaps the fix should be in
ToolTipBaseView instead, but it should be its own CL rather than being mixed in
here.

[snake, 2016/10/26 12:44:56]

No, this is not related. Because i have changed the logic of processing mouse
events, i should do additional call to hide tooltip. I other case it will be bug
(related to this CL). And as result i can not move this in separate CL.

(JFYI: But http://crbug.com/592085 may be fixed after this CL, because mouse
events are processed more correctly in it).

 // Update windowMask_ depending on the current view bounds.
 - (void)updateWindowMask;