Cross-platform session context synchronization method and system based on browser request interception

Abstract

The invention provides a cross-platform session context synchronization method and system based on browser request interception, and is applied to the technical field of browser extension and network data interaction. The method comprises the steps of loading site strategy configuration to define a data mapping and input container positioning rule, injecting proxy codes to monitor a page request state, locking a target input container in a DOM tree based on a multi-dimensional score, intercepting a session submission request and analyzing an original load, retrieving a historical context and converting the historical context into an implicit data segment according to a mapping relation, combining the data to an original load to generate a recombination request and then sending the recombination request; according to the scheme, session context non-inductive synchronization of cross-heterogeneous platforms can be realized on the premise of not depending on a fixed selector and not changing a page UI (User Interface), the continuity of user memory by different platforms is kept, the robustness of element positioning and the accuracy of an operation time sequence are improved, and the user experience is improved. The problem of data islands is effectively solved, and man-machine interaction continuity is enhanced.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a cross-platform session context synchronization method and system based on browser request interception. Background Technology

[0002] In recent years, online question-answering platforms based on large language models (referring to neural network models with large-scale parameters and complex structures) have been widely used. However, the independence between different platforms creates data silos, resulting in the inability to share user conversation history, personal preferences, and other conversation context information (represented as user memory in the large model) across platforms. Users must repeatedly input background information when switching platforms, severely impacting interaction efficiency and user experience continuity.

[0003] In existing technologies, single-platform enhancement plugins rely on fixed selectors to locate page elements. When the target website updates its front-end code, causing changes to the Document Object Model (DOM) structure or style class names, the functionality becomes ineffective, exhibiting poor robustness. Aggregated chat clients only integrate the access interface, failing to integrate underlying session data and thus unable to achieve unified contextual memory. Clipboard or local knowledge base auxiliary tools require users to manually copy and paste, which is an explicit operation, interrupting the natural conversation flow and failing to achieve synchronization between automation and seamlessness. Furthermore, none of the above solutions effectively address the technical challenges of stable identification of interactive components in dynamic web environments, accurate determination of business readiness status under complex network behavior, and injection of contextual data without altering the user interface.

[0004] Therefore, existing technologies lack a cross-platform session context synchronization mechanism that can achieve high robustness, low intrusion, and seamless user experience across heterogeneous network applications.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of the present invention, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] In view of this, the present invention provides a cross-platform session context synchronization method and system based on browser request interception, aiming to solve the problems of session data isolation between large model platforms, inability to communicate with each other's contexts, element positioning relying on fragile selectors, and context injection process interfering with user interaction in the prior art. By loading site strategy configuration, heterogeneous data mapping and multi-dimensional scoring positioning of input containers are realized. Combined with request proxy monitoring and seamless data injection mechanism of the page's native script environment, the automatic synchronization and accurate integration of cross-platform session contexts can be achieved without relying on a fixed DOM structure or changing the front-end UI.

[0007] This invention provides a cross-platform session context synchronization method based on browser request interception, the method comprising:

[0008] Load the site policy configuration that matches the Uniform Resource Locator (URL) of the current page. The site policy configuration defines the mapping relationship between heterogeneous data and the Uniform Memory Protocol (UNMIP) format, as well as the input container positioning rules.

[0009] Inject proxy monitoring code into the native script runtime environment of the current page. The proxy monitoring code proxies the native network request objects of the page in order to collect statistics on the request status of the target endpoint.

[0010] In response to user interaction on the current page, calculate node scores in the document object model tree based on input container positioning rules and lock the target input container;

[0011] Intercept session commit requests triggered by interactive operations and parse the original request payload of the session commit request;

[0012] Retrieve the associated historical session context based on the current user's identity, and convert the historical session context into an implicit data segment adapted to the current page based on the mapping relationship;

[0013] The implicit data segments are merged into the original request payload to generate a reassembled request payload, which is then used to replace the original request payload before being sent to the server.

[0014] In some optional embodiments, proxy monitoring code is injected into the native script runtime environment of the current page to collect statistics on the request status of the target endpoint, including:

[0015] Utilize browser extension interfaces to inject proxy monitoring code into the page's native script execution environment;

[0016] The asynchronous request object and the interface object retrieval are rewritten globally on the page by proxy monitoring code to add request counting logic;

[0017] Identify critical business requests based on the Uniform Resource Locator (URL) prefix whitelist in the site policy configuration;

[0018] Maintain a concurrent request count. Increase the concurrent request count when a critical business request is detected, and decrease the concurrent request count when the critical business request response ends or fails. Determine the page's network readiness status based on the concurrent request count.

[0019] In some optional embodiments, determining the page network readiness status based on the concurrent request count value further includes:

[0020] After the concurrent request count reaches zero, a silent time window timer is started.

[0021] If no new business-critical requests are detected within the silent time window and no structural changes occur in the document object model tree, a network ready signal is generated.

[0022] The network ready signal is sent to the extension isolation environment through the window message communication mechanism.

[0023] In some optional embodiments, for pages employing streaming protocols, tracking the request status of the target endpoint further includes:

[0024] Monitor the establishment and disconnection status of streaming connections;

[0025] When a streaming response is detected to be active, the document object model observer is used to listen for changes in the child nodes of the page message container node.

[0026] When the streaming response remains connected but the time for the child node changes of the message container node to stop exceeds a preset threshold, it is determined that the logical transmission of the current streaming response has ended.

[0027] In some optional embodiments, node scores are calculated in the document object model tree based on input container positioning rules, including:

[0028] Traverse the candidate nodes in the document object model tree and extract the semantic attributes, geometric position attributes, and inclusion relationship attributes of each candidate node.

[0029] If the semantic attribute of a candidate node is declared as a text input box or has an editable attribute, assign it a first preset score;

[0030] If the geometric position of a candidate node is located within the bottom preset area of ​​the visible viewport, a second preset score is assigned.

[0031] If a candidate node contains a form label or is located in the footer area, assign it a third preset score;

[0032] The first preset score, the second preset score, and the third preset score are weighted and summed to obtain the final positioning score for each candidate node.

[0033] In some optional embodiments, after locking the target input container, a performance optimization step is further included:

[0034] When the calculated final location score exceeds the locking threshold, the corresponding candidate node is marked as a locked target;

[0035] Stop global change monitoring of the document object model tree and start local property monitoring for locked targets;

[0036] Resume global change monitoring of the Document Object Model (DOM) tree only when a change in page routing state is detected or a locked target is removed from the DOM tree.

[0037] In some optional embodiments, restoring global change monitoring of the document object model tree includes:

[0038] When restoring global change monitoring, a debouncing strategy is adopted to merge multiple document object model change events within a preset time window into a single processing step.

[0039] After the preset time window ends, a new round of node score calculation is triggered to re-lock the target input container.

[0040] In some optional embodiments, the calculation of node scores also includes a visibility verification step:

[0041] Obtain the calculation style of the candidate nodes and check their display and visibility attributes;

[0042] If the width or height of a candidate node is less than a preset pixel threshold, or if its display attribute indicates that it is hidden, then the final positioning score of the candidate node will be forcibly set to zero.

[0043] In some optional embodiments, merging implicit data segments into the original request payload to generate a reassembled request payload includes:

[0044] A set of zero-width character sequences that are invisible to the page rendering engine is used as sentinel markers;

[0045] The historical session context is encapsulated between sentinel tags to form implicit data segments;

[0046] Append the implicit data segment to the end of the user input text field in the original request payload;

[0047] The zero-width character sequence configuration enables the server-side model to recognize the boundaries of the historical session context, while ensuring that implicit data segments do not occupy visible space when displayed on the front-end interface of the page.

[0048] In some optional embodiments, merging implicit data segments into the original request payload to generate a reassembled request payload further includes:

[0049] Parse the data structure type of the original request payload;

[0050] If the data structure type is in Object Markup Language format, then predefined context key-value pairs are added to the original request payload, and the historical session context is populated into the context key-value pairs;

[0051] If the data structure type is a form data format, a hidden field is appended to the form data, and the historical session context is used as the value of the hidden field.

[0052] In some optional embodiments, the method further includes the step of processing the server's response data:

[0053] Intercept session response data returned by the server;

[0054] Based on the response extraction rules defined in the site policy configuration, new Q&A content is extracted from the session response data using regular expressions;

[0055] The newly added Q&A content is cleaned into a unified memory protocol format data containing roles, content, and timestamps;

[0056] The cleaned data is stored in a local database using an incremental deduplication algorithm.

[0057] In some optional embodiments, an incremental deduplication algorithm is used to store the cleaned data in a local database, including:

[0058] Generate a unique content hash value for each newly added question and answer;

[0059] Check if a unique content hash value exists in the local database;

[0060] If it does not exist, the question and answer content will be written to the local database and its source platform and session identifier will be marked.

[0061] If it exists, update the last active timestamp of that Q&A content.

[0062] In some optional embodiments, the method further includes a cross-domain identity synchronization step:

[0063] After detecting that the user has successfully logged into the current page, retrieve the user's identity identifier from the local storage or session storage of the current page;

[0064] Bind the user's identity to the extension's global user account;

[0065] Download the historical session context of other platforms stored under the global user account from the remote server and cache it in the extension's local storage.

[0066] In some optional embodiments, loading a site policy configuration that matches the current page's Uniform Resource Locator includes:

