* refactor: use mojo for electron internal IPC
* add sender_id, drop MessageSync
* remove usages of AtomFrameMsg_Message
* iwyu
* first draft of renderer->browser direction
* refactor to reuse a single ipc interface
* implement TakeHeapSnapshot through mojo
* the rest of the owl^WtakeHeapSnapshot mojofication
* remove no-op overrides in AtomRendererClient
* delete renderer-side ElectronApiServiceImpl when its pipe is destroyed
* looks like we don't need to overlay the renderer manifest after all
* don't try to send 2 replies to a sync rpc
* undo changes to manifests.cc
* unify sandboxed + unsandboxed ipc events
* lint
* register ElectronBrowser mojo service on devtools WebContents
* fix takeHeapSnapshopt failure paths
* {electron_api => atom}::mojom
* add send_to_all to ElectronRenderer::Message
* keep interface alive until callback is called
* review comments
* use GetContext from RendererClientBase
* robustify a test that uses window.open
* MessageSync posts a task to put sync messages in the same queue as async ones
* add v8::MicrotasksScope and node::CallbackScope
* iwyu
* use weakptr to api::WebContents instead of Unretained
* make MessageSync an asynchronous message & use non-associated interface
* iwyu + comments
* remove unused WeakPtrFactory
* inline OnRendererMessage[Sync]
* cleanups & comments
* use helper methods instead of inline lambdas
* remove unneeded async in test
* add mojo to manifests deps
* add gn check for //electron/manifests and mojo
* don't register renderer side service until preload has been run
* update gn check targets list
* move interface registration back to RenderFrameCreated
NOLINT disables the linting error that we can't fix because its just
implementing a content API.
We also disable clang-format because it tries to format the // NOLINT
onto a new line which doesn't exactly work
navigations
There is a race condition between DidCreateScriptContext and another
navigation occuring in the main process. If the navigation occurs while
the preload script is running, the same process is re-used. This
ensures that any pending navigations are completely removed / ignored
when we trigger a new navigation.
Fixes#17576
So although apple has it documented that notifications with duplicate identifiers in the same session won't be presented. They apparently forgot to mention that macOS also non-deterministically and without any errors, logs or warnings will also not present some notifications in future sessions if they have a previously used identifier.
As such, we're going to truly randomize these identifiers so they are
unique between apps and sessions. The identifier now consists of a
randomly generated UUID and the app bundle id.
