* fix: Invalidate weak ptrs before window Javascript object is destroyed
* chore: add regression test for #14513
This test is similar to the original gist at https://gist.github.com/bpasero/a02a645e11f4946dcca1331d0299149d -- the key is to open multiple windows and add an `app.on('browser-window-focus') listener that accesses window.id.
* fix: last commit didn't test the right thing.
The test needs to run in the main process to reproduce the
conditions reported in #14513
* fix: Notify focus change right away, not on next tick
* fix: emit the JS blur/focus events on next tick to avoid race condition
* address feedback from review
* fix: bind deferred Emit() calls to a WeakPtr
This is so that the deferred Emit() calls will be canceled
if the TopLevelWindow is destroyed.
* chore: remove wip/test code cruft
* fix: make linter happy
* Enable disabled tests
* refactor: cleaner impl of EmitEventSoon()
* Revert "Merge branch 'fix-win-focus' of github.com:electron/electron into fix-win-focus"
This reverts commit 90576806eb271d059f0a215c67e9b4b04f7396a4, reversing
changes made to 9c13e47779a3af78fe0970c1f3d6cd040a5354e6.
* Restore 704722c1, which was removed in error.
We apologise again for the fault in the subtitles. Those responsible for sacking the people who have just been sacked have been sacked.
* feat: allow setting window shape
This binds Widget::SetShape, an API that already exists in Chromium (for
Windows and Linux). It's a more reliable method of having some parts of
your window be "click-through" than the current `setIgnoreMouseEvents`
API, which messes around with the `WS_EX_LAYERED` window style on
Windows, causing strange bugs and incompatibility with hardware
acceleration.
* update docs
RenderProcessHost switch can happen between ipc calls when
speculative process are invvolved, which will lead to deletion
of entries on current context. Use OS process handles to
uniquely associate a destruction handler for a render process.
* fix: use OOIF for webview tag
* fix: do not call GetNativeView for webview
* fix: OOIPF webview's WebContents is managed by embedder frame
* fix: guest view can not be focused
* fix: clear zoom controller when guest is destroyed
* fix: implement the webview resize event
The webview is no longer a browser plugin with the resize event, use
ResizeObserver instead.
* test: disable failed tests due to OOPIF webview
* fix: embedder can be destroyed earlier than guest
This happens when embedder is manually destroyed.
* fix: don't double attach
* fix: recreate iframe when webview is reattached
* fix: resize event may happen very early
* test: some tests are working after OOPIF webview
* chore: remove unused browser plugin webview code
* fix: get embedder via closure
When the "destroyed" event is emitted, the entry in guestInstances would be
cleared.
* chore: rename browserPluginNode to internalElement
* test: make the visibilityState test more robust
* chore: guestinstance can not work with OOPIF webview
* fix: element could be detached before got response from browser
* fix: create a window capturer correctly
We were incorrectly creating two screen capturers instead of a window
capturer
* spec: ensure dc tests pass
* spec: enable all tests after verifying dc tests work
When using `views::Widget` to create window, Chromium will automatically
use a `BridgedContentView` as content view, which however does not
support draggable regions inside it.
By fallback to `FullSizeContentView` we can work around this problem,
with the price of losing the ability to use `views::View` APIs. Since
we don't expect users to use the new `View` APIs in `BrowserWindow`
anyway, it should not be a problem.
This change does not affect users of `TopLevelWindow`, and for users of
`BrowserWindow` there is nothing to lose.
In the long term we should look into how to make draggable regions work
with `BridgedContentView`. The related Chromium code is still being
changed rapidly, we can wait until Chromium migrated its
`NativeAppWindowCocoa` class to use `views::Widget`.
* fix: pass the boolean value of enableAutoSize to setSize
The webContents setSize API takes in an optional enableAutoSize boolean.
Looking in the code, if that property is set, regardless if you pass in
true or false, it will always set it to true. This change passes the
appropriate boolean value down properly.
* creating new bool for autosize