[0067] Check if the latest policy configuration for the current page exists in local storage;

[0068] If the policy configuration does not exist or has expired, an asynchronous request is sent to the configuration server to obtain the latest site policy configuration.

[0069] Site policy configurations are distributed as script code and executed in an extension isolation environment to generate specific location rule objects.

[0070] In some optional embodiments, a network routing optimization step is also included before sending to the server:

[0071] Get the server-side domain name resolution result for the current page;

[0072] If the DNS resolution result indicates that the server is located overseas, the target address of the request will be modified to the preset edge acceleration node address through the Domain Name System policy.

[0073] The reassembly request payload is forwarded to the origin server by using the backbone network through edge acceleration nodes.

[0074] This invention provides a cross-platform session context synchronization system based on browser request interception. The system runs in the extension environment of a computer terminal and includes:

[0075] The strategy configuration loading module is configured to parse the site strategy configuration that matches the Uniform Resource Locator (URL) of the current page, establish a mapping index between heterogeneous data and the Uniform Memory Protocol (UNMIP) format, and initialize the input container positioning rules.

[0076] The native environment monitoring bridging module is configured to deliver proxy monitoring code to the native script execution environment of the current page. The proxy monitoring code takes over the native network request objects of the page to establish a cross-environment request status statistics link.

[0077] The container positioning and locking module is configured to monitor the user's interaction behavior on the current page and drive the node scoring calculation engine of the document object model tree according to the input container positioning rules, thereby locking the target input container.

[0078] The request fusion processing module is configured to capture session submission requests triggered by interactive behavior, parse the original request payload, call historical session context data, generate implicit data segments adapted to the current page based on the mapping index, and reassemble the implicit data segments into the original request payload.

[0079] The communication sending module is configured to replace the original request payload with a reconstructed request payload to complete the delivery of the request to the server.

[0080] In some optional embodiments, the native environment monitoring bridging module includes a bidirectional communication channel and a native proxy engine;

[0081] The native proxy engine resides in the native script runtime environment of the page and is configured with a request interceptor and a counter registry, which are used to update the concurrent count value in the counter registry when a business-critical request that matches the prefix whitelist is intercepted.

[0082] The bidirectional communication channel is configured to trigger a network ready instruction and transfer it across processes to the extension environment when the concurrent count value in the counter registry reaches zero and the silent window condition is met.

[0083] In some optional embodiments, the container location locking module integrates a resource scheduling controller;

[0084] The resource scheduling controller is configured to maintain a global listening state machine. When the score output by the node scoring calculation engine is lower than the locking threshold, the global document object model observer is kept running. When the score exceeds the locking threshold, the global listening state machine is triggered to transition, forcibly suspending the global document object model observer and activating the local attribute listener for the locked target input container to reduce the system's computing resource consumption.

[0085] In some optional embodiments, the request fusion processing module includes an implicit encoder;

[0086] The implicit encoder is configured to load a pre-defined zero-width character sentinel sequence, serialize and encapsulate historical session context data between the zero-width character sentinel sequences, generate text data blocks that are invisible to the page rendering engine but can be parsed by the server at the binary level, and merge them into the original request payload.

[0087] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention.

[0088] The cross-platform session context synchronization method and system based on browser request interception of the present invention has the following beneficial effects:

[0089] This invention achieves seamless synchronization of cross-platform session context and maintains the continuity of user memory across different platforms through request interception and implicit data injection. It employs a multi-dimensional scoring algorithm for input container positioning, improving robustness in dynamic pages; monitors network status through a script proxy in the page's native script runtime environment, ensuring the accuracy of operation timing; encapsulates context data using zero-width characters, achieving data fusion without altering the user interface; and combines unified protocol mapping and configurability strategies to support flexible expansion across heterogeneous platforms, effectively solving the problems of fragile positioning, explicit interaction, and data silos in existing technologies. Attached Figure Description

[0090] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings.

[0091] Figure 1 This is a flowchart of a cross-platform session context synchronization method based on browser request interception according to an embodiment of the present invention;

[0092] Figure 2 This is a schematic diagram of the structure of a cross-platform session context synchronization system based on browser request interception according to an embodiment of the present invention;

[0093] Figure 3 This is an overall interaction diagram of a cross-platform session context synchronization method based on browser request interception according to an embodiment of the present invention;

[0094] Figure 4 This is a schematic diagram of the interaction flow of a cross-platform session context synchronization method based on browser request interception according to an embodiment of the present invention. Detailed Implementation

[0095] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that the invention will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0096] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0097] The flowchart shown in the attached diagram is merely an illustrative example and does not necessarily include all steps. For example, some steps may be broken down, while others may be combined or partially combined. Therefore, the actual execution order may change depending on the specific circumstances.

[0098] In a browser environment, web application interactions typically involve data exchange with backend services via asynchronous network requests, and changes to the frontend DOM structure are strongly correlated with the initiation of these network requests. By proxying global network request interfaces (such as fetch and XMLHttpRequest) in the page's native script runtime environment, the lifecycle of requests can be intercepted, observed, and controlled without modifying the page code, enabling precise monitoring of business endpoints. This mechanism, combined with URL matching rules, can identify request traffic for specific functions and reflect the current communication load of the page by maintaining a concurrency count, thereby determining whether the page is in a stable and usable state. Simultaneously, the Document Object Model (DOM), as a structured representation of page content, possesses semantic attributes, geometric layouts, and hierarchical relationships that can be analyzed by the program. Utilizing a multi-dimensional feature-weighted scoring method, robust identification of target elements can be established, avoiding positioning failures caused by reliance on volatile CSS selectors. Furthermore, user-submitted data is encapsulated in a specific format within the network request payload for transmission. By parsing and modifying this payload, additional information can be embedded while preserving the original input, enabling seamless data injection. If this type of injection uses a character sequence invisible to the rendering engine as a separator, it can ensure that the server receives the complete information combination without affecting the front-end display. The entire process relies on the isolation and communication mechanism between the extension and the page script runtime environment to complete cross-domain data integration while ensuring security. The above methods together constitute a technical path to achieve context awareness and data collaboration in dynamic, heterogeneous web applications, enabling the system to stably identify user intent, accurately grasp the timing of operations, and automatically complete context information in a non-intrusive manner, ultimately achieving the technical goal of cross-platform session memory continuity. It should be noted that the session context in this specification is represented at the business level as user memory data in a large model.

[0099] like Figure 1 As shown, this embodiment of the invention provides a cross-platform session context synchronization method based on browser request interception. The method includes the following steps:

[0100] Step S100: Load the site policy configuration that matches the Uniform Resource Locator of the current page.

[0101] In one embodiment, when a user accesses a target website through a browser, the extension obtains the URL of the current tab and looks up the corresponding site policy configuration based on the main domain of that URL. This site policy configuration defines mapping relationships for data format conversion and location rules for identifying page elements. The mapping relationships are used to adapt heterogeneous data structures from different platforms to a unified memory protocol format, while the location rules provide a basis for subsequent judgment in locking the input container in the document object model tree. In one implementation, the policy configuration is loaded and parsed as an executable script, generating specific rule objects in the extension's isolated environment. In other optional implementations, the policy configuration can be implemented using a static JSON file combined with runtime compilation logic, or it can be dynamically distributed via a remote configuration center and then instantiated locally.

[0102] Step S200: Inject proxy monitoring code into the native script runtime environment of the current page to collect statistics on the request status of the target endpoint.

[0103] In one embodiment, a script injection mechanism provided by a browser extension is used to inject code with network monitoring capabilities into the page's native script runtime environment (Main World). This proxy monitoring code enhances the functionality of the page's original network request interfaces, enabling them to capture request lifecycle events of specific business endpoints without altering their original behavior. By listening to and counting these events, observability of the overall network activity state of the page is achieved. In one implementation, this mechanism achieves transparent observation of request traffic by rewriting the global asynchronous communication interface; in other alternative implementations, state tracking in streaming scenarios can also be supported by hijacking the WebSocket constructor or replacing the EventSource implementation.

[0104] Step S300: In response to the user's interaction on the current page, calculate the node score in the document object model tree based on the input container positioning rules and lock the target input container.

[0105] In one embodiment, when a user initiates input-based interaction with the page, an analysis of the DOM tree is initiated. The system extracts multi-dimensional features from candidate nodes based on preset positioning rules and calculates a probability score for each node to become a target input area, considering factors such as semantics, layout, and structural relationships. The node with the highest score is considered the container for the current session interaction and enters a locked state. This locking result is used to precisely trigger subsequent data injection. In one implementation, the scoring process uses a weighted fusion algorithm to quantitatively evaluate multiple feature indicators; in other optional implementations, a machine learning-based classification model can be introduced to prioritize candidate nodes, or a rule engine-driven decision chain approach can be used for dynamic determination.

[0106] Step S400: Intercept the session submit request triggered by the interactive operation and parse the original request payload of the session submit request.

[0107] In one embodiment, when a user completes input and triggers a send action, the system captures the upcoming session submission request through the aforementioned established network monitoring channel. This request is temporarily blocked before actual transmission and enters the processing pipeline. The system performs syntax parsing on the payload portion of the request to restore its internal data structure for subsequent insertion of context information. The parsing method is adaptively selected based on the actual encoding type of the payload to ensure correct reading of the user's original input. In one implementation, the parsing process supports mainstream data serialization formats such as JSON and FormData; in other optional implementations, it can also be extended to support decoding of customized formats such as XML and Protocol Buffers.

