Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: ginify BrowserView #23578

Merged
merged 24 commits into from
Jul 9, 2020
Merged

refactor: ginify BrowserView #23578

merged 24 commits into from
Jul 9, 2020

Conversation

nornagon
Copy link
Member

@nornagon nornagon commented May 13, 2020

Description of Change

This refactors BrowserView to use gin::Wrappable instead of gin_helper::TrackableObject. It also makes some changes to the API, removing the id and related methods, and making the object self-owned instead of forcing manual memory management on the user.

I'm not yet convinced that the new code doesn't leak BrowserViews forever in certain (or all) situations, but putting it up for review because at least the tests pass!

Checklist

Release Notes

Notes: Removed experimental APIs: BrowserView.{fromId, fromWebContents, getAllViews} and the id property of BrowserView.

Siteproxy

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.
@electron-cation electron-cation bot added new-pr 🌱 PR opened in the last 24 hours and removed new-pr 🌱 PR opened in the last 24 hours labels May 13, 2020
Copy link
Contributor

@zcbenz zcbenz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to force WebContents of BrowserView to close after each test, currently the tests are failing with:

not ok 250 webContents module getAllWebContents() API returns an array of web contents
 
  AssertionError: expected [ Array(21) ] to have a length of 3 but got 21
 
      at Context.<anonymous> (electron/spec-main/api-web-contents-spec.ts:37:27)

Also I think the removed APIs should be mentioned in breaking changes.

@nornagon
Copy link
Member Author

@zcbenz removed APIs are marked experimental (mostly, though I think the one omission is a mistake and should have been marked experimental). Do we still list breaking changes when APIs are experimental?

@zcbenz
Copy link
Contributor

zcbenz commented May 18, 2020

I could not find any documents on what to do with removing experimental APIs, I'm good without mentioning it then.

nornagon added 23 commits June 8, 2020 10:21

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.
fix

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.
@nornagon nornagon requested a review from zcbenz July 8, 2020 20:10
@nornagon
Copy link
Member Author

WebContents will stay alive as long as there's a page loaded in it. As you've discovered, the BrowserView can be GC'd while the WebContents stays alive, if there's a page loaded. To make sure the WebContents is closed, you must call destroy or otherwise close the WebContents (window.close() from the loaded page also works fine).

This is a common pattern in JS, consider e.g. creating sockets in Node.js:

for (let i = 0; i < 40; i++) {
  let socket = net.connect({port: 1234}, (s) => { /* ... */ })
}

Those sockets will remain alive unless explicitly closed.

@JohanKnutzen
Copy link

@nornagon You're right, but the difference is that sockets have a destroy function whereas BrowserView and webContents do not.

I don't mind explicit resource management, we were destroying BrowserView using BrowserView.destroy before. The problem is:

  • BrowserView.destroy was removed
  • webContents does not have a public API destroy function

So to remove the process leak, one needs to call an undocumented function which is unknowable by users of Electron and without it, there's no proper lifecycle management.

This is an issue in our case because we dynamically create BrowserViews and use them as tabs in our application.

@nornagon
Copy link
Member Author

@yohan1234 ah, yes, you're right. I had it in my head that webContents.destroy was publicly documented.

I agree that this is a missing piece of our API. I've opened a new issue to track it: #26929

@JohanKnutzen
Copy link

@nornagon Excellent!

@pushkin-
Copy link

@nornagon Calling destroy() and then closing the window crashes Electron for me actually
dump.zip

@JohanKnutzen
Copy link

@pushkin- Is it bound to a BrowserWindow when you destroy it? to remove it prior to destroy: BrowserWindow.setBrowserView(null)

@pushkin-
Copy link

@yohan1234 removing it from the window fixed the crash. Thanks!

@pushkin-
Copy link

So destroying the webcontents fixes the process leak, but the entries are still not removed from my WeakMap<WebContents, value> for some reason. Maybe it just takes a really long time? (I waited 15 minutes). Or maybe there's something else going on. I might have to use a regular map and just delete the entries myself.

@JohanKnutzen
Copy link

