1856452 - When building with the macOS 14 SDK, windows cannot be moved on macOS 14

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, task, P3)

Description

[Markus Stange [:mstange]]

When building with the macOS 14 SDK, windows cannot be moved by dragging them. This only affects macOS 14 Sonoma.

This needs to be fixed before we can build Firefox with the macOS 14 SDK (bug 1855564).

See bug 1856296 for when we accidentally shipped this to Nightly.

Comment 1

[Markus Stange [:mstange]]

Copying over my comments from the other bug:

(In reply to Markus Stange [:mstange] from bug 1856296 comment #11)

We implement window dragging by setting up our NSView hierarchy in such a way that the NSViews in the back return YES from movableByWindowBackground, and then we place non-movable transparent NSViews in the non-movable regions of the window (they return NO from movableByWindowBackground). See here for more details.

We also have a hack here to avoid paints which might be causing problems and which might be unnecessary these days.

(In reply to Markus Stange [:mstange] from bug 1856296 comment #12)

When debugging this, I suggest the following approach: First, try to remove the call to ManipulateViewWithoutNeedingDisplay (just call mNonDraggableRegion.UpdateRegion directly). If that doesn't fix it, dump the NSView hierarchy starting at the window's border view ([[window contentView] superview]) along with each view's movableByWindowBackground property. There may also be a NSWindow styleMask flag that affects this behavior.

Comment 2

[Markus Stange [:mstange]]

The macOS 14 AppKit release notes mention a change to clipToBounds:

For applications linked against the macOS 14 SDK, the default value of this property is false. Apps linked against older SDKs default to true.

I wonder if there's a view in our view hierarchy which is not movableByWindowBackground which used to be clipped out and is now not clipped out any more and interferes with the dragging.

Comment 3

[Brad Werth [:bradwerth] | Out until Feb 2025]

This can be fixed very simply by setting clipToBounds on the NonDraggableViews we create in ViewRegion::UpdateRegion. That's not as satisfying as I would like, because it seems to imply that the problem is some kind of view added to one of the NonDraggableView objects, and I don't see where that could be done. I'll post the fix here and we'll discuss in review if we want to push for a better-understood solution.

Comment 4

[Brad Werth [:bradwerth] | Out until Feb 2025]

Or perhaps the container view only respects the bounds of its subviews if those subviews have clipToBounds set, as if it's checking their clip rather than their bounds.

Comment 5

[Brad Werth [:bradwerth] | Out until Feb 2025]

Attachment: Bug 1856452: Make NonDraggableView opaque region limited to its bounds.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7fc3469f6363
Make NonDraggableView opaque region limited to its bounds. r=mstange

Comment 7

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/7fc3469f6363