A cross-process rendering system and method for a browser with native program windows

Abstract

This invention discloses a cross-process rendering system and method for browsers and native application windows. The system includes a browser rendering process, a local middleware process, and a local target application process, establishing a cross-process communication channel via HTTP and WebSocket. The front-end intercepts plugin requests and connects to the local service; the middleware receives instructions and launches an independent target application process; it obtains the target application window handle and uses operating system APIs to mount it as a child window of the browser container window, achieving seamless visual embedding; user interaction events are converted into system messages in real time and sent to the native window through the communication channel, achieving native-level editing responses. This invention achieves multi-document process isolation, ensuring browser stability even if a single instance crashes, and guarantees communication security through digital signatures and encrypted transmission. It is suitable for online document editing scenarios with high security requirements.

Description

Technical Field

[0001] This invention belongs to the field of Internet technology, specifically relating to a cross-process rendering system and method for browsers and native program windows. Background Technology

[0002] With the widespread adoption of web technologies, online document processing (such as previewing and editing Office / WPS documents) has become a core requirement. Traditional solutions primarily rely on PPAPI (Pepper Plugin API) technology, which employs an in-process rendering architecture, loading the plugin directly into the browser's process space and calling the local Office / WPS software through the browser's provided interface. While this method achieves embedded display of documents in the browser, it suffers from serious security and stability vulnerabilities because the browser plugin and the browser itself run in the same process space. With mainstream browsers (such as Chrome 107+ and Edge) completely disabling PPAPI, not only has compatibility been lost, but the urgent need for a secure and stable cross-process rendering technology has also become apparent.

[0003] Traditional solutions suffer from stability, security, and compatibility issues due to the lack of a secure and efficient mechanism for embedding local program windows. Specifically, the core technical problem this invention aims to solve is: how to securely launch a local Office / WPS program and seamlessly and faithfully mount its native editing window to a designated area of ​​the browser without relying on browser plugins, through a cross-process communication and window management mechanism, to achieve an editing experience indistinguishable from the original program. Summary of the Invention

[0004] A cross-process rendering system for browsers and native application windows includes: Rendering instructions are passed across processes: Browser process: responsible for providing a container, intercepting user input, and communicating with middleware. The middleware process forwards instructions to the Office application process. Local middleware process: the core hub, responsible for communication bridging, program launch, window mounting, and message forwarding; Office / WPS application process: runs independently and is responsible for the realistic rendering and editing logic of documents; Native Window Mounting and Hybrid Rendering: After opening a specified document using an Office application (such as Word), the Kingsoft Control obtains the handle of the Word application's main window. The local middleware process uses operating system APIs (such as Windows' SetParent function) to set the Word window as a child window of a browser-specific child window (the browser process informs it of its handle or identifier through a communication channel). This operation achieves seamless visual embedding between the Word native window and the browser window. The content of the Word window is directly rendered by the system and naturally composited with other parts of the browser (such as toolbars and sidebars), providing native rendering effects and high-fidelity interaction that are indistinguishable from native software and support hardware acceleration. At the same time, in order to achieve precise interface control over the embedded area (such as hiding the Word native menu and toolbar, or achieving borderless embedding), the local middleware process will work with the Kingsoft Control to adjust the style and handle message hooks of the mounted Word window. Real-time synchronization mechanism: A bidirectional cross-process communication channel is established. The full-duplex communication channel provided by WebSocket ensures low-latency synchronization between user operations and visual feedback. The local middleware can manage multiple independent WebSocket sessions, thereby supporting the simultaneous opening and editing of multiple documents. Each session corresponds to an independent Office / WPS application process instance, realizing true multi-document concurrent rendering and isolation.

