Description of Change

fixes: #42637

Summary of bug

• As highlighted in the issue, prior to v30, when setting a view to setTopBrowserView, the view would focus correctly, and that is because it's using the macOS view ordering APIs to reorder the view to the top without reseting any state.
• With the new WebContentView changes in v30, we updated our implementation of setTopBrowserView to:

BrowserWindow.prototype.setTopBrowserView = function (browserView: BrowserView) {
  if (browserView.ownerWindow !== this) { throw new Error('Given BrowserView is not attached to the window'); }
   this.addBrowserView(browserView);
};

The issue arises because this.addBrowserView removes the view from the owner window before re-adding it. This removal removes the view from the focus list and resets its state, causing the top view to incorrectly focus.

Proposed fix

• This PR has already added Chromium's reordering API inside AddChildViewAt to reorder if the child is already a child of this view. So calling this.contentView.addChildView directly on a view that already exists on the window will reorder it to the top.
• Tested with my local build of electron and works as expected

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation, tutorials, templates and examples are changed or added
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Fixed a focus issue when calling BrowserWindow.setTopBrowserView