@pushkin- Not sure what you mean. All references need to be removed for garbage collection. Do you mean some kind of internal map in BrowserWindow or something in your application?

@pushkin-
Copy link

@yohan1234 The WeakMap structure that I created from above (what nornagon posted) still has entries for destroyed webcontents:

webContentsToBrowserView.set(browserView.webContents, browserView)

@JohanKnutzen
Copy link

@pushkin- Sorry, where is the code?

@pushkin-
Copy link

@yohan1234 I'm referring to this.

My specific code is like:

interface IWebContentsInfo {
	browserView: Electron.BrowserView;
	browserWindow: Electron.BrowserWindow;
}
let webContentsInfo = new WeakMap<Electron.WebContents, IWebContentsInfo>();

And when I close the window, I do:

window.setBrowserView(null);
const webContentsIds = getAllWebContentsIdThatAreAssociatedWithThatWindow(); // each WC is a tab
for each webContents Id:
    webContents.fromId(id).destroy();

And the entries are never removed from the WeakMap.

@JohanKnutzen
Copy link

JohanKnutzen commented Dec 11, 2020

@pushkin- .destroy() only destroys the internal V8 stuff in webcontents, it doesn't nuke the chain of things. In your code it seems that it might be that webContents (and BrowserWindow/BrowserView by proxy) leak forever

@MatthieuLeMee
Copy link

Any news on a way to stop a BrowserView properly and unallocate memory as we were doing with destroy() before the v11 ?
We are building an enterprise portal using tabs too, and browserview management is the heart of our app.

@JohanKnutzen
Copy link

@MatthieuLeMee we seem to have the same use case. @nornagon opened up a proposal but I don't know who the maintainer is:
#26929

Perhaps the practical approach is to unmerge this PR?

@nornagon
Copy link
Member Author

BrowserView will be GCable when its WebContents is destroyed and the reference to it is dropped. bv.webContents.destroy() should do the trick.

@pushkin-
Copy link

@nornagon Unless it's a bug in my code, I pasted an example above where I destroyed the webcontents, but the entry is not cleared from the WeakMap (I waited 15 minutes for GC; maybe it takes longer?).

I could open a separate issue for this if you want (if we don't already have one)

@nornagon
Copy link
Member Author

@pushkin- yeah, let's go ahead and open a new issue, I think. If the BVs aren't being GC'd even after the webContents is destroyed then that'd be a bug. I don't think WeakMap would factor into it.

@pushkin-
Copy link

@nornagon I posted an issue here

sentialx pushed a commit to sentialx/electron that referenced this pull request Apr 8, 2021

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.
@eric-burel
Copy link

eric-burel commented Jan 12, 2022

Hi guys, I am currently upgrading from v7 (long way ahead!), and I don't get how I should replace those methods.

Here's my use case: I want some renderer code to open a dialog. To do so, I've created an IPC handler, and I expose a method like this in preload script: showOpenDialogSync: (...args) => { return ipcRenderer.sendSync('show-open-dialog-sync', ..args);}.

First, I am not sure if I am allowed to call dialog in the preload script, but that's another point.

Then, the handler is like this:

const showOpenDialogSyncHandler: IpcMainHandlerDef = [
    showOpenDialogSyncChannel,
    async (evt: any, ...args: any) => {
        const parent = evt.sender
            ? BrowserWindow.fromWebContents(evt.sender)
            : null;
        evt.returnValue = dialog.showOpenDialogSync(parent, ...args);
        return evt;
    },
];

So to get the parent, I need to get the BrowserWindow based on the event sender WebContents. How should I achieve that without those methods?

By the way they are still documented and nothing tells that they are deprecated or removed in current doc: https://www.electronjs.org/docs/latest/api/browser-window#browserwindowfromwebcontentswebcontents

I have some hard time upgrading the code from "remote" to the new APIs

Edit: ok I found more info in the hidden comments, I missed them. It seems that I need to maintain my own mapping.

Edit 2: man it's BrowserView that was affect by this, not BrowserWindow sorry for the inconvenience ^^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants