Bug 1576113 - Add a comment.
authorMarkus Stange <mstange@themasta.com>
Sat, 24 Aug 2019 13:45:07 -0400
changeset 489764 0bc07ad7cfad0be286f4ccdad78c84094ec65177
parent 489763 2093b28e6aa976e6e559217dcd45bf865aa5e7be
child 489765 1125aad05d5c39c2453c04ca6d037afaef16c296
child 489779 bf126cb4b08f1bfa4bd0c17bff0e1c27bea2a529
push id36482
push userdluca@mozilla.com
push dateSat, 24 Aug 2019 21:52:09 +0000
treeherdermozilla-central@1125aad05d5c [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
bugs1576113
milestone70.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1576113 - Add a comment. MANUAL PUSH: Backout and comment change that don't require a review and are somewhat time-critical: the backout fixes breakage in some local build scenarios.
widget/cocoa/nsCocoaWindow.mm
--- a/widget/cocoa/nsCocoaWindow.mm
+++ b/widget/cocoa/nsCocoaWindow.mm
@@ -2744,22 +2744,35 @@ static NSMutableSet* gSwizzledFrameViewC
                                 @selector(FrameView__closeButtonOrigin));
     }
     IMP _fullScreenButtonOrigin =
         class_getMethodImplementation(frameViewClass, @selector(_fullScreenButtonOrigin));
     if (_fullScreenButtonOrigin && _fullScreenButtonOrigin != our_fullScreenButtonOrigin) {
       nsToolkit::SwizzleMethods(frameViewClass, @selector(_fullScreenButtonOrigin),
                                 @selector(FrameView__fullScreenButtonOrigin));
     }
+    // Override the _wantsFloatingTitlebar method to return NO, because it works around multiple
+    // problems:
+    // When we're not using CoreAnimation, the "floating titlebar" overlaps in a glitchy way with
+    // the NSOpenGLContext when we're drawing in the titlebar. These glitches do not happen when we
+    // use CoreAnimation.
+    // An additional problem appears in builds that link against the 10.14 SDK: In windows where
+    // _wantsFloatingTitlebar returns YES, the root NSView contains an additional view that provides
+    // a window background. This confuses our setContentView override which will place the content
+    // view *below* that background view, effectively hiding the content view completely.
+    // The floating titlebar view also slightly clips the bottom of the window buttons which we
+    // forcefully move down with our override of _closeButtonOrigin.
+    // See bug 1576391 for the removal of the _wantsFloatingTitlebar override.
     IMP _wantsFloatingTitlebar =
         class_getMethodImplementation(frameViewClass, @selector(_wantsFloatingTitlebar));
     if (_wantsFloatingTitlebar && _wantsFloatingTitlebar != our_wantsFloatingTitlebar) {
       nsToolkit::SwizzleMethods(frameViewClass, @selector(_wantsFloatingTitlebar),
                                 @selector(FrameView__wantsFloatingTitlebar));
     }
+
     [gSwizzledFrameViewClasses addObject:frameViewClass];
   }
 
   return frameViewClass;
 }
 
 - (id)initWithContentRect:(NSRect)aContentRect
                 styleMask:(NSUInteger)aStyle