[0108] Step S500: Retrieve the associated historical session context based on the current user identity, and convert the historical session context into an implicit data segment adapted to the current page based on the mapping relationship.

[0109] In one embodiment, the system uses the current user's identifier as an index to query related past conversation records from local or cached storage. These records contain user preferences, recent conversation topics, and other background information that contributes to contextual coherence. Subsequently, based on the mapping relationships defined in the site policy, this structured contextual data is transformed into a data representation format suitable for the current target platform. The transformed data is encapsulated into a special data unit that does not affect the front-end rendering performance, namely an implicit data segment. In one implementation, this data segment is visually hidden by wrapping it with an invisible character sequence; in other alternative implementations, the same functionality can be achieved by adding hidden fields with naming conventions, embedding objects using reserved attribute names, etc.

[0110] Step S600: Merge the implicit data segments into the original request payload to generate a reassembled request payload, and use the reassembled request payload to replace the original request payload and send it to the server.

[0111] In one embodiment, the system merges the generated implicit data segment with the original request payload parsed in step S400 to construct a new request body. This reassembly process maintains the integrity of the original fields while seamlessly integrating contextual information into the data stream. After reassembly, the original request payload is completely replaced and returned to the underlying network interface for final transmission. The entire process is transparent to the user and does not depend on modifications to the page UI. In one implementation, the merging operation is directly appended to the end of the user-input text; in other alternative implementations, data fusion can also be achieved by adding key-value pairs to the structured data body, inserting custom header fields, or using URL query parameters.

[0112] The aforementioned technical features form a tightly coordinated workflow: site policy configuration provides the platform-adaptive metadata foundation for the entire system, enabling it to cross heterogeneous applications; proxy monitoring code builds an observable bridge between the extended environment and the native page environment, solving the state blind spot problem caused by sandbox isolation; the container positioning method based on a scoring mechanism eliminates the dependence on fixed selectors, and can still stably identify interaction entry points in environments with frequent SPA updates; the request interception and payload reassembly mechanism enables context injection at the data link layer, avoiding intrusive modifications to the UI. The combination of these three features achieves seamless synchronization of session context across multiple platforms without changing user operating habits or disrupting page visual consistency, effectively overcoming the technical shortcomings of existing solutions such as high fragility, explicit interaction, and fragmented experience.

[0113] Compared with existing technologies, this embodiment, through the above-described solution, can achieve automated and low-interference synchronization of session context data between multiple independent large language model platforms without modifying the target website code or increasing the user's additional operational burden; by leveraging configuration strategies and dynamic positioning mechanisms, it significantly improves the robustness and maintainability of the system in the face of frequent front-end iterations; by completing data fusion at the network request level, it avoids the functional failure problem caused by changes in the DOM structure of traditional UI-level plugins, while ensuring the accuracy and timeliness of cross-platform data interoperability.

[0114] In one specific implementation, proxy monitoring code is injected into the native script runtime environment of the current page to collect statistics on the request status of the target endpoint, including:

[0115] By leveraging the script injection interface provided by browser extensions, a proxy monitoring code for monitoring network activity is injected into the native script execution environment of the current page. First, this proxy monitoring code rewrites asynchronous request objects (such as `window.fetch`) and traditional fetch interface objects (such as `XMLHttpRequest.prototype.send`) in the page's global scope, embedding a request counting mechanism within their call logic. Specifically, each time a new network request is initiated, the proxy code checks whether the target Uniform Resource Locator (URL) of the request matches the business endpoint prefix whitelist defined in the site policy configuration; if it matches, it is determined to be a business request, and the concurrent request count is incremented.

[0116] After the Promise object returned by the original request completes its asynchronous processing flow (whether it is a successful response or an error occurs), the proxy code executes the callback function to decrement the concurrent request count, thereby dynamically maintaining the number of active requests on the current page.

[0117] Based on the changing trend of the concurrent request count, the system continuously assesses the overall network load status of the page and determines whether to enter a suitable window for performing context injection or data collection.

[0118] In other alternative implementations, the proxy monitoring code can also perform similar request state tracking for long-connection-based streaming protocols by intercepting WebSocket constructors or listening to SSE (Server-Sent Events) connection events; or, it can use a proxy to wrap all requests made via third-party HTTP client libraries (such as Axios) to ensure coverage of the diverse network call paths in modern single-page applications.

[0119] Through the above solution, this embodiment enables fine-grained perception of page-level network activity and effectively identifies the business request cycle that affects user interaction status. Compared with existing technologies, this embodiment not only breaks through the execution environment isolation limitation between browser extension scripts and page native scripts, achieving transparent hijacking and monitoring of native network interfaces, but also avoids invalid statistics on irrelevant resource requests by introducing a request classification mechanism based on whitelist filtering, significantly improving the accuracy of status judgment and the overall operating efficiency of the system.

[0120] In one specific implementation, determining the page's network readiness based on the concurrent request count further includes: when the concurrent request count maintained by the agent monitoring code reaches zero, a silent time window timer with a preset duration of 200 milliseconds is first started. Specifically, this timer is implemented using the `setTimeout` function to monitor whether any business requests conforming to the Uniform Resource Locator (URL) prefix whitelist defined in the site policy configuration are triggered again within this time window. If a new business request is detected before the timer expires, the current timer is immediately cleared and the system remains in a non-ready state; if the timer executes completely until its timeout and no new request initiation event is received during this period, the system proceeds to the next verification phase.

[0121] Further checks are performed to determine if any structural changes have occurred to the Document Object Model (DOM) tree. This determination is made using a lightweight MutationObserver instance, which only listens for changes in the child nodes of an element (i.e., changes in the childList type), and does not listen for changes in attributes or text content. If no childList changes are observed within the silent time window, the DOM structure is considered to be in a stable state. At this point, the system generates a network ready signal and sends it to the extension's content script runtime environment via the window.postMessage interface in a specific message format (e.g., { type: 'NETWORK_IDLE', timestamp: Date.now()}). Upon receiving this message, the content script forwards it to the extension's background script to trigger subsequent data collection or injection operations.

[0122] In other alternative implementations, the duration of the silent time window can be dynamically adjusted based on the target website's historical network behavior, for example, calculated based on the average delay from the end of the last request to the completion of the page's visual update over the past five sessions; or, the criteria for determining DOM structural changes can be replaced by listening for subtree changes to specific container nodes (such as the root node of a dialog list) and filtering them in conjunction with a change magnitude threshold (such as considering a single change with more than 10 new nodes as a significant change) to improve the accuracy of the judgment.

[0123] By employing the above approach, this embodiment can further eliminate the risk of misjudgment caused by sudden surges in requests or asynchronous DOM rendering, after the concurrent requests have ended, thereby more accurately identifying the true idle state of the page. Compared with existing technologies, this embodiment significantly improves the accuracy and robustness of network readiness judgment by introducing a dual verification mechanism of time dimension and structural stability, avoiding premature execution of context injection operations before the page is fully rendered or data is still loading, thus ensuring the reliability of data synchronization and the overall stability of the system.

[0124] In one specific implementation, based on the above embodiments, for pages using streaming protocols, the statistics of target endpoint request status further incorporate a joint judgment mechanism based on the streaming connection lifecycle and dynamic changes in the DOM. First, the native environment monitoring bridging module monitors the initialization process of the streaming communication channel by detecting the creation of WebSocket instances or the establishment of Server-Sent Events (SSE) connections in the page scripts. Specifically, after injection, the proxy monitoring code overrides the WebSocket constructor and the EventSource interface. When it detects that the target URL of a newly established connection matches the streaming endpoint prefix defined in the site policy configuration, it determines that the streaming response is active and initiates the corresponding status tracking logic.

[0125] Then, the system activates a lightweight MutationObserver instance, specifically bound to the message container node specified by the strategy configuration on the page—this node is typically the parent DOM element carrying the model's segmented output content. This observer continuously monitors changes to its child nodes, recording the timestamp of each newly added text segment. Next, the system sets a preset silence threshold, such as 1.5 seconds. With the streaming connection open, if no changes are observed in the child nodes of the message container within this time window, a logical transmission termination signal is triggered.

[0126] At this point, the system determines that the current round of streaming response has fully returned all content at the business logic level, even if the underlying connection has not yet been closed. This signal is passed to the content script environment of the extension program via the postMessage mechanism to drive the execution of subsequent operations, such as controlling the timing of context data retrieval or preparing for UI state updates.

[0127] In other alternative implementations, message container node identification can be achieved through several paths: in one implementation, the node can be directly located using a preset CSS selector in the strategy configuration; in another implementation, based on the characteristic of frequent text updates received within candidate nodes, the most likely message carrying area can be automatically derived through runtime dynamic sampling and access frequency analysis; in addition, for front-end frameworks that use custom event broadcasting for streaming progress, the endpoint of content generation can also be determined by intercepting specific CustomEvent event names.

[0128] Through the above solution, this embodiment can accurately distinguish between maintaining network connection and ending actual content delivery in streaming transmission, solving the problem of misjudgment of operation timing caused by long-term connection persistence. Compared with the prior art, this embodiment achieves accurate determination of the logical response completion time based on client-observable behavior without relying on explicit server-side end markers, thereby ensuring the correctness and timeliness of subsequent operations such as context synchronization and data collection, while avoiding performance overload caused by high-frequency minor updates.

