How Chromium's Web Share API Invokes Native OS Share Sheets

This article provides a technical overview of how the Web Share API in the Chromium browser bridges web applications with native operating system share dialogs. It covers the complete lifecycle of a share request, starting from the initial JavaScript invocation in the Blink rendering engine, moving through Chromium’s inter-process communication layer, and ending with the execution of platform-specific native APIs on Android, iOS, Windows, macOS, and ChromeOS.

The process begins when a user interacts with a web page and triggers the navigator.share() JavaScript method. Because this happens within a web page, it is handled by Chromium's rendering engine, Blink, which runs inside a restricted, sandboxed Renderer process.

Before Chromium attempts to contact the operating system, Blink performs strict validation:

  • HTTPS Requirement: The API only functions in secure contexts (HTTPS).
  • Transient Activation: Blink verifies that the call was triggered by a direct user gesture, such as a mouse click or screen tap, to prevent spam.
  • Data Validation: The payload (URL, text, title, or files) is checked for validity. If files are included, Blink verifies that the file types are on Chromium's allowlist of safe-to-share extensions.

Once validated, Blink creates a JavaScript Promise that waits for the native OS to respond, and prepares to send the data out of the sandbox.

2. Crossing the Sandbox via Mojo IPC

Because the Renderer process is sandboxed for security, it cannot directly invoke operating system APIs. To bypass this, Chromium uses Mojo, its inter-process communication (IPC) system.

Blink packages the share data into a Mojo message and sends it across the IPC boundary to the privileged Browser process. Specifically, it communicates with the blink.mojom.ShareService interface. The Browser process receives this request via a C++ implementation called ShareServiceImpl, which acts as the central router for native OS integration.

3. Invoking Mobile Share Sheets

Once the Browser process has the share data, it hands the payload off to platform-specific code to trigger the mobile operating system's native UI.

Android On Android, Chromium's Browser process is written in C++, while the Android OS APIs require Java. Chromium bridges this gap using the Java Native Interface (JNI).

  • The C++ ShareServiceImpl calls into Chromium's Java layer (ShareDelegateImpl).
  • The Java code constructs a standard Android Intent using Intent.ACTION_SEND (or Intent.ACTION_SEND_MULTIPLE for multiple files).
  • The text, URL, and file URIs are attached as extras to this Intent.
  • Finally, Chromium calls Intent.createChooser(), which instructs the Android OS to display the native bottom-sheet share dialog over the browser.

iOS Although iOS requires browsers to use WebKit rather than Blink, Chromium on iOS still manages the UI layer and native bridges using Objective-C++.

  • When a share is triggered, the Chromium iOS layer captures the payload and instantiates a native UIActivityViewController object.
  • The shared items (URLs, strings, or file data) are passed into this controller's initialization array.
  • Chromium then presents the UIActivityViewController on the current view controller, invoking the standard iOS share sheet.

4. Invoking Desktop Share Sheets

Desktop operating systems handle sharing differently than mobile platforms, requiring Chromium to hook into various modern desktop APIs.

Windows On Windows 10 and Windows 11, Chromium utilizes the Windows Runtime (WinRT) APIs.

  • The Browser process accesses the DataTransferManager class via its C++/WinRT projection.
  • Chromium binds the share operation to the specific browser window handle (HWND) using the IDataTransferManagerInterop interface.
  • It registers an event handler for the DataRequested event, populates a DataPackage object with the web payload, and calls ShowShareUIForWindow(). This triggers the native Windows Share flyout.

macOS On macOS, Chromium uses Objective-C++ to interact with Apple's AppKit framework.

  • The Browser process takes the share payload and converts the items into NSString or NSURL objects.
  • Chromium instantiates an NSSharingServicePicker object, passing the converted data items into it.
  • It then calls the showRelativeToRect:ofView:preferredEdge: method, which anchors and displays the native macOS share menu directly beneath the web page's share button or the browser's top toolbar.

ChromeOS On ChromeOS, the browser and the operating system are tightly integrated.

  • When ShareServiceImpl receives the Mojo message, it routes the request directly to the Ash window manager's SharesheetService.
  • ChromeOS builds a unified native share sheet that combines two types of targets: Android apps running in the ARC++ container (invoked via Android Intents) and installed Progressive Web Apps (PWAs) that have registered as Web Share Targets in their web app manifests.

5. Resolving the JavaScript Promise

Regardless of the platform, the final step is the same. Once the user either selects a share target in the native OS sheet or dismisses the dialog, the operating system sends a callback to Chromium's Browser process. The Browser process sends a Mojo IPC message back to the Blink Renderer process, which then resolves the original JavaScript Promise (if the share succeeded) or rejects it with an AbortError (if the user canceled the action).