Share a shared buffer object with script of the iframe in the WebView.
The script will receive a sharedbufferreceived event from chrome.webview.
The event arg for that event will have the following methods and properties:
getBuffer(): return an ArrayBuffer object with the backing content from the shared buffer.
additionalData: an object as the result of parsing additionalDataAsJson as JSON string.
This property will be undefined if additionalDataAsJson is nullptr or empty string.
source: with a value set as chrome.webview object.
If a string is provided as additionalDataAsJson but it is not a valid JSON string,
the API will fail with E_INVALIDARG.
If access is COREWEBVIEW2_SHARED_BUFFER_ACCESS_READ_ONLY, the script will only have read access to the buffer.
If the script tries to modify the content in a read only buffer, it will cause an access
violation in WebView renderer process and crash the renderer process.
If the shared buffer is already closed, the API will fail with RO_E_CLOSED.
The script code should call chrome.webview.releaseBuffer with
the shared buffer as the parameter to release underlying resources as soon
as it does not need access to the shared buffer any more.
The application can post the same shared buffer object to multiple web pages or iframes, or
post to the same web page or iframe multiple times. Each PostSharedBufferToScript will
create a separate ArrayBuffer object with its own view of the memory and is separately
released. The underlying shared memory will be released when all the views are released.
For example, if we want to send data to script for one time read only consumption.
Sharing a buffer to script has security risk. You should only share buffer with trusted site.
If a buffer is shared to a untrusted site, possible sensitive information could be leaked.
If a buffer is shared as modifiable by the script and the script modifies it in an unexpected way,
it could result in corrupted data that might even crash the application.
Share a shared buffer object with script of the iframe in the WebView. The script will receive a sharedbufferreceived event from chrome.webview. The event arg for that event will have the following methods and properties: getBuffer(): return an ArrayBuffer object with the backing content from the shared buffer. additionalData: an object as the result of parsing additionalDataAsJson as JSON string. This property will be undefined if additionalDataAsJson is nullptr or empty string. source: with a value set as chrome.webview object. If a string is provided as additionalDataAsJson but it is not a valid JSON string, the API will fail with E_INVALIDARG. If access is COREWEBVIEW2_SHARED_BUFFER_ACCESS_READ_ONLY, the script will only have read access to the buffer. If the script tries to modify the content in a read only buffer, it will cause an access violation in WebView renderer process and crash the renderer process. If the shared buffer is already closed, the API will fail with RO_E_CLOSED.
The script code should call chrome.webview.releaseBuffer with the shared buffer as the parameter to release underlying resources as soon as it does not need access to the shared buffer any more.
The application can post the same shared buffer object to multiple web pages or iframes, or post to the same web page or iframe multiple times. Each PostSharedBufferToScript will create a separate ArrayBuffer object with its own view of the memory and is separately released. The underlying shared memory will be released when all the views are released.
For example, if we want to send data to script for one time read only consumption.
\snippet ScenarioSharedBuffer.cpp OneTimeShareBuffer
In the HTML document,
\snippet assets\ScenarioSharedBuffer.html ShareBufferScriptCode_1
\snippet assets\ScenarioSharedBuffer.html ShareBufferScriptCode_2
Sharing a buffer to script has security risk. You should only share buffer with trusted site. If a buffer is shared to a untrusted site, possible sensitive information could be leaked. If a buffer is shared as modifiable by the script and the script modifies it in an unexpected way, it could result in corrupted data that might even crash the application.