[0129] In one specific implementation, node scores are calculated in the Document Object Model (DOM) tree based on input container positioning rules. The container positioning and locking module calculates the probability score of each candidate node as a target input container by analyzing the multi-dimensional attributes of each candidate node in the DOM tree. First, the system traverses the set of interactive nodes in the current page's DOM tree, filtering out elements with text input potential as candidate nodes, including but not limited to... <textarea>、< / textarea> (Has the contenteditable attribute) <input> Alternatively, elements with the semantic role of textbox. Specifically, for each candidate node, its semantic attributes, geometric position attributes, and inclusion relationship attributes with the page structure are extracted and quantitatively evaluated respectively.

[0130] For semantic attribute evaluation, if a candidate node's role attribute is textbox or log, or its contenteditable attribute is explicitly set to true, a first preset score is assigned. This score indicates that the node has the ability to directly receive user text input. For geometric position attribute evaluation, the system obtains the vertical coordinate distribution of the candidate node in the viewport and calculates the distance ratio of its bottom edge relative to the bottom of the viewport. If the node is located within a preset ratio range at the bottom of the visible area, a second preset score is assigned to reflect its high probability of being in the input area in a typical dialog interface layout. For evaluation of relational attributes, if the candidate node is... <form>If the direct or indirect child nodes of a tag, or the semantic identifier of its ancestor node, is a footer area, then a third preset score is assigned to enhance its weight as a session submission container.

[0131] Next, the system weights and sums the scores from the three dimensions according to predefined weighting coefficients to generate a final location score for each candidate node. The weighting coefficients are dynamically loaded based on site strategy configurations to ensure adaptability across different platform interface structures. After the scoring process is complete, the system sorts all candidate nodes based on the obtained scores and selects the node with the highest score as the target input container for subsequent operations. In other optional implementations, the multidimensional attributes may also include word matching accuracy of text placeholder content, node event listener registration status, or CSS class name pattern matching results of its parent container to further improve location accuracy.

[0132] Through the above solution, this embodiment can achieve high-precision recognition of user input containers in heterogeneous web page environments without relying on fixed CSS selectors or DOM paths, thus effectively addressing the selector failure problem caused by frequent front-end iterations. At the same time, the scoring mechanism based on multi-dimensional feature fusion enhances the adaptability and robustness of the positioning logic, enabling the system to maintain consistent behavior on dialogue platforms with different UI architectures.

[0133] In one specific implementation, after locking the target input container, a performance optimization step is also included: when the container positioning and locking module calculates that the final positioning score of a candidate node exceeds a preset locking threshold, the candidate node is marked as a locked target input container. First, the system stops running the global observer used to monitor changes in the entire document object model tree structure to avoid unnecessary computational overhead from continuous monitoring. Specifically, this global observer was originally configured to monitor node additions, deletions, and attribute changes in elements and their subtrees, triggering a debouncing delay-based score recalculation process after each change. Then, the system immediately starts a lightweight local attribute listener, which is bound only to the DOM node of the locked target input container and is specifically used to monitor changes in its attributes (such as class, style, contenteditable, etc.), thereby maintaining monitoring of the node's state with lower resource consumption.

[0134] Next, the system continuously monitors two types of external events that may affect the current locked state: first, the browser's popstate or hashchange events, used to identify routing behavior in single-page applications; and second, the removal or replacement of the locked target node from the current DOM tree through a local property listener mechanism. Once either of these events is triggered, the system determines that the current page context has undergone a substantial change, and the original location results are no longer valid. At this point, the current local property listener is immediately destroyed, and the global document object model observer is reactivated to restore the ability to scan the entire DOM tree, preparing for relocation in the subsequent page environment.

[0135] In some other alternative implementations, local property listeners can be further configured to listen only to changes in specific CSS class name prefixes, or to combine node MutationObserver and ResizeObserver to achieve multi-dimensional lightweight monitoring; the recovery mechanism of global listeners can also be supplemented by listening to page lifecycle events (such as visibilitychange) or network navigation events.

[0136] By employing the above approach, this embodiment significantly reduces the granularity and frequency of DOM environment monitoring during stable interaction phases, thereby effectively reducing CPU usage and memory consumption, and improving the system performance and response efficiency of browser extensions in long-running scenarios. Compared with existing technologies, this embodiment optimizes resource scheduling while ensuring accurate positioning by dynamically switching the monitoring range and level, avoiding the performance degradation caused by continuous global monitoring in traditional solutions.

[0137] In one specific implementation, based on the above embodiments, when the page routing state changes or the locked target is removed from the Document Object Model (DOM) tree, the system resumes global change monitoring of the DOM tree. First, the system recreates a MutationObserver instance covering the element subtree to capture subsequent DOM structure changes. Specifically, while starting this observer, a debouncing mechanism is enabled: all DOM change events within a preset time window are temporarily stored in a buffer queue, and node scoring calculations are not immediately triggered. Then, after the preset time window ends (e.g., 150 milliseconds), only one complete DOM traversal operation is performed, and the node scoring calculation engine is run based on the latest DOM structure of the current page to re-evaluate the final positioning score of each candidate node. Next, based on the new round of scoring results, the node with the highest score is selected as the new target input container and enters a locked state.

[0138] In some alternative implementations, the length of the preset time window can be dynamically adjusted based on the page type; for sites built with single-page application frameworks (such as React and Vue), a longer debouncing period (e.g., 200 milliseconds) is used, while a shorter period (e.g., 100 milliseconds) is used for static pages. In other alternative implementations, the debouncing logic can be replaced by a throttling function, which samples the DOM state and performs a score calculation at a fixed frequency (e.g., every 100 milliseconds) during periods of high-frequency changes, instead of waiting for complete silence.

[0139] By employing the above approach, this embodiment effectively avoids redundant scanning and resource waste caused by frequent DOM updates, significantly reducing CPU utilization. Compared to existing technologies, this embodiment, while ensuring positioning accuracy, optimizes the system's response efficiency and stability in dynamic page environments by introducing an event merging mechanism in the time dimension, making it particularly suitable for modern web application scenarios where front-end frameworks frequently re-render.

[0140] In one specific implementation, the container positioning and locking module further includes a visibility verification step when performing node score calculation: First, it obtains the calculated style information of the candidate node, specifically by calling the `window.getComputedStyle(node)` method to get the actual CSS property value of the node in the current rendering context. Then, it parses the `display` property; if the property value is `none`, or the `visibility` property value is `hidden`, the node is determined to be invisible. Next, it further checks the node's geometric dimensions: it obtains the layout width and height using the `node.getBoundingClientRect()` method; if the width is less than 10 pixels and the height is less than 10 pixels, the node is considered to lack actual interactive capabilities. Once any of the above conditions is met, a visibility verification failure is triggered, and the system forcibly sets the final positioning score of the candidate node to zero, preventing it from participating in subsequent sorting and locking processes.

[0141] In some other alternative implementations, the preset pixel threshold can be dynamically adjusted according to the UI design specifications of different platforms. For example, it can be set to 8 pixels for mobile adaptation pages and 12 pixels for desktop applications. In addition, the judgment of invisible state can be extended to visual hiding methods such as opacity: 0 and transform: scale(0) to enhance the comprehensiveness of detection.

[0142] Through the above solution, this embodiment can effectively eliminate interference from invalid candidate nodes caused by DOM remnants, undestroyed conditional rendering, or layout collapse, significantly improve the accuracy and stability of target input container recognition, avoid misjudging hidden or small-sized non-functional elements as user interaction entry points, and thus ensure the correct triggering time of the context injection function and the overall robustness of the system.

[0143] In one specific implementation, the process for merging implicit data segments into the original request payload includes, first, the selection and configuration of a zero-width character sequence. Specifically, the system pre-defines a set of control characters defined in the Unicode standard that are invisible during text rendering as sentinel markers. For example, the start marker uses the character sequence U+2068 (FIRSTSTRONG ISOLATE) followed by U+200B (ZERO WIDTH SPACE), and the end marker uses U+2060 (WORD JOINER) followed by U+200B. This combination has been tested and consistently behaves as a placeholder without glyphs in mainstream browser engines (such as Blink and WebKit), and is not automatically cleared by HTML parsers or JavaScript string processing functions.

[0144] The historical session context data is then serialized into a structured text format, such as a flattened key-value pair string or a compact JSON string, and encapsulated between the aforementioned sentinel tags to form a complete implicit data segment. This data segment is then appended to the end of the field in the original request payload that identifies the user input. For example, in a conversational platform based on text field submissions, if the user input field in the original payload is named "prompt," the reassembly operation writes the new string concatenation result back to that field.

[0145] To ensure the server-side model logic can recognize and correctly parse the implicit data segment, parsing rule metadata, including the sentinel tag encoding and delimiter semantics, is defined in the site policy configuration. Upon receiving a request, the server can use regular expressions to match specific zero-width character patterns, extract the encapsulated historical context information, and inject it into the pre-context of model inference. Because the selected characters do not visually clutter the interface, no extra spaces, line breaks, or garbled characters appear when the front-end displays user input, thus maintaining the integrity of the original UI.

