![]() In #20829, we fixed compositor recycling when switching between BrowserViews, but it turns out that there is one additional case that we need to handle. When we create a completely new BrowserView instance, it starts of as visible (even when it hasn't been added to the window), which means that it will need its own compositor instead of using the recycled compositor. To fix this, lets make BrowserViews hidden by default until they're added to the window. See also #19988. This is a potentially breaking change given that the initial value of `document.visibilityState` will now be `hidden`, but given the experimental status of BrowserViews, I think this is a fine change to make. The old behavior can be restored with `webPreferences: { show: true }`. Notes: Fix compositor recycling when creating new BrowserView |
||
---|---|---|
.. | ||
app | ||
browser | ||
common | ||
renderer | ||
utility |