[Bug]: Inconsistent window dragging behavior between BrowserWindow / BrowserView

[anulman]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Electron Version

13.1.7

What operating system are you using?

macOS

Operating System Version

macOS Big Sur 11.5.2

What arch are you using?

x64

Last Known Working Electron version

No response

Expected Behavior

Dragging a -webkit-app-region: drag area behaves differently if the WebContents are loaded in the BrowserWindow vs. a BrowserView. There are three noticeable differences; I expected both scenarios to work the way a BrowserWindow does, i.e.

• When you drag a draggable region between two monitors, a semi-transparent preview should show up on the "inactive" monitor
• When you click and drag a draggable region on a not-focused BrowserWindow, the window should reposition itself as expected
• When you're mid-drag and your mouse cursor "leaves" a draggable area, the window should smoothly catch up to the new mouse position

Actual Behavior

Here is a Loom demoing the difference between expected and actual behavior: https://www.loom.com/share/7d28722ac7bb4e1eb37aabc5bae53f8b

• When you drag a BrowserView's draggable region between two monitors, no semi-transparency effects occur and the window "snaps" to a newly-active monitor once activated
  • This is especially obvious when two monitors are positioned spatially above / below each other; dragging to the bottom window will snap aggressively such that the top of the window is beneath the "Apple menu bar" at the top of the screen.
• When you click and drag a BrowserView's draggable region when its containing window was not focused, it will activate the window and ignore the mouse drag
• When you're mid-drag with a BrowserView's draggable region and your mouse cursor "leaves" a draggable area, the window "stutters" to the new position, or sometimes even does not move to the new position at all.

Testcase Gist URL

https://gist.github.com/0a371fe58ff8c8b72287629ab6d76d34

Additional Information

No response

[anulman]

Wow @codebytere, thank you for the prompt response!

I was looking at your change, the surrounding file, and the NSWindow interface; I suspect this is all an artifact of the manual setFrameOrigin work done in the custom mouseDragged and mouseDown handlers.

Which lead me to "wild and crazy idea time": could we get rid of this entirely by changing the mouseDownCanMoveWindow implementation to something like:

- (BOOL)mouseDownCanMoveWindow {
  NSPoint point = [NSEvent mouseLocation];

  // Pass-through events that hit one of the exclusion zones
  for (NSView* exclusion_zones in [self subviews]) {
    if ([exclusion_zones hitTest:point])
      return NO;
  }

  return YES;
}

[codebytere]

@anulman ooh interesting idea!! i'll check it out 👀

[anulman]

@codebytere omg I think I've got it! Loom and PR #31114 incomingare now up. Very excited to contrib 😄

https://www.loom.com/share/3ab47d45a0be4223af88b3377a800cd9

[codebytere]

Closed in #31114