[0146] In some other alternative implementations, the sentinel marker can be replaced with other invisible character combinations, such as a combination of U+FEFF (ZERO WIDTH NO-BREAK SPACE) and U+2063 (INVISIBLE SEPARATOR), or a fixed-length marker header consisting of multiple consecutive U+200C (ZERO WIDTH NON-JOINER); or, for API interfaces that support custom headers, implicit data segments can also be transmitted by extending HTTP header fields, but in this case, the zero-width character encapsulation mechanism is still retained to be compatible with plain text payload scenarios.

[0147] Through the above solution, this embodiment can achieve the hidden embedding of context data and reliable boundary recognition without changing the visible layout of the page. This allows the server to restore the context without decoupling the existing input process, while avoiding the problem of prompt word pollution or user experience degradation caused by the introduction of visible markers.

[0148] In one specific implementation, merging implicit data segments into the original request payload to generate a reassembled request payload further includes: when the request fusion processing module receives the session submission request to be sent, it first parses the data structure type of the original request payload. Specifically, it determines the format by checking the Content-Type field in the request header: if the field value is application / json or a semantically equivalent media type, the original request payload is determined to be in Object Markup Language format; if the field value is application / x-www-form-urlencoded or multipart / form-data, it is determined to be in form data format.

[0149] For payloads in Object Markup Language (OML) format, the system performs a shallow parsing of the original JSON structure, then adds a predefined context key at the root level, such as `memos_context`, and inserts the converted historical session context as its value. This key name is specified by the site policy configuration to ensure compatibility with the target platform's server-side interface. The reconstructed JSON object retains its original fields, only adding context information, and is then serialized into a string for subsequent transmission.

[0150] For form data formats, the system processes them accordingly based on their encoding type. If it's application / x-www-form-urlencoded, the historical session context is URL-encoded and represented as &memos_context=<encoded_value> The form field is appended to the end of the original form string; if it is multipart / form-data, a new form part is constructed, its name is set to memos_context, its content is the serialized context text, and it is inserted into the form data stream. This hidden field has no visual representation on the front end of the page and does not trigger any client-side logic.

[0151] In other alternative implementations, for Object Markup Language (OML) formats, nested paths can be used to inject the context, for example, by populating data into deep attribute paths such as context.plugins.memos to adapt to the parameter receiving specifications of specific platforms. For form data formats, the front-end script's filtering mechanism for unknown fields can be bypassed by adding field names with obfuscated prefixes or suffixes (such as _ctx_memo_hidden), thereby improving the injection success rate.

[0152] Through the above scheme, this embodiment can dynamically select the most suitable context injection mode based on the data encapsulation format of the actual network request, ensuring data integrity while avoiding request rejection or parsing failure due to format mismatch. Compared with the prior art, this embodiment achieves compatibility support for multiple mainstream data transmission formats, enhances the system's adaptability in heterogeneous web application environments, and can complete the effective transmission of context data without modifying the server-side code.

[0153] In one specific implementation, based on the above embodiments, in response to the session response data returned by the server, the extension's content script first intercepts the response content via the browser's network API. Specifically, according to the predefined response extraction rules in the site policy configuration associated with the current page, the system calls a regular expression engine to perform pattern matching on the response body, identifying and extracting newly added question-and-answer fragments from the current dialogue. The extracted raw text or structured data is then cleaned by the system, standardized according to the Uniform Memory Protocol (UMP) format, generating standard data units containing speaker roles, text content, and timestamp fields. Then, the standardized data units are written to the extension's local database by the request fusion processing module using an incremental update mechanism based on content uniqueness, ensuring that only newly added or changed data is persisted and avoiding duplicate recording.

[0154] In other alternative implementations, response extraction rules can use JSONPath expressions instead of regular expressions to adapt to structured response formats; timestamps during data cleaning can be obtained from the client's local clock or parsed from the server's response headers; and incremental update mechanisms can determine data novelty based on full-text hashes, semantic fingerprints, or field combination keys.

[0155] Through the above scheme, this embodiment can realize the automated collection and structured aggregation of multi-source heterogeneous session response data, complete the continuous accumulation and unified management of user dialogue history without relying on manual intervention, improve the integrity and timeliness of the context memory, and provide a reliable data foundation for subsequent cross-platform context synchronization.

[0156] In one specific implementation, an incremental deduplication algorithm is used to store the cleaned data in a local database. This includes: after newly added question-and-answer content is cleaned into Uniform Memory Protocol (UMP) format data, a unique content hash value is first generated for that data. Specifically, the SHA-256 hash algorithm is used to concatenate the "role" and "content" fields in the question-and-answer content to calculate a digest, forming a fixed-length string as the unique identifier of the record. Then, the system queries the local database interface to see if there is an existing record with the same hash value. If no match is found, the question-and-answer content is written to local storage in structured data form, with a unique identifier indicating its source platform domain and the session it belongs to. If a matching record is found in the query results, no insertion operation is performed; instead, the "last active timestamp" field of the existing record is updated to the current system time to reflect its latest interaction status.

[0157] In other alternative implementations, the hash algorithm can be replaced with BLAKE3 or MD5 (provided the probability of collision is acceptable) to adapt to scenarios with different performance and security requirements; the generation of unique identifiers can also combine session ID and timestamp prefix to form a composite key, further reducing the false positive rate of cross-session content duplication determination; the local database can adopt IndexedDB, SQLite or a lightweight key-value storage engine, dynamically adapted according to the browser environment's support.

[0158] By employing the above approach, this embodiment effectively avoids redundant storage of identical dialogue content in the local database, significantly saving storage space and improving subsequent data retrieval efficiency. Simultaneously, by updating the timestamps of existing records, it achieves accurate tracking of user session activity, providing a reliable data foundation for subsequent context-priority sorting based on a time decay strategy.

[0159] In one specific implementation, the method further includes a cross-domain identity synchronization step: when a user successfully logs into the current target website, the system first listens for changes in page routing or the appearance of specific DOM nodes through content scripts to determine whether the user has completed the identity authentication process. Specifically, the system polls and checks the localStorage or sessionStorage storage areas in the current page context to look for user identity identification fields related to the platform, such as predefined keys like user_id and auth0_client_user. These keys and their resolution rules are pre-specified by the site policy configuration to ensure accurate adaptation to identity data sources for different platforms.

[0160] The system transmits the extracted user identity identifier to the extension's backend service module and performs a binding operation locally: establishing a one-to-one mapping relationship between the identity identifier and the global user account maintained by the extension, and persistently storing it in the local database. This binding relationship is used for subsequent cross-platform context data association queries and synchronization.

[0161] The system initiates a securely authenticated data retrieval request to the remote context synchronization server. This request carries the bound global user account credentials and requests access to historical session context data for all other connected platforms under that account. The response data is a structured collection of records conforming to the Uniform Memory Protocol format, containing question-and-answer pairs from multiple platforms, timestamps, session IDs, and source platform identifiers. The system caches this data in the extension's local storage space and marks its freshness and version information for subsequent incremental updates.

[0162] In other alternative implementations, user identity extraction can be achieved by listening to the Authorization Header in the page's network requests, particularly suitable for platforms employing the Bearer Token mechanism; alternatively, it can be triggered by injecting a lightweight script to listen for native page events (such as the custom loginSuccess event). Furthermore, the download of cross-platform context data can be configured to an on-demand loading mode, downloading only historical fragments relevant to the current platform's topic, rather than synchronizing the entire dataset, to optimize bandwidth usage and initialization performance.

[0163] Through the above solution, this embodiment can achieve seamless identity association for users across heterogeneous platforms and automatically aggregate scattered session memories based on a unified account system, thereby providing a complete data foundation for subsequent context-aware injection and significantly improving contextual coherence and personalized service capabilities in multi-platform interaction scenarios.

[0164] In one specific implementation, a site policy configuration matching the current page's Uniform Resource Locator (URL) is loaded. The loading process first checks if a site policy configuration item matching the current page's URL exists in the browser extension's local storage area (chrome.storage.local). Specifically, the system reads the version number field from this configuration item and compares it with a pre-defined latest version identifier stored within the extension or obtainable via a remote interface. If no matching configuration is found, or the locally stored version number is lower than the latest version, an asynchronous HTTP GET request is initiated to a predefined configuration server to retrieve the latest policy file for the target site.

[0165] The strategy file is provided as JavaScript code, containing a self-executing function or module exported object that encapsulates structured parameters such as input container location rules, data mapping relationships, and network endpoint whitelists specific to the website. After downloading, this script does not run directly in the page context, but is dynamically executed in the extension's isolated execution environment (i.e., the content script or service worker thread) using `eval()` or `newFunction()`. The execution result generates a JavaScript object instance containing complete parsing logic and rule definitions, which serves as the specific location rule object for subsequent operations. This object is cached locally and marked with its acquisition timestamp and version number for subsequent expiration checks.

[0166] In other alternative implementations, the policy configuration can be transmitted as a signed JSON file, parsed and used by the main logic of the extension program to construct the corresponding rule object; or it can be distributed as a WASM binary module to improve parsing efficiency and security. Furthermore, the policy update mechanism can support incremental update mode, downloading only the changed configuration data to reduce network transmission overhead. The configuration server can also return differentiated policy versions based on user agent characteristics or geographical location to achieve multi-environment adaptation.

