MacViews triage: this is important; let's fix it for M-67 before we start canarying this.

FYI: The fix I put up for  issue 775984  seems to also fix this.

Thank you ellyjones@.

Pls see https://bugs.chromium.org/p/chromium/issues/detail?id=775984#c7.

I confirmed that <https://chromium-review.googlesource.com/980701> also fixes this issue.

It looks like this may not be quite the right fix — with this change, it's possible to drag the window from controls like the window buttons, *and* the control gets activated when you let go after a drag. Reopening.

** Bulk Edit **

There are only two M67 dev releases left on 04/03 & 04/10 before M67 branch on 04/12. Please try to land the fix ASAP to trunk so we can move forward with 50%-50% experiment on M67 Canary/Dev (if possible at all). Thank you.

** Bulk Edit **

There is only one dev release left 04/10 before M67 branch on 04/12. Please try to land the fix ASAP to trunk so we can move forward with 50%-50% experiment on M67 Canary/Dev (if possible at all). Thank you.

FYI: Change/Fix has to be landed in trunk latest by 4:00 PM PT, Friday (04/06) so we can pick it up for next week dev release. 

 Issue 828059  has been merged into this issue.

sdy@, any progress here? Thank you.

Hi govind@, yes, a CL is in review:

https://chromium-review.googlesource.com/c/chromium/src/+/1000212

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/91ee9c23182a6f91b45da5540ace7e80462045c0

commit 91ee9c23182a6f91b45da5540ace7e80462045c0
Author: Sidney San Martín <sdy@chromium.org>
Date: Wed Apr 11 06:54:49 2018

[MacViews] Fix browser windows dragging unexpectedly, especially when trying to drag tabs.

There are two paths which lead to dragging a Mac app's window around:

- The slow path is initiated by the app: some hit testing happens on mouse
  down, and something (most often the frame view) calls `[self.window
  performWindowDragWithEvent:theEvent]` to start server-side dragging.

- The fast path involves the window submitting a map of draggable regions to
  the window server. A `mouseDown:` in those regions starts a drag without
  waiting for the app.

AppKit uses both: it traverses the view hierarchy and reads the
`mouseDownCanMoveWindow` property of each view (which defaults to NO if the
view `isOpaque` and YES otherwise), and submits a map based on the views'
frames. However, a view may still override `-hitTest:` to punt some events
(say, if it's not rectangular, like a Chrome tab). If the title bar gets the
event, it starts a drag on the slow path. This means that, if an app is hung,
dragging still works, you just can't start drags from the transparent parts of
non-rectangular views.

One more complication: views that underlap the title bar in a window with a
full size content view, even if the title bar is hidden, only cut a hole in the
drag map if they override `-mouseDown:` *and* return YES for
`acceptsFirstResponder`. That was an issue because `BridgedContentView` returns
YES only if it's already first responder, so dragging was unpredictable.

This change:

- …makes BridgedContentView return nil when `-hitTest:` is passed a spot that
  should be draggable. The event ends up at the frame view, which could result
  in a drag or in a double-click miniaturizing or zooming the window.

- …deals with the "one more complication" by overriding `-_copyDragRegion` in
  BrowserWindowFrame to return nil, which effectively opts the window out of
  the fast path.

- …adds a custom frame view class for frameless app windows which uses
  `-[NSWindow performWindowDragWithEvent:]` (and an old undocumented version on
  10.10) to start a drag on `mouseDown:`, because the
  `movableByWindowBackground` property on windows seems to only affect "fast
  path" dragging.

Bug:  823770 ,  826477 
Change-Id: I9b7d727776d45853d1160b4cec53baf678e70d93
Reviewed-on: https://chromium-review.googlesource.com/1000212
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549802}
[modify] https://crrev.com/91ee9c23182a6f91b45da5540ace7e80462045c0/chrome/browser/ui/views/apps/app_window_native_widget_mac.mm
[modify] https://crrev.com/91ee9c23182a6f91b45da5540ace7e80462045c0/chrome/browser/ui/views/apps/chrome_native_app_window_views_mac.h
[modify] https://crrev.com/91ee9c23182a6f91b45da5540ace7e80462045c0/chrome/browser/ui/views/apps/chrome_native_app_window_views_mac.mm
[modify] https://crrev.com/91ee9c23182a6f91b45da5540ace7e80462045c0/chrome/browser/ui/views/frame/browser_native_widget_window_mac.mm
[modify] https://crrev.com/91ee9c23182a6f91b45da5540ace7e80462045c0/chrome/browser/ui/views/frame/native_widget_mac_frameless_nswindow.mm
[modify] https://crrev.com/91ee9c23182a6f91b45da5540ace7e80462045c0/ui/views/cocoa/bridged_content_view.h
[modify] https://crrev.com/91ee9c23182a6f91b45da5540ace7e80462045c0/ui/views/cocoa/bridged_content_view.mm
[modify] https://crrev.com/91ee9c23182a6f91b45da5540ace7e80462045c0/ui/views/cocoa/bridged_native_widget.h
[modify] https://crrev.com/91ee9c23182a6f91b45da5540ace7e80462045c0/ui/views/cocoa/bridged_native_widget.mm
[modify] https://crrev.com/91ee9c23182a6f91b45da5540ace7e80462045c0/ui/views/cocoa/bridged_native_widget_interactive_uitest.mm
[modify] https://crrev.com/91ee9c23182a6f91b45da5540ace7e80462045c0/ui/views/cocoa/native_widget_mac_nswindow.mm

Can this be marked as fixed if nothing else is pending?

Able to reproduce this issue on Mac OS 10.12.6 on the build without fix 67.0.3381.0 and the issue is fixed on the latest Canary 67.0.3396.0 as per  issue 826477 .

By enabling #views-browser-windows flag, able to click on the maximize/minimize/close buttons and on clicking on the tabstripe, able to ex[and/shrink the window.
Attached is the screen cast for reference.

Hence adding TE verified labels as the fix is working as intended.

Thanks..

Deleted: 823770.mp4 2.6 MB

	823770.mp4 2.6 MB View Download

Thanks for verifying!