[0005] A cross-process rendering method for a browser and a native application window based on the system, comprising the following steps; S1. Communication Establishment and Command Issuance: Front-end interception and connection: The browser front-end script intercepts the user's request to open the document, blocks the default plugin behavior, and establishes a connection with the local middleware service via HTTP to negotiate and establish a WebSocket real-time communication channel; Command encapsulation and transmission: The front end sends document operation commands (such as opening report.docx) to the local middleware via WebSocket; S2. Local program startup: Process creation: After receiving the instruction, the local middleware launches the local target application process (such as Microsoft Word) through system calls (such as CreateProcess) or the Kingsoft control interface. Document Loading and Window Ready: Instructs the newly launched Word process to open the specified document, and Word will create a main window containing the document content; Window handle acquisition: The local middleware obtains the handle of the Word document window through the Kingsoft control or system API (such as FindWindow); Browser container identification: The browser frontend sends a handle to the container window created by the browser for the embedded document to the middleware via WebSocket. This container is typically a specific... The system window corresponding to the element; S3. Window Mounting: The local middleware calls the system API to set the Word window as a child window of the browser container window. This operation is the key to achieving embedding, which makes the rendering of the Word window completely handled by the operating system and Word itself, with the browser only providing a display area. Window style adjustment: The middleware further adjusts the style of the Word window, such as removing the border and resizing it to fill the container, to achieve a visually seamless integration; S4. Interactive Message Forwarding and Synchronization: Event Capture and Upload: When a user executes business code, the front-end script captures the event and sends it to the local middleware via WebSocket; Message conversion and delivery: The local middleware converts these operation information into operating system messages (such as Windows messages) and sends them precisely to the mounted Word window; Native response: After receiving a message, the Word window executes the same processing logic as the original program (such as cursor movement, text input, and rendering refresh), giving users a native-level editing experience; Secure inter-process communication: Digital signatures can be used to verify the integrity of the message source in HTTP requests and WebSocket messages, and sensitive data can be encrypted to ensure the security of cross-process transmission; Rendering resource isolation: Each Office / WPS application process enjoys an independent GPU context and memory space, avoiding resource competition with browser rendering tasks and improving graphics rendering performance; Fault isolation: Due to process isolation, the unexpected crash of the Office / WPS application process will not cause the browser rendering process or the local middleware process to shut down, greatly enhancing overall stability; Performance optimization strategies: Compress the transmitted rendering data and implement caching strategies in the middleware or frontend to reduce network transmission overhead and improve response speed; A cross-process rendering system for browsers and native application windows, enabling secure inter-process communication using the following mechanism; Secure cross-process communication mechanism: It adopts a cooperative communication protocol based on HTTP for session initialization and control, and WebSocket for full-duplex real-time data exchange. The mechanism is the "blood vessel" connecting isolated processes, ensuring the reliability, efficiency and security of instruction and data transmission.

[0006] The beneficial effects of this invention are as follows: **Intrinsically Enhanced Security:** By isolating potentially dangerous operations in independent processes outside the browser sandbox through a cross-process architecture, strictly adhering to the principle of least privilege, it fundamentally eliminates the risk of malicious web pages attacking the system through plugin interfaces. **Superior Stability:** Process isolation ensures that failures of individual components (especially local applications) are controlled within their respective process scopes, preventing overall browser crashes and significantly enhancing system fault tolerance. **True Cross-Platform and Browser Compatibility:** Communication is based on standard HTTP / WebSocket protocols, widely supported by all modern browsers, enabling seamless operation on browsers with different kernels such as Chrome, Edge, and Firefox, overcoming the compatibility challenges of PPAPI. **Performance Optimization and Efficient Resource Utilization:** Independent Office / WPS application processes can fully utilize system resources for rendering, avoiding lag caused by resource contention within a single browser process, especially beneficial for the smooth display of complex documents. **Good Maintainability and Scalability:** Each process module has clear responsibilities and can be independently upgraded and maintained. The WebSocket-based communication architecture facilitates the extension of new functions, such as real-time collaborative editing and remote control. Native Experience and High-Performance Rendering: By directly mounting native application windows, users can obtain a high-fidelity visual experience and smooth interactive response that is completely consistent with local operation. This is because all rendering is directly handled by the native application and operating system graphics stack, resulting in minimal performance overhead. Flexible Rendering Strategies: This invention supports both native window mounting and data stream rendering modes, which can be flexibly selected or combined according to actual needs (such as requirements for interface consistency, network environment, and security strategies), achieving a high degree of adaptability. Detailed Implementation