[0167] Through the above solution, this embodiment enables dynamic and remote management of site policy configurations, avoiding functional failures caused by changes in the front-end interface, and significantly improving the maintainability and adaptability of the system. Compared with existing technologies, this embodiment can adapt to new or modified target platforms without releasing new version extensions, reducing operation and maintenance costs; at the same time, through local caching and version verification mechanisms, unnecessary network requests are reduced while ensuring real-time configuration, thus optimizing resource utilization efficiency.

[0168] In one specific implementation, before sending the reassembly request payload to the server, the communication sending module further includes a network routing optimization step: first, obtaining the resolution result of the server domain name associated with the current page. Specifically, the system determines the geographical distribution attributes of the target server IP address by calling the network information interface in the browser extension environment or by using a background script. Then, the system determines whether the IP address belongs to a preset overseas address database, for example, by comparing known overseas data center IP ranges or by using a third-party geographic location database for location identification.

[0169] If the determination result indicates that the server is located overseas, the system initiates a network routing optimization mechanism: by configuring a local domain name resolution policy, the target domain name of the original request is remapped to a preset edge acceleration node address. This edge acceleration node is deployed domestically or near a high-performance access point close to the user, possessing high bandwidth and low latency backbone network connectivity. Then, the reassembled request payload is directed to this edge node, which acts as a proxy forwarder, forwarding the request completely to the origin server via an optimized transmission path (such as a dedicated tunnel or CDN backbone network), thereby avoiding the high latency and instability that may arise from cross-border links on the public internet.

[0170] In other alternative implementations, the selection of edge acceleration nodes can be dynamically adjusted based on real-time network quality, such as selecting the optimal path from multiple candidate nodes based on historical response time, packet loss rate, or RTT probing results; or, the domain name redirection strategy can be implemented by modifying the request interception rules inside the extension, without relying on the operating system's DNS configuration, ensuring the flexibility and isolation of policy execution.

[0171] Through the above solution, this embodiment can effectively reduce network latency caused by cross-regional data transmission, improve the response speed of session requests and communication reliability, and is especially suitable for scenarios where users access large language model service platforms deployed overseas, significantly improving the consistency of user experience under long-distance network interaction.

[0172] This invention provides a cross-platform session context synchronization system based on browser request interception. This system runs on a computer terminal with a browser extension installed and is used to achieve seamless synchronization of user session context data between heterogeneous network applications. For example... Figure 2 As shown, the system includes:

[0173] The policy configuration loading module M100 is configured to parse site policy configurations that match the current page's Uniform Resource Locator (URL), establish a mapping index between heterogeneous data and the Uniform Memory Protocol (UNMIP) format, and initialize the input container's location rules. This module reads policy files for specific domains from local storage. If a match is not found or the version is outdated, it initiates an asynchronous request to a remote configuration server to obtain the latest policy script. The policy script is parsed and instantiated in the extension's isolated execution environment, generating a configuration object containing data extraction rules, location parameters, and endpoint whitelists. In other optional implementations, policy configuration can be provided via static JSON resources, dynamic API interfaces, or the browser's built-in policy manager, and supports hot-update mechanisms to adapt to structural changes on the target website.

[0174] The M200 native environment monitoring bridging module is configured to deliver proxy monitoring code to the native script execution environment of the current page. This proxy monitoring code takes over the page's native network request objects to establish a cross-environment request status statistics chain. This module utilizes the script injection capability provided by browser extensions to write a lightweight JavaScript code into the page's global execution context, thereby overcoming the limitations of the content script sandbox. The injected code wraps network interfaces such as fetch and XMLHttpRequest, adding state tracking logic without altering their original behavior. The resulting statistics chain can provide real-time feedback on the lifecycle events of business requests, providing timing data for subsequent operations. In other optional implementations, the proxy mechanism for network request objects can be implemented by overriding the WebSocket constructor, intercepting Service Worker communication paths, or hooking navigation events to adapt to web applications with different communication modes.

[0175] The Page Native Script Execution Environment in this invention refers to the execution context in which JavaScript code loaded by the webpage itself runs. For example, in Chromium-based browsers (such as Google Chrome and Microsoft Edge), this environment is often referred to as the Main World. Code running in this environment has full access to and modification rights over global page objects such as the window, the Document Object Model (DOM), and native network interfaces such as fetch and XMLHttpRequest.

[0176] In contrast, the extension isolation environment or isolated world described in this specification refers to the sandbox environment in which the content scripts of browser extensions run. Although this environment can access the DOM structure of the page, it is isolated from the page's native script execution environment at the JavaScript variable and object level. The technical solution of this invention can overcome this isolation and establish a communication and monitoring bridge between the two environments.

[0177] The container positioning and locking module M300 is configured to monitor user interaction on the current page and drive the node scoring calculation engine of the Document Object Model (DOM) tree according to input container positioning rules, thereby locking the target input container. This module continuously evaluates the matching degree between candidate nodes and the expected input area by listening to DOM changes and user input events. The scoring process integrates multiple dimensions such as semantic attributes (e.g., contenteditable, role), geometric position (distance relative to the bottom of the viewport), and structural relationships (whether it is nested within a form), and uses a weighted fusion algorithm to output a comprehensive score. When a node's score consistently exceeds a preset threshold, it is identified as the target input container and enters a locked state. In other optional implementations, the node scoring calculation engine can incorporate machine learning models to assist in judgment, or combine CSS selector historical matching records for dynamic weight adjustment, or identify the spatial characteristics of the dialog input area based on visual layout analysis technology.

[0178] In a specific scoring calculation embodiment, the scoring logic is implemented as follows, assuming the final score is determined. The calculation formula is defined as follows:

[0179]

[0180] in, , , These represent semantic score, geometric position score, and relational score, respectively. , , These are the corresponding weighting coefficients.

[0181] In this preferred embodiment, considering that semantic attributes most directly represent the input intent, while geometric position is greatly affected by page layout, and relational attributes are used as auxiliary verification, the system configures the weight coefficients as follows:

[0182] Semantic weight : Assign the highest weight. For example, when a node's role attribute is explicitly declared as a textbox, It is recorded as 1.0, contributing 0.5 points.

[0183] Geometric weights Assign a medium weight. The calculation can be performed using the normalization formula: ,in The coordinates of the bottom of the node. The coordinates are the bottom coordinates of the viewport. This is the viewport height. This setting prioritizes elements located at the bottom of the page (a common dialog box location).

[0184] Relationship weight : Assign auxiliary weights. For example, if the node is located within the label, It is recorded as 1.0, contributing 0.2 points.

[0185] In addition, set a lock threshold. That is, only when Only when the system determines that the node is the target input container and triggers the locking state.

[0186] It should be noted that the aforementioned weight values ​​(0.5, 0.3, 0.2) and threshold (0.8) are merely empirical settings for a general large-scale dialog interface. In practical applications, these parameters are dynamically assigned by the aforementioned site strategy configuration. For example, for certain sites where input boxes are located at the top of the page, the strategy configuration can be automatically adjusted to reduce... The value is determined to ensure the algorithm's universality across different UI layouts.

[0187] The request fusion processing module M400 is configured to capture session submission requests triggered by interactive behavior, parse the original request payload, and retrieve historical session context data. Based on the mapping index, it generates implicit data segments adapted to the current page and reassembles these implicit data segments into the original request payload. This module intervenes in the data transmission process after detecting a user submission action, retrieving historical context information associated with the current user's identity from the local database and converting it into data fragments conforming to the target platform's receiving format according to the mapping relationship in the site policy. The reassembly process selects an appropriate merging strategy based on the structure type of the original payload (such as JSON object, FormData, or plain text) to ensure data integrity and compatibility. In other optional implementations, the implicit data segments can be encoded using Base64 encoding, a custom binary prefix marker, or an encrypted envelope structure to enhance transmission security or circumvent server-side content filtering mechanisms.

[0188] The communication sending module M500 is configured to replace the original request payload with a reconstructed request payload to complete the request delivery to the server. After reconstructing the payload, this module calls the underlying network interface to send the modified request to the target server, and the entire process is transparent to the page logic. The replacement operation keeps the original HTTP methods, header fields, and authentication information unchanged, only updating the request body content, thereby avoiding triggering cross-domain security policies or causing session interruption. In other optional implementations, request delivery can be forwarded through an intermediate proxy gateway, the path can be optimized by using CDN edge node caching, or compression encoding can be enabled when necessary to reduce transmission overhead.

[0189] The aforementioned modules work together to form a closed-loop context synchronization process: the strategy configuration loading module M100 provides the system with adaptation knowledge specific to the website; the native environment monitoring bridging module M200 establishes accurate timing awareness capabilities, ensuring operations are performed when the page state is stable; the container positioning and locking module M300 overcomes the positioning difficulties caused by frequent changes in the front-end UI, achieving robust recognition of input containers; the request fusion processing module M400 seamlessly embeds external memory data into the user's original request stream based on the context and positioning results provided by the preceding modules; and finally, the communication sending module M500 completes the seamless delivery. This multi-module linkage mechanism solves the functional vulnerability problem caused by relying on fixed selectors in existing technologies, while avoiding the interference of explicit UI intervention on user experience, and achieving automated, low-intrusion synchronization of cross-platform session context without modifying the target website code.

