electron/atom/browser/native_browser_view_mac.mm

217 lines
6.5 KiB
Text
Raw Normal View History

Implement initial, experimental BrowserView API Right now, `<webview>` is the only way to embed additional content in a `BrowserWindow`. Unfortunately `<webview>` suffers from a [number of problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20). To make matters worse, many of these are upstream Chromium bugs instead of Electron-specific bugs. For us at [Figma](https://www.figma.com), the main issue is very slow performance. Despite the upstream improvements to `<webview>` through the OOPIF work, it is probable that there will continue to be `<webview>`-specific bugs in the future. Therefore, this introduces a `<webview>` alternative to called `BrowserView`, which... - is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will likely also be bugs in `BrowserWindow` web contents) - is instantiated in the main process like `BrowserWindow` (and unlike `<webview>`, which lives in the DOM of a `BrowserWindow` web contents) - needs to be added to a `BrowserWindow` to display something on the screen This implements the most basic API. The API is expected to evolve and change in the near future and has consequently been marked as experimental. Please do not use this API in production unless you are prepared to deal with breaking changes. In the future, we will want to change the API to support multiple `BrowserView`s per window. We will also want to consider z-ordering auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
// Copyright (c) 2017 GitHub, Inc.
// Use of this source code is governed by the MIT license that can be
// found in the LICENSE file.
#include "atom/browser/native_browser_view_mac.h"
#include "brightray/browser/inspectable_web_contents_view.h"
#include "skia/ext/skia_utils_mac.h"
#include "ui/gfx/geometry/rect.h"
// Match view::Views behavior where the view sticks to the top-left origin.
const NSAutoresizingMaskOptions kDefaultAutoResizingMask =
NSViewMaxXMargin | NSViewMinYMargin;
@interface DragRegionView : NSView
@property (assign) NSPoint initialLocation;
@end
2017-08-23 23:10:31 +00:00
@interface NSWindow ()
- (void)performWindowDragWithEvent:(NSEvent *)event;
@end
@implementation DragRegionView
- (BOOL)mouseDownCanMoveWindow
{
return NO;
}
2017-08-09 21:49:11 +00:00
- (NSView *)hitTest:(NSPoint)aPoint
{
// Pass-through events that don't hit one of the exclusion zones
for (NSView *exlusion_zones in [self subviews]) {
if ([exlusion_zones hitTest:aPoint])
return nil;
}
return self;
}
- (void)mouseDown:(NSEvent *)event
{
2017-08-22 18:14:21 +00:00
if ([self.window respondsToSelector:@selector(performWindowDragWithEvent)]) {
[self.window performWindowDragWithEvent:event];
return;
}
if (self.window.styleMask & NSFullScreenWindowMask) {
2017-09-26 22:03:44 +00:00
return;
}
self.initialLocation = [event locationInWindow];
}
- (void)mouseDragged:(NSEvent *)theEvent
{
2017-08-22 18:14:21 +00:00
if ([self.window respondsToSelector:@selector(performWindowDragWithEvent)]) {
return;
}
2017-09-26 22:03:44 +00:00
if (self.window.styleMask & NSFullScreenWindowMask) {
2017-09-26 22:03:44 +00:00
return;
}
2017-08-15 23:13:14 +00:00
NSPoint currentLocation = [NSEvent mouseLocation];
NSPoint newOrigin;
NSRect screenFrame = [[NSScreen mainScreen] frame];
NSRect windowFrame = [self.window frame];
newOrigin.x = currentLocation.x - self.initialLocation.x;
newOrigin.y = currentLocation.y - self.initialLocation.y;
// Don't let window get dragged up under the menu bar
2017-08-15 23:13:14 +00:00
if ((newOrigin.y + windowFrame.size.height) > (screenFrame.origin.y + screenFrame.size.height)) {
2017-08-10 16:38:01 +00:00
newOrigin.y = screenFrame.origin.y + (screenFrame.size.height - windowFrame.size.height);
}
// Move the window to the new location
[self.window setFrameOrigin:newOrigin];
}
// Debugging tips:
2017-08-09 21:49:11 +00:00
// Uncomment the following four lines to color DragRegionView bright red
2017-08-15 23:13:14 +00:00
// #ifdef DEBUG_DRAG_REGIONS
2017-08-09 21:49:11 +00:00
// - (void)drawRect:(NSRect)aRect
// {
// [[NSColor redColor] set];
// NSRectFill([self bounds]);
// }
2017-08-15 23:13:14 +00:00
// #endif
2017-08-09 21:49:11 +00:00
@end
@interface ExcludeDragRegionView : NSView
@end
@implementation ExcludeDragRegionView
- (BOOL)mouseDownCanMoveWindow {
return NO;
}
2017-08-09 21:49:11 +00:00
// Debugging tips:
// Uncomment the following four lines to color ExcludeDragRegionView bright red
2017-08-15 23:13:14 +00:00
// #ifdef DEBUG_DRAG_REGIONS
2017-08-09 21:49:11 +00:00
// - (void)drawRect:(NSRect)aRect
// {
// [[NSColor greenColor] set];
// NSRectFill([self bounds]);
// }
2017-08-15 23:13:14 +00:00
// #endif
2017-08-09 21:49:11 +00:00
@end
Implement initial, experimental BrowserView API Right now, `<webview>` is the only way to embed additional content in a `BrowserWindow`. Unfortunately `<webview>` suffers from a [number of problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20). To make matters worse, many of these are upstream Chromium bugs instead of Electron-specific bugs. For us at [Figma](https://www.figma.com), the main issue is very slow performance. Despite the upstream improvements to `<webview>` through the OOPIF work, it is probable that there will continue to be `<webview>`-specific bugs in the future. Therefore, this introduces a `<webview>` alternative to called `BrowserView`, which... - is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will likely also be bugs in `BrowserWindow` web contents) - is instantiated in the main process like `BrowserWindow` (and unlike `<webview>`, which lives in the DOM of a `BrowserWindow` web contents) - needs to be added to a `BrowserWindow` to display something on the screen This implements the most basic API. The API is expected to evolve and change in the near future and has consequently been marked as experimental. Please do not use this API in production unless you are prepared to deal with breaking changes. In the future, we will want to change the API to support multiple `BrowserView`s per window. We will also want to consider z-ordering auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
namespace atom {
NativeBrowserViewMac::NativeBrowserViewMac(
brightray::InspectableWebContentsView* web_contents_view)
: NativeBrowserView(web_contents_view) {
auto* view = GetInspectableWebContentsView()->GetNativeView();
view.autoresizingMask = kDefaultAutoResizingMask;
}
Implement initial, experimental BrowserView API Right now, `<webview>` is the only way to embed additional content in a `BrowserWindow`. Unfortunately `<webview>` suffers from a [number of problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20). To make matters worse, many of these are upstream Chromium bugs instead of Electron-specific bugs. For us at [Figma](https://www.figma.com), the main issue is very slow performance. Despite the upstream improvements to `<webview>` through the OOPIF work, it is probable that there will continue to be `<webview>`-specific bugs in the future. Therefore, this introduces a `<webview>` alternative to called `BrowserView`, which... - is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will likely also be bugs in `BrowserWindow` web contents) - is instantiated in the main process like `BrowserWindow` (and unlike `<webview>`, which lives in the DOM of a `BrowserWindow` web contents) - needs to be added to a `BrowserWindow` to display something on the screen This implements the most basic API. The API is expected to evolve and change in the near future and has consequently been marked as experimental. Please do not use this API in production unless you are prepared to deal with breaking changes. In the future, we will want to change the API to support multiple `BrowserView`s per window. We will also want to consider z-ordering auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
NativeBrowserViewMac::~NativeBrowserViewMac() {}
void NativeBrowserViewMac::SetAutoResizeFlags(uint8_t flags) {
NSAutoresizingMaskOptions autoresizing_mask = kDefaultAutoResizingMask;
if (flags & kAutoResizeWidth) {
autoresizing_mask |= NSViewWidthSizable;
}
if (flags & kAutoResizeHeight) {
autoresizing_mask |= NSViewHeightSizable;
}
auto* view = GetInspectableWebContentsView()->GetNativeView();
view.autoresizingMask = autoresizing_mask;
}
Implement initial, experimental BrowserView API Right now, `<webview>` is the only way to embed additional content in a `BrowserWindow`. Unfortunately `<webview>` suffers from a [number of problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20). To make matters worse, many of these are upstream Chromium bugs instead of Electron-specific bugs. For us at [Figma](https://www.figma.com), the main issue is very slow performance. Despite the upstream improvements to `<webview>` through the OOPIF work, it is probable that there will continue to be `<webview>`-specific bugs in the future. Therefore, this introduces a `<webview>` alternative to called `BrowserView`, which... - is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will likely also be bugs in `BrowserWindow` web contents) - is instantiated in the main process like `BrowserWindow` (and unlike `<webview>`, which lives in the DOM of a `BrowserWindow` web contents) - needs to be added to a `BrowserWindow` to display something on the screen This implements the most basic API. The API is expected to evolve and change in the near future and has consequently been marked as experimental. Please do not use this API in production unless you are prepared to deal with breaking changes. In the future, we will want to change the API to support multiple `BrowserView`s per window. We will also want to consider z-ordering auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
void NativeBrowserViewMac::SetBounds(const gfx::Rect& bounds) {
auto* view = GetInspectableWebContentsView()->GetNativeView();
auto* superview = view.superview;
const auto superview_height = superview ? superview.frame.size.height : 0;
view.frame =
NSMakeRect(bounds.x(), superview_height - bounds.y() - bounds.height(),
bounds.width(), bounds.height());
}
void NativeBrowserViewMac::SetBackgroundColor(SkColor color) {
auto* view = GetInspectableWebContentsView()->GetNativeView();
view.wantsLayer = YES;
view.layer.backgroundColor = skia::CGColorCreateFromSkColor(color);
}
void NativeBrowserViewMac::UpdateDraggableRegions(
2017-08-15 23:13:14 +00:00
const std::vector<gfx::Rect>& system_drag_exclude_areas) {
NSView* webView = GetInspectableWebContentsView()->GetNativeView();
2017-08-10 14:58:39 +00:00
NSInteger superViewHeight = NSHeight([webView.superview bounds]);
NSInteger webViewHeight = NSHeight([webView bounds]);
2017-08-09 21:49:11 +00:00
NSInteger webViewWidth = NSWidth([webView bounds]);
2017-08-10 14:58:39 +00:00
NSInteger webViewX = NSMinX([webView frame]);
NSInteger webViewY = 0;
// Apple's NSViews have their coordinate system originate at the bottom left,
// meaning that we need to be a bit smarter when it comes to calculating our
// current top offset
if (webViewHeight > superViewHeight) {
webViewY = std::abs(webViewHeight - superViewHeight - (std::abs(NSMinY([webView frame]))));
} else {
webViewY = superViewHeight - NSMaxY([webView frame]);
}
// Remove all DraggableRegionViews that are added last time.
// Note that [webView subviews] returns the view's mutable internal array and
// it should be copied to avoid mutating the original array while enumerating
// it.
base::scoped_nsobject<NSArray> subviews([[webView subviews] copy]);
for (NSView* subview in subviews.get())
if ([subview isKindOfClass:[DragRegionView class]])
[subview removeFromSuperview];
2017-08-09 21:49:11 +00:00
// Create one giant NSView that is draggable.
base::scoped_nsobject<NSView> dragRegion(
[[DragRegionView alloc] initWithFrame:NSZeroRect]);
2017-08-09 21:49:11 +00:00
[dragRegion setFrame:NSMakeRect(0,
0,
webViewWidth,
webViewHeight)];
// Then, on top of that, add "exclusion zones"
2017-08-15 23:13:14 +00:00
for (auto iter = system_drag_exclude_areas.begin();
2017-08-09 21:49:11 +00:00
iter != system_drag_exclude_areas.end();
++iter) {
base::scoped_nsobject<NSView> controlRegion(
[[ExcludeDragRegionView alloc] initWithFrame:NSZeroRect]);
2017-08-10 14:58:39 +00:00
[controlRegion setFrame:NSMakeRect(iter->x() - webViewX,
webViewHeight - iter->bottom() + webViewY,
2017-08-09 21:49:11 +00:00
iter->width(),
iter->height())];
[dragRegion addSubview:controlRegion];
}
2017-08-09 21:49:11 +00:00
// Add the DragRegion to the WebView
[webView addSubview:dragRegion];
}
Implement initial, experimental BrowserView API Right now, `<webview>` is the only way to embed additional content in a `BrowserWindow`. Unfortunately `<webview>` suffers from a [number of problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20). To make matters worse, many of these are upstream Chromium bugs instead of Electron-specific bugs. For us at [Figma](https://www.figma.com), the main issue is very slow performance. Despite the upstream improvements to `<webview>` through the OOPIF work, it is probable that there will continue to be `<webview>`-specific bugs in the future. Therefore, this introduces a `<webview>` alternative to called `BrowserView`, which... - is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will likely also be bugs in `BrowserWindow` web contents) - is instantiated in the main process like `BrowserWindow` (and unlike `<webview>`, which lives in the DOM of a `BrowserWindow` web contents) - needs to be added to a `BrowserWindow` to display something on the screen This implements the most basic API. The API is expected to evolve and change in the near future and has consequently been marked as experimental. Please do not use this API in production unless you are prepared to deal with breaking changes. In the future, we will want to change the API to support multiple `BrowserView`s per window. We will also want to consider z-ordering auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
// static
NativeBrowserView* NativeBrowserView::Create(
brightray::InspectableWebContentsView* web_contents_view) {
return new NativeBrowserViewMac(web_contents_view);
}
} // namespace atom