[0007] A cross-process rendering system for browsers and native application windows includes: Rendering instructions are passed across processes: Browser process: responsible for providing a container, intercepting user input, and communicating with middleware. The middleware process forwards instructions to the Office application process. Local middleware process: the core hub, responsible for communication bridging, program launch, window mounting, and message forwarding; Office / WPS application process: runs independently and is responsible for the realistic rendering and editing logic of documents; Native Window Mounting and Hybrid Rendering: After opening a specified document using an Office application (such as Word), the Kingsoft Control obtains the handle of the Word application's main window. The local middleware process uses operating system APIs (such as Windows' SetParent function) to set the Word window as a child window of a browser-specific child window (the browser process informs it of its handle or identifier through a communication channel). This operation achieves seamless visual embedding between the Word native window and the browser window. The content of the Word window is directly rendered by the system and naturally composited with other parts of the browser (such as toolbars and sidebars), providing native rendering effects and high-fidelity interaction that are indistinguishable from native software and support hardware acceleration. At the same time, in order to achieve precise interface control over the embedded area (such as hiding the Word native menu and toolbar, or achieving borderless embedding), the local middleware process will work with the Kingsoft Control to adjust the style and handle message hooks of the mounted Word window. Real-time synchronization mechanism: A bidirectional cross-process communication channel is established. The full-duplex communication channel provided by WebSocket ensures low-latency synchronization between user operations and visual feedback. The local middleware can manage multiple independent WebSocket sessions, thereby supporting the simultaneous opening and editing of multiple documents. Each session corresponds to an independent Office / WPS application process instance, realizing true multi-document concurrent rendering and isolation.

[0008] A cross-process rendering method for a browser and a native application window based on the system, comprising the following steps; S1. Communication Establishment and Command Issuance: Front-end interception and connection: The browser front-end script intercepts the user's request to open the document, blocks the default plugin behavior, and establishes a connection with the local middleware service via HTTP to negotiate and establish a WebSocket real-time communication channel; Command encapsulation and transmission: The front end sends document operation commands (such as opening report.docx) to the local middleware via WebSocket; S2. Local program startup: Process creation: After receiving the instruction, the local middleware launches the local target application process (such as Microsoft Word) through system calls (such as CreateProcess) or the Kingsoft control interface. Document Loading and Window Ready: Instructs the newly launched Word process to open the specified document, and Word will create a main window containing the document content; Window handle acquisition: The local middleware obtains the handle of the Word document window through the Kingsoft control or system API (such as FindWindow); Browser container identification: The browser frontend sends a handle to the container window created by the browser for the embedded document to the middleware via WebSocket. This container is typically a specific... The system window corresponding to the element; S3. Window Mounting: The local middleware calls the system API to set the Word window as a child window of the browser container window. This operation is the key to achieving embedding, which makes the rendering of the Word window completely handled by the operating system and Word itself, with the browser only providing a display area. Window style adjustment: The middleware further adjusts the style of the Word window, such as removing the border and resizing it to fill the container, to achieve a visually seamless integration; S4. Interactive Message Forwarding and Synchronization: Event Capture and Upload: When a user executes business code, the front-end script captures the event and sends it to the local middleware via WebSocket; Message conversion and delivery: The local middleware converts these operation information into operating system messages (such as Windows messages) and sends them precisely to the mounted Word window; Native response: After receiving a message, the Word window executes the same processing logic as the original program (such as cursor movement, text input, and rendering refresh), giving users a native-level editing experience; Secure inter-process communication: Digital signatures can be used to verify the integrity of the message source in HTTP requests and WebSocket messages, and sensitive data can be encrypted to ensure the security of cross-process transmission; Rendering resource isolation: Each Office / WPS application process enjoys an independent GPU context and memory space, avoiding resource competition with browser rendering tasks and improving graphics rendering performance; Fault isolation: Due to process isolation, the unexpected crash of the Office / WPS application process will not cause the browser rendering process or the local middleware process to shut down, greatly enhancing overall stability; Performance optimization strategies: Compress the transmitted rendering data and implement caching strategies in the middleware or frontend to reduce network transmission overhead and improve response speed.

[0009] A cross-process rendering system for browsers and native application windows, enabling secure inter-process communication using the following mechanism; Secure cross-process communication mechanism: It adopts a cooperative communication protocol based on HTTP for session initialization and control, and WebSocket for full-duplex real-time data exchange. The mechanism is the "blood vessel" connecting isolated processes, ensuring the reliability, efficiency and security of instruction and data transmission.