[0190] Through the above solution, this embodiment can accurately identify user interaction entry points in dynamically evolving single-page application environments, precisely grasp the timing of data injection, and achieve implicit fusion of contextual information in a way that is compatible with multiple data formats. This effectively breaks down data silos between large language model service platforms and improves the coherence and efficiency of multi-platform collaborative interaction. Compared with existing technologies, this embodiment has highly robust element location capabilities, supports a flexible and expandable cross-platform adaptation mechanism, achieves a completely seamless context injection experience, and significantly reduces system resource consumption caused by continuous DOM monitoring.

[0191] In one specific implementation, the native environment monitoring bridging module M200 includes a native proxy engine and a bidirectional communication channel. The native proxy engine is injected into the current page's native script execution environment in the form of an immediately invoked function expression (IIFE), and resides and runs continuously within this environment. Internally, the native proxy engine is configured with a request interceptor to override the global fetch interface and the XMLHttpRequest.prototype.send method. When any network request is initiated, the request interceptor first determines whether its URL matches the Uniform Resource Locator (URL) prefix whitelist defined in the site policy configuration; if it matches, the request is identified as a business request, and the concurrent count in the registry is incremented. This registry, as a shared state object within the native proxy engine, is used to maintain the number of currently incomplete requests in real time.

[0192] Upon request completion or failure, the native proxy engine captures the response termination signal via a Promise chain or event listener mechanism and decrements the concurrency count in the registry accordingly. Whenever the concurrency count changes, the native proxy engine further evaluates whether the silent window condition is met: after the concurrency count reaches zero, a timer of a preset duration (e.g., 200 milliseconds) is started. If no new request initiation signal matching the whitelist is received during this period, the silent window condition is considered met. Once this condition is met, the native proxy engine sends a structured message to the extension's content script by calling `window.postMessage`. This message contains a "network-ready" type identifier and timestamp information.

[0193] This message is received via a bidirectional communication channel, which is constructed by `window.postMessage` and `chrome.runtime.onMessage`, enabling cross-context and cross-process message passing from the native script runtime environment to the extension isolation environment. Upon receiving this message, the content script converts it into internal instructions and notifies other modules (such as the container positioning and locking module M300 or the request fusion processing module M400) that the current page has entered a network-ready state and can safely execute subsequent data collection or injection operations.

[0194] In other alternative implementations, the request interceptor can also be adapted to the WebSocket protocol to monitor the establishment and closure of streaming connections by intercepting the prototype of the WebSocket constructor; the counting registry can use a weak reference mechanism to manage request instances to prevent memory leaks; the message format of the bidirectional communication channel can use encrypted serialized data packets to enhance the security of cross-domain communication; or the judgment logic of the silent window can be combined with the DOM change frequency output by MutationObserver to form a composite idle state detection mechanism.

[0195] Through the above solution, this embodiment can achieve precise perception of the network activity status of the page, ensuring accurate identification of business readiness timing in a dynamic, asynchronous single-page application environment. The native proxy engine directly monitors the request lifecycle in the native page environment, avoiding state blind spots caused by sandbox isolation and improving the completeness and real-time performance of monitoring. The design of the bidirectional communication channel ensures reliable cross-domain transmission of status signals, enabling extension programs to intervene in the interaction process at the optimal time, thereby improving the success rate of context synchronization and the overall stability of the system.

[0196] In one specific implementation, the container positioning and locking module M300 integrates a resource scheduling controller. This controller is configured to maintain a global listening state machine for dynamically managing the listening strategy for Document Object Model (DOM) changes. This state machine has two operating modes: a global scan state and a locking state. During system initial operation or when page routing changes, the state machine is in the global scan state. At this time, the resource scheduling controller activates a global MutationObserver acting on the element, listening for all DOM structure change events within its subtree. The observer's callback function is set to debouncing mode, merging multiple change events within a preset time window (e.g., 150 milliseconds) into a single trigger to reduce the impact of high-frequency updates on the main thread.

[0197] When the node scoring calculation engine in the container positioning and locking module M300 continuously outputs a final positioning score for a candidate node that exceeds a preset locking threshold (e.g., 0.8), the resource scheduling controller in the container positioning and locking module M300 determines that the target input container has been stably positioned and then triggers a state machine transition: forcibly suspending the aforementioned global MutationObserver, terminating its listening to the entire DOM tree; simultaneously, starting a lightweight local attribute listener, which is only bound to the DOM node that has been marked as a locked target, specifically listening for changes in its attributes, such as whether the style, class, or contenteditable attributes have undergone abrupt changes. This local listener provides finer-grained monitoring and has extremely low resource overhead. When the system detects the browser's popstate event (indicating a front-end route jump) or discovers through another dedicated observer that the locked target node has been removed from the DOM tree, the resource scheduling controller immediately triggers the state machine to fall back to the global scan state, re-establishes the global MutationObserver, and starts a new round of debouncing DOM scanning to adapt to the new page environment.

[0198] In some other alternative implementations, the local property listener can be replaced with a MutationObserver that only listens for changes to specific CSS class names, or a polling mechanism can be used to periodically check the offsetParent property of the target node to determine its visibility status; the length of the debouncing time window can be dynamically adjusted according to the page type. For example, for sites built with single-page application (SPA) frameworks such as React or Vue, a shorter debouncing period (e.g., 100 milliseconds) can be used, while for static pages a longer period (e.g., 200 milliseconds) can be used to balance responsiveness and performance consumption.

[0199] Through the above solution, this embodiment can significantly reduce the CPU usage of the browser extension during continuous monitoring of page structure changes. By switching from coarse-grained global monitoring to fine-grained local monitoring after the target stabilizes, it avoids maintaining a high-overhead observer throughout the entire DOM lifecycle, effectively reducing the frequency of event callbacks and memory residency burden. Simultaneously, by combining debouncing mechanisms with a state machine-driven dynamic switching strategy, it ensures robust positioning in scenarios with frequent page updates and achieves on-demand resource allocation, thereby improving the overall system efficiency and browser environment smoothness while ensuring functional reliability.

[0200] In one specific implementation, the request fusion processing module M400 includes a separate functional component called the implicit encoder. This implicit encoder is configured to load a pre-defined sequence of zero-width characters from the extension's local resources. The start sentinel marker consists of a consecutive combination of Unicode code points U+2068 (FIRST STRONG ISOLATE) and U+200B (ZEROWIDTH SPACE), and the end sentinel marker consists of a consecutive combination of U+2060 (WORD JOINER) and U+200B. Historical session context data is first serialized into a structured text format, such as a JSON string, and then encoded in UTF-8 before injection. This encoded data is encapsulated between the aforementioned sentinel markers, forming a complete block of text data. This data block is then merged into the end of the user input field in the original request payload, participating in subsequent transmission as part of the overall request content.

[0201] The implicit encoder integrated into the M400 request fusion processing module ensures binary-level data consistency by calling the browser's built-in TextEncoder interface. This ensures that the encapsulated text data block exists as a standard byte stream in the HTTP request body, which can be correctly parsed by the server-side application layer protocol stack. Since the zero-width characters used do not occupy actual pixels during HTML rendering and do not trigger line breaks or layout changes, this data block is completely invisible on the front-end interface and does not affect the layout and interaction of user-visible content. The implicit encoder also has type adaptation capabilities. When the original request payload is detected to be of type application / json, the encapsulated text data block is preferentially embedded as the value of a new key-value pair into the JSON object; when the payload is of type multipart / form-data or application / x-www-form-urlencoded, it is appended to the text stream of the specified input field.

[0202] In some other alternative implementations, the sentinel marker can be replaced with other combinations of Unicode control characters that do not affect DOM rendering, such as using U+FEFF (ZERO WIDTH NO-BREAK SPACE) as the padding character, or using a custom delimiter pattern in conjunction with Base64 encoding to enhance transmission robustness; in other variations, the implicit encoder may also support a dynamic encryption mechanism that performs lightweight symmetric encryption on historical session context data before encapsulation, allowing only authorized server nodes to decrypt and restore it.

[0203] Through the above solution, this embodiment enables cross-platform injection of session context data without altering the page's visual appearance, ensuring data integrity and parsability during transmission while avoiding user cognitive interference or platform policy detection risks caused by the introduction of visible UI elements. Compared to existing technologies, this embodiment provides a data embedding mechanism that satisfies both front-end seamlessness and back-end processing capability in a browser environment, significantly improving the concealment and compatibility of context synchronization, and is suitable for seamless integration in various heterogeneous web application environments.

[0204] This embodiment is combined with the appendix Figure 3 The system architecture and attachments shown Figure 4 The interactive sequence shown further elaborates on the micro-implementation logic of the present invention in terms of element positioning robustness and data injection concealment, aiming to solve the technical problems of inaccurate positioning and data injection interference in the user interface in the dynamic page environment of the prior art.

[0205] Please refer to Figure 4 The interaction flowchart. Figure 4 In the diagram, after the plugin UI activates the content script, it enters a processing step marked as DOM scanning / raw block extraction (self-looping arrow). Although it is simplified to a single step in the diagram, in a preferred embodiment of the invention, this step internally runs a high-level logic state machine designed to balance system performance and positioning accuracy.

[0206] Specifically, the DOM scanning process is not a simple single traversal, but involves the following state transitions:

