Commit graph

18 commits

Author SHA1 Message Date
Birunthan Mohanathas
42934a1006 Make BrowserView DragRegionViews children of the WebContents view
Previously they were children of the `InspectableWebContentsView` view,
which caused this assertion to fail:

f993888424/brightray/browser/mac/bry_inspectable_web_contents_view.mm (L162)
2018-03-19 20:45:40 +02:00
Birunthan Mohanathas
3b8ddd0997 Use NSView convertRect:toView: for BrowserView DragRegionView positioning 2018-03-19 20:44:05 +02:00
Birunthan Mohanathas
377e6c3210 Rename system_drag_exclude_areas => drag_exclude_rects 2018-03-19 20:44:05 +02:00
Birunthan Mohanathas
61160ff9e5 Store InspectableWebContents instead of InspectableWebContentsView in NativeBrowserView 2018-03-19 20:44:05 +02:00
Felix Rieseberg
0cc1ebc021 🔧 Allow dragging window to screen above menubar (for real) 2017-09-29 14:20:34 -04:00
Felix Rieseberg
89246f3714 🔧 Allow dragging over menubar 2017-09-27 17:43:09 -04:00
Birunthan Mohanathas
044a3a29a6 Simplify checking for NSFullScreenWindowMask 2017-09-27 16:36:18 +03:00
Felix Rieseberg
d45788a7b8 🔧 Don't drag fullscreen window 2017-09-26 18:03:44 -04:00
Felix Rieseberg
a44c2d5dcc 🔧 Extend interface 2017-08-23 16:10:31 -07:00
Felix Rieseberg
cd5cd25f74 🔪 Bonus colon 2017-08-22 11:14:21 -07:00
Felix Rieseberg
6191e6e787 🔧 Implement feedback 2017-08-15 16:14:58 -07:00
Felix Rieseberg
b4bb00843b 🔧 Spaces for the Spacelord 2017-08-10 09:38:01 -07:00
Felix Rieseberg
d913b53fea 🔧 Handle offset BrowserView 2017-08-10 08:00:21 -07:00
Felix Rieseberg
7bfece1144 🔧 Make work with complex shapes 2017-08-09 15:21:58 -07:00
Felix Rieseberg
a55015d63d 🔧 Support older versions of macOS 2017-08-09 15:21:58 -07:00
Felix Rieseberg
a5dfb09037 🔧 Draggable (using the window’s regions) 2017-08-09 15:21:58 -07:00
Birunthan Mohanathas
06fcf2c19d Add support for BrowserView autoresizing 2017-04-13 01:27:31 +03:00
Birunthan Mohanathas
8b9f7e5b00 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-13 01:27:27 +03:00