MacViews: Fix sending mouse exit event and releasing capture on D&D.

ui/base/cocoa/base_view.h

Index: ui/base/cocoa/base_view.h
diff --git a/ui/base/cocoa/base_view.h b/ui/base/cocoa/base_view.h
index 0675caeae632e96c577ef8b17c98af441be57355..ef3ca4839f44ec55f5925905dcb3711f85e7c59b 100644
--- a/ui/base/cocoa/base_view.h
+++ b/ui/base/cocoa/base_view.h
@@ -27,8 +27,6 @@ UI_BASE_EXPORT
 
  @private
   ui::ScopedCrTrackingArea trackingArea_;
-  BOOL dragging_;
-  base::scoped_nsobject<NSEvent> pendingExitEvent_;

[tapted, 2016/09/19 00:31:01]

spqchan is right - we can't change BaseView -- too much other stuff relies on
it, and it's unlikely there is good test coverage for the UI interactions.

Can you explain why it's necessary to remove the `pendingExitEvent_` logic in
order to fix the bug?

Then, if pendingExitEvent_ really is useless for any situation involving
BridgedContentView, then it can be disabled via overriding. E.g.

 - Add a method `handleMouseEvent` which switches on [event type] and does the
updates of dragging_ and pendingExitEvent_ all in the one method
 - Change all the BaseView [foo]MouseBar methods to call handleMouseEvent
instead of mouseEvent
 - override handleMouseEvent in BridgedContentView to just call mouseEvent so
the logic is skipped.

[snake, 2016/09/20 15:04:26]

was
I can not repro case on http://crbug.com/33100, because TestCase.swf is not
correctly opened by current flash version.
I did try reproduce this, using other plugin (Chromium PDF plugin and Yandex PDF
plugin).
in
1) Currently In MacViews on any click the MouseUp event are delivered to
BridgedContentView::processCapturedMouseEvent: , not to BaseView::MouseUp:. This
happens, beacause on MouseDown we call native_widget_->SetCapture(); in
views::Widget::OnMouseEvent, and after that all messages are delivered using
other way.

2) When we create new NSWindow while processing MouseDown (menu for example),
the MouseUp is never received.

3) When we start D&D using NSView::beginDraggingSession[with item]: , the
MouseUp event will be processed by system, and we receive only
NSView::performDragOperation: . 
the
so
Should I create separate CL for changes in base_view.* ?

[tapted, 2016/09/21 10:07:05]

So a possible alternative fix may be to generate a synthetic mouseUp event
that's sent once the dragging session ends. That may even be "nicer", if it
gives views::Views a way to tidy up their state. But if that doesn't happen on
Aura, then it's not likely that Views are expecting that. Also it's more
complicated. So let's go with this.
Hm, I guess there's not much left after removing the unnecessary code - let's
leave it.

   NSInteger pressureEventStage_;
 }