[0010] The beneficial effects of this invention are as follows: **Intrinsically Enhanced Security:** By isolating potentially dangerous operations in independent processes outside the browser sandbox through a cross-process architecture, strictly adhering to the principle of least privilege, it fundamentally eliminates the risk of malicious web pages attacking the system through plugin interfaces. **Superior Stability:** Process isolation ensures that failures of individual components (especially local applications) are controlled within their respective process scopes, preventing overall browser crashes and significantly enhancing system fault tolerance. **True Cross-Platform and Browser Compatibility:** Communication is based on standard HTTP / WebSocket protocols, widely supported by all modern browsers, enabling seamless operation on browsers with different kernels such as Chrome, Edge, and Firefox, overcoming the compatibility challenges of PPAPI. **Performance Optimization and Efficient Resource Utilization:** Independent Office / WPS application processes can fully utilize system resources for rendering, avoiding lag caused by resource contention within a single browser process, especially beneficial for the smooth display of complex documents. **Good Maintainability and Scalability:** Each process module has clear responsibilities and can be independently upgraded and maintained. The WebSocket-based communication architecture facilitates the extension of new functions, such as real-time collaborative editing and remote control. Native Experience and High-Performance Rendering: By directly mounting native application windows, users can obtain a high-fidelity visual experience and smooth interactive response that is completely consistent with local operation. This is because all rendering is directly handled by the native application and operating system graphics stack, resulting in minimal performance overhead. Flexible Rendering Strategies: This invention supports both native window mounting and data stream rendering modes, which can be flexibly selected or combined according to actual needs (such as requirements for interface consistency, network environment, and security strategies), achieving a high degree of adaptability. Example 2

[0011] Process environment configuration: Browser rendering process: Taking Chrome 115 as an example, its rendering process runs in a strict sandbox environment; Local Middleware Process: A standalone application written in C, installed locally on the user's computer, which can be configured as a background service that starts with the system or manually started by the user, and comes pre-integrated with the Kingsoft Control SDK; Office / WPS application processes: The locally installed Microsoft Word 2016 or the latest version of WPS Office is running in its normal mode; Cross-process rendering process: Users visit web pages that integrate this technology and click the "Open Word Document" button; The front-end script within the page intercepts and forwards the request to the middleware service, and prevents the browser from attempting to load the PPAPI plugin; When the local middleware service receives the request, it starts a new Word process (or reuses an existing instance) and dynamically binds to a WebSocket port (such as 8081), returning the port number via an HTTP response. The browser frontend establishes a WebSocket connection with ws: / / localhost:8081 based on the returned port number; The front end sends a document open command through this WebSocket connection; The local middleware uses the Kingsoft control to open a specified document in Word. The Kingsoft control obtains the Word window handle (HWND). The browser frontend sends a "mount request" to the local middleware via a WebSocket message. This request contains a handle to the specific container window that the browser has created for the embedded document (usually provided by a browser extension or the host application). After receiving the handle, the local middleware calls the system API (such as SetParent) to set the Word window as a child window of the browser container window, and adjusts its position and size to fill the container to achieve visual embedding. At the same time, it may modify the style of the Word window to achieve seamless integration. User actions within the browser (such as scrolling and clicking) are transmitted back via WebSocket. The middleware then converts these actions into Windows messages and sends them to the mounted Word window, completing a native-level interactive loop.

[0012] Effect verification To verify the effectiveness and superiority of the technical solution of this invention, the following tests need to be conducted and compared with the traditional PPAPI plugin solution.

[0013] Stability verification: Testing method: Fault injection testing was used. During document editing, the crash of the local Office / WPS application process was artificially simulated (e.g., by forcibly terminating the process through Task Manager).

[0014] Expected Results and Comparison: The solution of this invention ensures that the browser process and other tabs within the browser remain stable, without crashing or freezing. Users can resume document editing via the "Reload" button on the page, and the middleware service automatically restarts a new Office process and remounts the window.

[0015] Traditional PPAPI solution: The browser process has a very high probability of becoming unresponsive or crashing, resulting in the loss of all data in the open tabs.

[0016] Verification metrics: browser process crash rate, data recovery success rate.

[0017] Security verification Testing method: Use browser developer tools and network packet capture tools to monitor the network requests and system resource access behavior of web page scripts.

[0018] Expected Results and Comparison: The solution of this invention is as follows: Monitoring shows that all network requests from the web page scripts are directed only to specific ports on localhost (such as 9582 and 8081), with no requests directly accessing the local file system, registry, or other system-level APIs. All operations on local resources are performed by trusted local middleware processes in a controlled environment.

[0019] Traditional PPAPI solutions: Plugins run inside the browser process and have high system privileges, making it difficult to isolate and monitor their system access behavior at the network level, which poses potential security risks.

[0020] Verification metrics: Number of system calls from web page scripts, number of attempts to call sensitive APIs;

[0021] Multiple instances and compatibility verification: Test method: Open multiple documents of different types (such as Word, Excel, PPT) simultaneously in the same browser page, and test in different browsers (Chrome, Edge, Firefox);

[0022] Expected Results and Comparison: This invention provides a stable solution that supports concurrent editing of multiple documents. Each document runs in an independent Office application process, ensuring isolation and preventing interference between them. It maintains consistent functionality and performance across all modern browsers.

