fix: check the sending frame for internal guest, window and reply IPCs - #53684

…s (42-x-y) (#53727)

fix: check the sending frame for internal guest, window and reply IPCs (#53684)

* fix: check the sending frame for internal guest, window and reply IPCs

* guest-view IPCs (attach/detach/call/property get/set) are honoured only
  from the frame that created the <webview>, not from any frame in the
  embedder WebContents
* window.close() via the internal IPC is honoured only from the top-level
  document, and the renderer override is installed for the main frame only
* replies to webContents.executeJavaScript()/insertCSS() and friends are
  accepted only from the main frame they were sent to
* webContents.sendToFrame() only addresses frames that belong to that
  WebContents
* the <webview> `ipc-message` event carries `frameOrigin` / `frameUrl` of the
  frame in the guest that sent it
* process.getProcessMemoryInfo() reports the calling frame's own process
* docs: validateSender example checks senderFrame.origin

* docs: add API history PR reference

* refactor: drop frameOrigin/frameUrl from the webview ipc-message event

(cherry picked from commit 8cc20cf)

…s (43-x-y) (#53726)

fix: check the sending frame for internal guest, window and reply IPCs (#53684)

* fix: check the sending frame for internal guest, window and reply IPCs

* guest-view IPCs (attach/detach/call/property get/set) are honoured only
  from the frame that created the <webview>, not from any frame in the
  embedder WebContents
* window.close() via the internal IPC is honoured only from the top-level
  document, and the renderer override is installed for the main frame only
* replies to webContents.executeJavaScript()/insertCSS() and friends are
  accepted only from the main frame they were sent to
* webContents.sendToFrame() only addresses frames that belong to that
  WebContents
* the <webview> `ipc-message` event carries `frameOrigin` / `frameUrl` of the
  frame in the guest that sent it
* process.getProcessMemoryInfo() reports the calling frame's own process
* docs: validateSender example checks senderFrame.origin

* docs: add API history PR reference

* refactor: drop frameOrigin/frameUrl from the webview ipc-message event

(cherry picked from commit 8cc20cf)

)

Removing a <webview> from the DOM tears down its internal iframe first,
which destroys the guest and drops it from guestInstances. The element's
disconnectedCallback then sends GUEST_VIEW_MANAGER_DETACH_GUEST for that
id. Since #53684 the handler validates the id with getGuestForFrame()
before detaching, so the already-gone guest made the sync IPC throw back
into disconnectedCallback. The uncaught error also skipped the element's
reset, so a removed <webview> that was re-inserted never got a new guest.

Treat a detach for an unknown guest as a no-op again (as detachGuest()
always did) and keep the sender-frame check for live guests.

Fixes #53989.

)

Removing a <webview> from the DOM tears down its internal iframe first,
which destroys the guest and drops it from guestInstances. The element's
disconnectedCallback then sends GUEST_VIEW_MANAGER_DETACH_GUEST for that
id. Since #53684 the handler validates the id with getGuestForFrame()
before detaching, so the already-gone guest made the sync IPC throw back
into disconnectedCallback. The uncaught error also skipped the element's
reset, so a removed <webview> that was re-inserted never got a new guest.

Treat a detach for an unknown guest as a no-op again (as detachGuest()
always did) and keep the sender-frame check for live guests.

Fixes #53989.

Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Sam Attard <[email protected]>

)

Removing a <webview> from the DOM tears down its internal iframe first,
which destroys the guest and drops it from guestInstances. The element's
disconnectedCallback then sends GUEST_VIEW_MANAGER_DETACH_GUEST for that
id. Since #53684 the handler validates the id with getGuestForFrame()
before detaching, so the already-gone guest made the sync IPC throw back
into disconnectedCallback. The uncaught error also skipped the element's
reset, so a removed <webview> that was re-inserted never got a new guest.

Treat a detach for an unknown guest as a no-op again (as detachGuest()
always did) and keep the sender-frame check for live guests.

Fixes #53989.

Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Sam Attard <[email protected]>

)

Removing a <webview> from the DOM tears down its internal iframe first,
which destroys the guest and drops it from guestInstances. The element's
disconnectedCallback then sends GUEST_VIEW_MANAGER_DETACH_GUEST for that
id. Since #53684 the handler validates the id with getGuestForFrame()
before detaching, so the already-gone guest made the sync IPC throw back
into disconnectedCallback. The uncaught error also skipped the element's
reset, so a removed <webview> that was re-inserted never got a new guest.

Treat a detach for an unknown guest as a no-op again (as detachGuest()
always did) and keep the sender-frame check for live guests.

Fixes #53989.

Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Sam Attard <[email protected]>

)

Removing a <webview> from the DOM tears down its internal iframe first,
which destroys the guest and drops it from guestInstances. The element's
disconnectedCallback then sends GUEST_VIEW_MANAGER_DETACH_GUEST for that
id. Since #53684 the handler validates the id with getGuestForFrame()
before detaching, so the already-gone guest made the sync IPC throw back
into disconnectedCallback. The uncaught error also skipped the element's
reset, so a removed <webview> that was re-inserted never got a new guest.

Treat a detach for an unknown guest as a no-op again (as detachGuest()
always did) and keep the sender-frame check for live guests.

Fixes #53989.

Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Sam Attard <[email protected]>