I've tried hard to find a solution for the clipped window button problem which
does not involve swizzling but could not find one.
The officially ratified ways of moving the window buttons are:
1. Use an NSToolbar in your window, or
2. Make a custom window with your own buttons.
I don't think having an NSToolbar is an option for us. And making our own window frame
implementation would be hard to get right and can easily behave differently from the
native implementation.
I've also tried asking the window to not render any window buttons on its own; then we
could make our own buttons and place them on top of our view. But if I change the
window's styleMask to be just NSTitledWindowMask, it doesn't only make the buttons
disappear, it also makes the window non-resizable. And if I include NSResizableWindowMask,
the buttons come back (only the zoom button is enabled, the other two are grayed out).
This change also stops overriding _wantsFloatingTitlebar when CoreAnimation is
enabled, which is necessary for the window buttons to render.
Depends on D43341
Differential Revision: https://phabricator.services.mozilla.com/D43361
--HG--
extra : moz-landing-system : lando
This gives us two behaviors for free which we were achieving through manual
overrides:
- The content view is sized to cover the entire window frame.
- The window controls are placed on top of the content view (instead of
underneath it in z-order).
It also forces CoreAnimation layers for the window's entire NSView hierarchy, so
we only use it when the CoreAnimation pref is enabled.
NSFullSizeContentViewWindowMask is only available on 10.10 and up, but we still
support 10.9, so we cannot remove the code with the manual overrides just yet.
This change also requires a change to NonDraggableView in order to preserve
window dragging behavior in the titlebar: When NSFullSizeContentViewWindowMask
is used, the method which assembles the window's draggable region takes a
different path. It treats the titlebar specially, and traverses the NSView
hierarchy twice, once for the titlebar area and once for the rest of the window.
Outside the titlebar, it calls _opaqueRect on every visible NSView, but for the
titlebar area, it calls _opaqueRectForWindowMoveWhenInTitlebar instead.
Overriding _opaqueRectForWindowMoveWhenInTitlebar allows us to achieve the old
dragging behavior.
Differential Revision: https://phabricator.services.mozilla.com/D43341
--HG--
extra : moz-landing-system : lando
This makes them only apply in windows with titlebars, which is the only place
where they're needed. The setContentView override can even cause harm for other
windows, such as sheet windows, because it'll move the content view below a
full-window covering solid grey view provided by the system, in builds that
link against the 10.14 SDK and don't override _wantsFloatingTitlebar.
Differential Revision: https://phabricator.services.mozilla.com/D43340
--HG--
extra : moz-landing-system : lando
This makes prefs definition simpler, more consistent, and less error-prone.
Differential Revision: https://phabricator.services.mozilla.com/D41145
--HG--
extra : moz-landing-system : lando
On platforms that don't use native layers for rendering, we usually want reftests
to see exactly what's going to end up in the window. It's conceivable that
rendering into offscreen framebuffers might miss bugs on those platforms (though
I'm not sure if we've seen any evidence of this).
But when we're rendering to native layers, we have non-default framebuffers either
way, so we might as well create our own framebuffer rather than asking a native
layer for one. We're not interested in getting this rendering to the screen, so
it's better to leave the native layer out of this.
Differential Revision: https://phabricator.services.mozilla.com/D42406
--HG--
extra : moz-landing-system : lando
This makes CompositorOGL always render into offscreen render targets.
CompositorOGL no longer expects the GLContext to have a default framebuffer.
This duplicates a bunch of code from GLContextCGL, but that code can be removed
from GLContextCGL once WebRender no longer needs it.
This also makes it so that we don't recreate render targets on every frame;
instead, we create one render target for every IOSurface in the native layer's
"swap chain" and cycle through those render targets. We only throw away the
render targets when the window is resized or closed.
Differential Revision: https://phabricator.services.mozilla.com/D42405
--HG--
extra : moz-landing-system : lando
It looks like a big patch but it's mostly just moved code, with some duplication:
- Layer creation and destruction moves to LayerManagerComposite and RendererOGL.
- BasicCompositor IOSurface setup code moves to BasicCompositor.cpp.
- OpenGL IOSurface setup code moves to CompositorOGL and RenderCompositorOGL.
The duplication is a bit unfortunate but the LayerManagerComposite code will
diverge from the WebRender code soon.
BeginFrame gets a new argument aNativeLayer. This argument will go away again
over the course of this patch queue. But for now, BeginFrame is the best place
to do the layer setup because it's a very close place to PreRender which is
where that code was previously.
I wasn't able to think of a nice way to give CompositorOGL and BasicCompositor
platform-specific behavior without #ifdefs. So now LayerManagerComposite uses
the "cross-platform" NativeLayer interface, but CompositorOGL and
BasicCompositor use NativeLayerCA because they actually need the IOSurface, and
they do that in #ifdef'd code.
Luckily, NativeLayerCA.h can be included in both .cpp files and in .mm files.
Differential Revision: https://phabricator.services.mozilla.com/D42402
--HG--
extra : moz-landing-system : lando
This lets LayerManagerComposite and RendererOGL set the correct opaque region
on the native layer.
Differential Revision: https://phabricator.services.mozilla.com/D42401
--HG--
extra : moz-landing-system : lando
This patch adds support for quota cache invalidation if the profile is loaded in different builds.
Differential Revision: https://phabricator.services.mozilla.com/D39673
--HG--
extra : moz-landing-system : lando
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.
--HG--
extra : rebase_source : 5230000ce88395794c272f0133e09979c70d526d
extra : amend_source : df014e518d27480c5b149acb8acaa0433565d483
The source of the trouble is our setContents override, which makes sure the window's
content view is the bottommost view in the window, and its interaction with a change
in behavior on 10.14, where windows that return YES from _wantsFloatingTitlebar will
contain an additional NSView for the window background. Our setContents override
moves the content view behind that window background view, which covers it with a
solid gray color.
--HG--
extra : amend_source : cd11d5c805de7054c3dfa3a1d5ae0f504f07116d
We need this change so that the newly-built clang will have
C++17-compatible libstdc++ headers installed. I believe this change
also means that the newly-built clang (and associated tools) links
against GCC 7's libstdc++, but we set RPATH or similar appropriately, so
there shouldn't be issues stemming from that.
Differential Revision: https://phabricator.services.mozilla.com/D41251
--HG--
extra : moz-landing-system : lando
1. Unsticky connection from a transaction we disable SPDY on to restart
2. Call OnReadSegment from TLSFilterTransaction;FilterOutput to push written data out (renegotiation)
3. Break indefinite loop that may occur during renegotiation by propagating WOULD_BLOCK via mFilterReadCode
Differential Revision; https;\\phabricator.services.mozilla.com\D40409
Differential Revision: https://phabricator.services.mozilla.com/D42310
--HG--
extra : moz-landing-system : lando