[0023] Traditional PPAPI solution: poor stability with multiple instances, prone to conflicts; cannot be used in non-Chromium-based browsers;

[0024] Verification metrics: number of concurrent instances running stably, cross-browser functional consistency.

Claims

1. A cross-process rendering system for a browser and a native application window, comprising: include: Rendering instructions are passed across processes: Browser process: responsible for providing a container, intercepting user input, and communicating with middleware. The middleware process forwards instructions to the Office application process. Local middleware process: the core hub, responsible for communication bridging, program launch, window mounting, and message forwarding; Office / WPS application process: runs independently and is responsible for the realistic rendering and editing logic of documents; Native Window Mounting and Hybrid Rendering: After opening a specified document using the Office application, the Kingsoft Controls obtain the handle of the Word application's main window. The local middleware process uses the operating system API, Windows' SetParent function, to set the Word window as a browser-specific child window. The browser process informs it of the handle or identifier of the child window through a communication channel. This operation achieves seamless visual embedding between the Word native window and the browser window. The content of the Word window is directly rendered by the system and naturally composited with other parts of the browser, providing native rendering effects and high-fidelity interaction that are indistinguishable from native software and support hardware acceleration. The local middleware process, in collaboration with the Kingsoft Controls, adjusts the style and handles message hooks for the mounted Word window. Real-time synchronization mechanism: A bidirectional cross-process communication channel is established. The full-duplex communication channel provided by WebSocket ensures low-latency synchronization between user operations and visual feedback. The local middleware manages multiple independent WebSocket sessions, supporting the simultaneous opening and editing of multiple documents. Each session corresponds to an independent Office / WPS application process instance, realizing true multi-document concurrent rendering and isolation.

2. A cross-process rendering method of a browser window of a native application based on the system of claim 1, characterized in that, Includes the following steps; S1. Communication Establishment and Command Issuance: Front-end interception and connection: The browser front-end script intercepts the user's request to open the document, prevents default plugin behavior, and establishes a connection with the local middleware service via HTTP, negotiating to establish a WebSocket real-time communication channel; Command encapsulation and sending: The front-end sends document operation commands to the local middleware via WebSocket; S2. Local Program Launch: Upon receiving the instruction, the local middleware launches the local target application process via system calls and the Kinglock control interface; Document Loading and Window Readiness: The newly launched Word process is instructed to open the specified document, and Word creates a main window containing the document content; The local middleware obtains the handle of the Word document window through the Kinglock control or the system API: FindWindow; The browser frontend sends the handle of the container window created by the browser for the embedded document to the middleware via WebSocket. This container is a specific... The system window corresponding to the element; S3. Window Mounting: The local middleware calls the system API to set the Word window as a child window of the browser container window. This operation is the key to achieving embedding, so that the rendering of the Word window is completely handled by the operating system and Word itself, and the browser only provides a display area. The middleware further adjusts the style of the Word window, including removing the border and resizing it to fill the container, to achieve visually seamless embedding. S4. Interactive Message Forwarding and Synchronization: Event Capture and Upload: When a user executes business code, it is captured by the front-end script and sent to the local middleware via WebSocket. The local middleware converts these operation information into operating system messages and sends them precisely to the mounted Word window. After receiving the message, the Word window executes the same processing logic as the original program: cursor movement, text input, and rendering refresh, giving the user a native editing experience.

3. The cross-process rendering system of browser and native program window according to claim 1, wherein: Rendering instructions are passed across processes, including: Secure inter-process communication: Digital signatures can be used to verify the integrity of the message source in HTTP requests and WebSocket messages, and sensitive data can be encrypted to ensure the security of cross-process transmission; Rendering resource isolation: Each Office / WPS application process enjoys an independent GPU context and memory space, avoiding resource competition with browser rendering tasks and improving graphics rendering performance; Fault isolation: Due to process isolation, the unexpected crash of the Office / WPS application process will not cause the browser rendering process or the local middleware process to shut down, greatly enhancing overall stability; Performance optimization strategies: Compress the transmitted rendering data and implement caching strategies in the middleware or frontend to reduce network transmission overhead and improve response speed.

4. The cross-process rendering system of a browser and native program window of claim 3, wherein; Secure inter-process communication uses the following mechanisms; Secure cross-process communication mechanism: It adopts a cooperative communication protocol based on HTTP for session initialization and control, and WebSocket for full-duplex real-time data exchange. The mechanism is the "blood vessel" connecting isolated processes, ensuring the reliability, efficiency and security of instruction and data transmission.