Over to sdy@ for M67 - sdy@ owns some related bugs about handling of clicks on the tabstrip background.

** 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. 

sdy@, any progress here? Thank you.

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

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

Eep, hitting enter to accept autocompletions is a dangerous game.

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?

Verified the fix on Mac 10.13.1 using Chrome version #67.0.3396.0 as per the comment #0.
Attaching screen cast for reference.
Observed that window minimised upon double clicking background area of the Tabstrip.
Hence, the fix is working as expected. 
Adding the verified labels.
Note: Able to reproduce the issue on chrome version 67.0.3381.0

Thanks...!!

Deleted: 826477.mp4 3.0 MB

	826477.mp4 3.0 MB View Download

Thanks for verifying!

 Issue 712277  has been merged into this issue.