BrowserView crashes the app after resizing the BrowserWindow

[Beelink]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Issue Details

• Electron Version:
  • 6.0.2 / 6.0.3 / 7.0.0-beta.3
• Operating System:
  • Windows 10 Pro 1903 (6/7/2019)
• Last Known Working Electron version:
  • N/A

Expected Behavior

I can resize the window

Actual Behavior

The application freezes for a few seconds and crashes

To Reproduce

1. Create new BrowserWindow
2. Create new BrowserView
3. browserView.webContents.loadURL(someURL)
4. browserWindow.setBrowserView(browserView)
5. browserView.setBounds(someBounds)
6. Trying to resize browserWindow crashes the app

Screenshots

Additional Information

There are no such error with webview-tag

Log: 2019-08-24T11_30_07_911Z-debug.log

[jiwonchang]

Hello @sofianguy ,

I'm also seeing this issue, with the same error code.

Screenshot:

I'm trying to deploy an app that uses BrowserView. May I know approximately when this issue can be resolved? Also, just in general, would you recommend using webview-tag as an alternative? I hesitate to use webview-tag since its documentation warns us against using it and instead recommends using BrowserView.

Please let me know if you have any questions. Thank you for your time! :)

Update:
I was able to find the root cause of the issue. The issue happens when I try to resize the BrowserWindow right after I call view.destroy() on a BrowserView instance. It seems that the conflict stems from the BrowserView attempting to resize itself while also trying to destroy itself.

Since this may be a different issue than the OP's issue, I'll start open a new issue. Thanks!

[James-Livesey]

The solution I found requires calling win.removeBrowserView(view) before view.destroy():

// To init the BrowserView
var win = new BrowserWindow();
var view = new BrowserView();

win.addBrowserView(view); // Can also use win.removeBrowserView

// To destroy the BrowserView with no crash
win.removeBrowserView(view); // We remove the BrowserView from the BrowserWindow first so that the bug does not trigger when we resize the window
view.destroy();

Note: You'll need to assign the BrowserView to a variable in order to do this.

I hope this works for you! It has seemed to fix the problem for me. It works on Linux for me at least, but it should also work on other platforms too.

[leofidus]

I experienced the same issue in both Electron 8.2.0 and Electron 9.0.0.

removeBrowserView before calling destroy fixes the problem for me. However this should at least be mentioned in the documentation.

In Electron 9 the Stacktrace looks like this:

Backtrace:
        v8::CFunction::ArgumentCount [0x00007FF7847FE664+4]
        v8::CFunction::ArgumentCount [0x00007FF7847FE772+274]
        v8::ArrayBuffer::Contents::AllocationLength [0x00007FF784804364+11668]
        IsSandboxedProcess [0x00007FF786E99CE4+1492404]
        IsSandboxedProcess [0x00007FF786EA15D5+1523365]
        node::AsyncResource::get_trigger_async_id [0x00007FF786CDD9A2+2067714]
        GetHandleVerifier [0x00007FF787A120AF+10201887]
        GetHandleVerifier [0x00007FF787A14B68+10212824]
        GetHandleVerifier [0x00007FF787A0FCF8+10192744]
        GetHandleVerifier [0x00007FF787A0F02C+10189468]
        GetHandleVerifier [0x00007FF787330889+2986745]
        GetHandleVerifier [0x00007FF7873303CF+2985535]
        CallWindowProcW [0x00007FF816955C0D+957]
        DispatchMessageW [0x00007FF8169557DC+972]
        MBToWCSEx [0x00007FF816965100+448]
        KiUserCallbackDispatcher [0x00007FF817F7FDE4+36]
        NtUserMessageCall [0x00007FF815A51184+20]
        GetWindowTextW [0x00007FF81695436A+2090]
        MapWindowPoints [0x00007FF816953AFF+959]
        IsCompositionActive [0x00007FF80F91984E+974]
        Ordinal96 [0x00007FF80F9325F2+1490]
        IsCompositionActive [0x00007FF80F91C50F+12431]
        IsCompositionActive [0x00007FF80F91BFF1+11121]
        GetWindowTextW [0x00007FF81695403F+1279]
        GetHandleVerifier [0x00007FF787A14335+10210725]
        GetHandleVerifier [0x00007FF787A0FA37+10192039]
        GetHandleVerifier [0x00007FF787A0F02C+10189468]
        GetHandleVerifier [0x00007FF787330889+2986745]
        GetHandleVerifier [0x00007FF7873303CF+2985535]
        CallWindowProcW [0x00007FF816955C0D+957]
        DispatchMessageW [0x00007FF8169557DC+972]
        IsWindowVisible [0x00007FF816961F73+419]
        KiUserCallbackDispatcher [0x00007FF817F7FDE4+36]
        NtUserMessageCall [0x00007FF815A51184+20]
        GetWindowTextW [0x00007FF81695436A+2090]
        MapWindowPoints [0x00007FF816953AFF+959]
        IsCompositionActive [0x00007FF80F91984E+974]
        IsCompositionActive [0x00007FF80F91C50F+12431]
        IsCompositionActive [0x00007FF80F91BFF1+11121]
        GetWindowTextW [0x00007FF81695403F+1279]
        v8_inspector::V8StackTraceId::ToString [0x00007FF786160495+8396917]
        v8_inspector::V8StackTraceId::ToString [0x00007FF7861613B7+8400791]
        v8_inspector::V8StackTraceId::ToString [0x00007FF786160BB6+8398742]
        v8_inspector::V8StackTraceId::ToString [0x00007FF7861615C6+8401318]
        (No symbol) [0x00007FFFE63E1028]```

[codebytere]

Closed in #25411