[0207] Global scan state (corresponding) Figure 4 (Initial scan phase): When a content script is first activated or a page route change (such as a URL change) is detected, the system enters a global scan state. At this time, the MutationObserver API is used to listen for changes in the entire element's subtree.

[0208] Debouncing Waiting State (Handling High-Frequency DOM Changes): In modern single-page applications (SPAs), the DOM structure often changes drastically within a short period. To avoid wasting computing power, when a change is detected, the system does not immediately execute the original block extraction, but instead starts a debouncing timer with a duration of 150 milliseconds. If another change is detected before the timer expires, the timer is reset.

[0209] Rating locked state (corresponding to) Figure 4 Decision point for original block extraction: When the debouncing timer ends, the system performs a snapshot analysis of the current DOM tree and executes a multi-dimensional scoring algorithm (based on semantic, geometric, and relational dimensions). Once the score of a candidate container node is calculated... (Locking threshold) The system determines that the target has been found and then performs a fallback listening operation: suspending the aforementioned global MutationObserver and binding a lightweight local property listener to the locked target container. This mechanism ensures that... Figure 4 In the subsequent interaction process shown, the system uses very little CPU resources until the target node is detected to be removed or the route is switched, at which point the state machine will reset to the global scan state.

[0210] Through the above mechanism Figure 4 The DOM scanning step in the invention enables a dynamic switch from coarse-grained global monitoring to fine-grained local locking, demonstrating the robustness of the invention.

[0211] Please refer to the attached document. Figure 3 The right side of the diagram illustrates the interaction between the browser plugin and the target website (such as ChatGPT or DeepSeek). The content script is responsible for direct data exchange with the target website. To achieve seamless synchronization, this invention constructs a special implicit data segment within the data stream of requests sent by the content script to the target website.

[0212] Specifically, when the content script intercepts a session submission request sent by a user to the target website, the request fusion processing module (located in the content script) constructs a reassembled request payload with the following structure:

[0213] Payload container: Preserves the format of the target website's original request (such as JSON or FormData).

[0214] Sandwich-structured data injection: In user-input text fields (such as the prompt field in JSON), data is assembled into the following sequence:

[0215] Plain text input by the user: This refers to the input content that the user can see on the interface.

[0216] Starting Sentinel Marker: Uses the Unicode character sequence `U+2068` (FIRST STRONG ISOLATE) and `U+200B` (ZERO WIDTH SPACE).

[0217] Serialized memory data: from Figure 3 The cleaned historical session context synchronized from the main database in the left-side backend service via the API gateway (i.e. Figure 3 The product of data cleaning and rule engine processing in China.

[0218] End Sentinel Marker: Uses the Unicode character sequence `U+2060` (WORD JOINER) and `U+200B`.

[0219] like Figure 3 As shown, the reconstructed payload is sent to the target website. Because zero-width characters are used as sentinels, the above structure is completely invisible in the target website's front-end rendering engine; the user can only see their plaintext input, thus achieving a seamless effect. Meanwhile, the target website's server or the system's back-end service (…) Figure 1 The data processing layer can then use the regular expression rule ` / \u2068(.*?)\u2060 / ` to precisely extract the intermediate memory data.

[0220] Combined with appendix Figure 3 The content script and Figure 4 In addition to initiating the authentication / sending raw data process, this invention also introduces a monitoring mechanism for the Page Native Script Execution Environment.

[0221] Although Figure 3 The native environment is not drawn separately, but the content scripts reside in the page context of the target website through injected proxy code (in the form of IIFE).

[0222] exist Figure 4 As shown, before sending the raw data, the injected proxy code intercepts the page's native window.fetch object.

[0223] The agent code maintains a concurrent request counter (In-flight Counter). The system generates a network ready signal only when this counter reaches zero and no new business requests are initiated within the subsequent 200-millisecond silent window.

[0224] The signal is Figure 4 The reliable execution of DOM scanning and raw data sending operations ensures the timing accuracy of data collection and injection.

[0225] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.< / form>

Claims

1. A cross-platform session context synchronization method based on browser request interception, characterized in that, The method includes: Load the site policy configuration that matches the Uniform Resource Locator (URL) of the current page. The site policy configuration defines the mapping relationship between heterogeneous data and the Uniform Memory Protocol (UNMIP) format, as well as the input container positioning rules. Inject proxy monitoring code into the native script runtime environment of the current page, and use the proxy monitoring code to proxy the native network request object of the page in order to collect statistics on the request status of the target endpoint; In response to user interaction on the current page, the node score is calculated in the document object model tree based on the input container positioning rules, and the target input container is locked. Intercept the session submission request triggered by the interaction operation and parse the original request payload of the session submission request; Retrieve the associated historical session context based on the current user identity, and convert the historical session context into an implicit data segment adapted to the current page based on the mapping relationship; The implicit data segments are merged into the original request payload to generate a reassembled request payload, which is then used to replace the original request payload and sent to the server.

2. The method according to claim 1, characterized in that, The step of injecting proxy monitoring code into the native script runtime environment of the current page to collect statistics on the request status of the target endpoint includes: The proxy monitoring code is injected into the page's native script execution environment using a browser extension interface; The proxy monitoring code rewrites the global asynchronous request object and the interface object of the page to add request counting logic. Based on the Uniform Resource Locator (URL) prefix whitelist in the site policy configuration, identify key business requests; Maintain a concurrent request count value. When the business-critical request is detected, the concurrent request count value is increased. When the business-critical request response ends or fails, the concurrent request count value is decreased. The page network readiness status is determined based on the concurrent request count value.

3. The method according to claim 2, characterized in that, The step of determining the page network readiness status based on the concurrent request count value also includes: After the concurrent request count reaches zero, a silent time window timer is started; If no new business-critical request is detected within the silent time window and no structural changes occur in the document object model tree, a network ready signal is generated. The network ready signal is sent to the extension isolation environment via a window message communication mechanism.

4. The method according to claim 2, characterized in that, For pages using streaming protocols, the request status of the target endpoint also includes: Monitor the establishment and disconnection status of streaming connections; When a streaming response is detected to be active, the document object model observer is used to listen for changes in the child nodes of the page message container node. When the streaming response remains connected but the time for the child node changes of the message container node to stop exceeds a preset threshold, it is determined that the logical transmission of the current streaming response has ended.

5. The method according to claim 1, characterized in that, The calculation of node scores in the document object model tree based on the input container positioning rules includes: Traverse the candidate nodes in the document object model tree and extract the semantic attributes, geometric position attributes, and inclusion relationship attributes of each candidate node. If the semantic attribute of the candidate node is declared as a text input box or has an editable attribute, a first preset score is assigned; If the geometric position of the candidate node is located within a preset area at the bottom of the visible viewport, a second preset score is assigned; If the candidate node contains a form label or is located in the footer area, a third preset score is assigned; The first preset score, the second preset score, and the third preset score are weighted and summed to obtain the final positioning score for each candidate node.

6. The method according to claim 1, characterized in that, The method also includes the step of processing the response data from the server: Intercept session response data returned by the server; Based on the response extraction rules defined in the site policy configuration, new question and answer content is extracted from the session response data using regular expressions; The newly added Q&A content is cleaned into a unified memory protocol format data containing roles, content, and timestamps; The cleaned data is stored in a local database using an incremental deduplication algorithm.

7. The method according to claim 6, characterized in that, The step of storing the cleaned data into a local database using an incremental deduplication algorithm includes: Generate a unique content hash value for each newly added question and answer content; Query whether the unique content hash value exists in the local database; If it does not exist, the question and answer content will be written to the local database and its source platform and session identifier will be marked. If it exists, update the last active timestamp of that Q&A content.

8. The method according to claim 1, characterized in that, The method also includes a cross-domain identity synchronization step: After detecting that the user has successfully logged into the current page, retrieve the user's identity identifier from the local storage or session storage of the current page; Bind the user identity identifier to the extension's global user account; Download the historical session context of other platforms stored under the global user account from the remote server and cache it in the extension's local storage.

9. The method according to claim 1, characterized in that, Before sending to the server, a network routing optimization step is also included: Get the server-side domain name resolution result for the current page; If the resolution result indicates that the server is located overseas, the target address of the request will be modified to the preset edge acceleration node address through the Domain Name System policy; The reassembly request payload is forwarded to the origin server via the backbone network through the edge acceleration node.

10. A cross-platform session context synchronization system based on browser request interception, characterized in that, The system runs in an extension environment on a computer terminal and includes: The strategy configuration loading module is configured to parse the site strategy configuration that matches the Uniform Resource Locator (URL) of the current page, establish a mapping index between heterogeneous data and the Uniform Memory Protocol (UNMIP) format, and initialize the input container positioning rules. The native environment monitoring bridging module is configured to deliver proxy monitoring code to the native script execution environment of the current page, and take over the native network request objects of the page through the proxy monitoring code to establish a cross-environment request status statistics link. The container positioning and locking module is configured to monitor the user's interactive behavior on the current page and drive the node rating calculation engine of the document object model tree according to the input container positioning rules, thereby locking the target input container. The request fusion processing module is configured to capture the session submission request triggered by the interaction behavior, parse the original request payload, call the historical session context data, generate an implicit data segment adapted to the current page based on the mapping index, and reassemble the implicit data segment into the original request payload. The communication sending module is configured to replace the original request payload with the recombined request payload to complete the delivery of the request to the server.

Images