Display device and script injection method

Abstract

The invention provides a display device and a script injection method. And the display equipment isolates the running environment from the script storage path through a hardware-level path to ensure that the user script is only loaded into the corresponding running environment. The controller responds to the application program loading request, identifies the running environment, determines a bound target script storage path, loads a target user script from the target script storage path and executes script injection. Effective isolation of operating environments is realized, system security and flexibility are improved, and interface cross-border access among different applications is prevented.

Description

Technical Field

[0001] This application relates to the field of display device technology, and in particular to a display device and a script injection method. Background Technology

[0002] Providing customization capabilities for app stores and broadcast TV applications in smart TV systems presents multiple technical challenges. First, traditional script injection methods rely on static declaration files, which have strict formatting requirements. Furthermore, each addition or deletion of a user script necessitates manual updating of the static declaration file, leading to maintenance difficulties and hindering online upgrades and dynamic management. Second, existing solutions lack effective runtime environment isolation mechanisms, allowing user scripts to be injected indiscriminately, potentially exposing high-risk interfaces and causing serious security issues. Summary of the Invention

[0003] This application provides a display device and a script injection method that can solve the problem of user scripts being injected indiscriminately, which may lead to the exposure of high-risk interfaces.

[0004] In a first aspect, this application provides a display device, comprising: a display; a memory configured to store a first user script corresponding to a first runtime environment and a second user script corresponding to a second runtime environment, wherein the first user script corresponds to a first script storage path, the second user script corresponds to a second script storage path, both the first script storage path and the second script storage path are hardware-level paths, the first script storage path is bound to the first runtime environment, the second script storage path is bound to the second runtime environment, and the first script storage path and the second script storage path are isolated from each other; and a controller configured to: in response to an application loading request, identify a runtime environment for loading the application, wherein the runtime environment is a first runtime environment or a second runtime environment; determine a target script storage path bound to the runtime environment based on the runtime environment; load a target user script from the target script storage path; and perform script injection according to the target user script.

[0005] The above technical solution has the following beneficial effects or advantages: by providing isolated hardware-level script storage paths for different operating environments, it ensures that user scripts under different operating environments cannot be cross-loaded, avoids security risks caused by interface exposure, reduces the risk of user data leakage, realizes secure loading of user scripts, and improves the overall security and stability of the smart TV application environment.

[0006] In some embodiments of this application, after the controller identifies the runtime environment for loading the application, it is further configured to: create an execution context corresponding to the runtime environment of the application; bind the execution context to the display window of the application; and specifically configure the controller to perform script injection according to the target user script, injecting the target user script into the execution context corresponding to the display window for execution.

[0007] The above technical solution has the following beneficial effects or advantages: After identifying the application's runtime environment, the controller creates a dedicated and isolated execution context for the application and binds it to the application's display window. This mechanism ensures that subsequently injected user scripts execute in a safe and controlled environment, effectively avoiding the risks of interface exposure and data leakage inherent in traditional script injection mechanisms.

[0008] In some embodiments of this application, the target user script includes metadata, and the controller performs script injection based on the target user script. Specifically, the controller is configured to: parse the metadata of the target user script to obtain script description information; the script description information includes Uniform Resource Locator (URL) matching rules; dynamically construct script configuration information based on the script description information; generate an extension object based on the script configuration information; the extension object is used to encapsulate the execution information of the target user script; transmit the extension object to the rendering module of the application; when the application loads page content to be displayed, determine whether the URL of the page content to be displayed satisfies the URL matching rules; if it does, inject the target user script into the execution context corresponding to the page content to be displayed through the rendering module, so as to execute the target user script in the application.

[0009] The above technical solution has the following beneficial effects or advantages: It solves the dynamic matching problem in the script injection process, improving efficiency and security. When loading page content, it determines whether the Uniform Resource Locator (URL) meets the matching rules, precisely controlling the injection timing. Execution only occurs when the URL matches, preventing invalid injection. It achieves efficient and secure script injection, effectively avoiding the risks of interface exposure and data leakage.

[0010] In some embodiments of this application, when the controller generates an extended object based on the script configuration information, it is specifically configured to add the script configuration information to the manifest dictionary to make the script configuration information structured. Generate corresponding extended objects based on the list dictionary.

[0011] The above technical solution has the following beneficial effects or advantages: By introducing a manifest dictionary as an intermediate structure, a better mechanism for generating extended objects is achieved. Adding script configuration information to the manifest dictionary allows for the standardized storage of configuration information that might otherwise be scattered or unstructured, greatly improving the efficiency of configuration information management. This structured data representation ensures that extended objects can be created based on clear and ordered data, thereby improving the efficiency of extended object generation.

[0012] In some embodiments of this application, the script configuration information further includes an injection timing identifier, which represents the loading stage of the page content. The loading stage includes a loading start stage, a loading completion stage, and an idle stage after loading is completed. The controller is further configured to inject the target user script according to the loading stage corresponding to the injection timing identifier when the Uniform Resource Locator (URL) of the page content to be displayed satisfies the URL matching rule.

[0013] The above technical solution offers the following benefits: By introducing injection timing indicators and clearly defining the page loading phase, the controller can execute injection operations at the most appropriate time based on the actual needs of the script. This not only avoids the potential for blocking page rendering due to premature script injection but also prevents the inability to respond to user actions promptly due to late script injection. This fine-grained timing control, combined with Uniform Resource Locator (URL) matching rules, ensures the accuracy, efficiency, and security of script injection, thereby improving application loading efficiency, reducing potential security risks, and enhancing the user experience.

[0014] In some embodiments of this application, the controller transmits the extended object to the rendering module of the application, specifically configured to: transmit the extended object to the rendering module of the application via an inter-process communication interface; save the extended object to a script injection manager via the rendering module of the application; and classify and store the extended object in different waiting queues according to the injection timing identifier via the script injection manager.

[0015] The above technical solution has the following beneficial effects or advantages: By using an inter-process communication interface to transmit extended objects, strict isolation between different application processes and the rendering module is ensured, avoiding the exposure of high-risk interfaces, improving system security, and also achieving orderly data transmission. By introducing a script injection manager inside the application's rendering module, efficient management of extended objects is achieved, enabling secure and efficient user script injection.

[0016] In some embodiments of this application, the script configuration information further includes Uniform Resource Locator (URL) exclusion rules. Before the controller determines whether the URL of the page content to be displayed satisfies the URL matching rules, it is further configured to: traverse the URL exclusion rules; and when the URL of the page content to be displayed matches the URL exclusion rules, determine that the page content to be displayed does not meet the script injection conditions.

[0017] The above technical solution has the following beneficial effects or advantages: By adopting a "filter-then-match" judgment process, the accuracy and security of script injection are ensured. Introducing this exclusion rule effectively avoids accidental script injection on sensitive or known security risky pages, thereby effectively reducing the risk of high-risk interface exposure and the possibility of user data leakage, and enhancing the security protection capabilities of display devices. It also improves the utilization rate of system resources and avoids executing script injection on unnecessary pages.

[0018] In some embodiments of this application, after the controller identifies the runtime environment used to load the application, it is further configured to: not load user scripts when the runtime environment is a third runtime environment.

[0019] The above technical solution has the following beneficial effects or advantages: Before determining the target script storage path, the controller introduces a security assessment of the operating environment, thereby resolving the security risks of script injection in high-risk environments. It effectively prevents user scripts from being injected into environments with easily exposed interfaces, such as general-purpose browsers, thus reducing the risk of high-risk interface exposure and ensuring the security of user data.

[0020] In some embodiments of this application, the controller is further configured during the operation of the application to: listen for user script change events under the target script storage path; dynamically update the script configuration information and the corresponding extension object when the target user script is detected to have been modified; and synchronize the updated extension object to the script injection manager.

[0021] The above technical solution has the following beneficial effects or advantages: It effectively solves the problem of user scripts not being automatically updated after modification. The controller can instantly detect any changes to user scripts by monitoring user script change events in the target script storage path in real time. Once a change is detected, it can dynamically update the relevant script configuration information and extended objects, and synchronize them to the script injection manager, improving system maintenance efficiency and response speed. Users can experience the latest script functionality without interrupting application use, thus enhancing the user experience.

[0022] Secondly, this application also provides a script injection method applied to a display device as described in the first aspect. In response to an application loading request, it identifies a runtime environment for loading the application, wherein the runtime environment is a first runtime environment or a second runtime environment. Specifically, it pre-stores a first user script corresponding to the first runtime environment and a second user script corresponding to the second runtime environment. The first user script corresponds to a first script storage path, and the second user script corresponds to a second script storage path. Both the first and second script storage paths are hardware-level paths. The first script storage path is bound to the first runtime environment, and the second script storage path is bound to the second runtime environment, and the first and second script storage paths are isolated from each other. Based on the runtime environment, it determines a target script storage path bound to the runtime environment; loads a target user script from the target script storage path; and performs script injection based on the target user script.

[0023] The above technical solution has the following advantages or beneficial effects: by providing isolated hardware-level script storage paths for different operating environments, it ensures that user scripts under different operating environments cannot be cross-loaded, avoids security risks caused by interface exposure, reduces the risk of user data leakage, realizes secure loading of user scripts, and improves the overall security and stability of the smart TV application environment. Attached Figure Description

[0024] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a schematic diagram illustrating the operation scenario between the display device 200 and the control device 100 in an embodiment of this application; Figure 2 This is a hardware configuration block diagram of the display device 200 in this embodiment of the application; Figure 3 This is a diagram showing the operating system configuration of the display device 200 in this embodiment of the application; Figure 4 A flowchart illustrating the script injection process performed by the display device 200 in this embodiment of the application; Figure 5 This is a flowchart illustrating the context binding process performed by the display device 200 in this embodiment of the application. Figure 6 Timing diagram for script injection into the display device 200 in this embodiment; Figure 7A flowchart illustrating the script injection process performed by the display device 200 in this embodiment of the application; Figure 8 A flowchart illustrating the generation of an extended object by the display device 200 in this embodiment of the application; Figure 9 This is a flowchart illustrating the script injection process performed by the display device 200 in this embodiment. Detailed Implementation

[0026] The embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described below do not represent all embodiments consistent with this application. They are merely examples of systems and methods consistent with some aspects of this application as detailed in the claims.

[0027] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0028] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0029] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0030] In this application embodiment, "display device" refers to a device with screen display and data processing capabilities. For example, display devices include, but are not limited to, smart TVs, mobile terminals, computers, monitors, advertising screens, wearable devices, virtual reality devices, and augmented reality devices.

[0031] Figure 1 This is a schematic diagram illustrating an operational scenario between a display device and a control device provided in some embodiments of this application. For example... Figure 1 As shown, users can operate the display device 200 via touch, voice, mobile terminal 300, and control device 100. For example, control device 100 can be a remote control, stylus, gamepad, etc.

[0032] like Figure 1The diagram also shows that the display device 200 communicates with the server 400 via various communication methods. This allows the display device 200 to communicate via a local area network (LAN), a wireless local area network (WLAN), and other networks.

[0033] Display device 200 can provide broadcast television reception function, and can also be equipped with intelligent network television function that provides computer support function, including but not limited to network television, smart television, Internet Protocol television (IPTV), etc.

[0034] Figure 2 Provided for some embodiments of this application Figure 1 Hardware configuration block diagram of display device 200.

[0035] In some embodiments, the display device 200 may include at least one of a tuner 210, a communication device 220, a detector 230, a device interface 240, a controller 250, a display 260, an audio output device 270, a user input interface 280, a memory, and a power supply.

[0036] In some embodiments, the communication device 220 is a component for communicating with external devices or the server 400 according to various communication protocol types. The display device 200 may be equipped with multiple communication devices 220 depending on the supported communication methods. The communication devices 220 can enable the display device 200 to communicate with the external devices or the server 400 via wireless or wired connections.

[0037] In some embodiments, detector 230 is used to acquire signals from the external environment or to interact with the outside world. For example, detector 230 includes a light receiver, a sensor for acquiring ambient light intensity; or, detector 230 includes an image acquisition device, such as a camera, which can be used to acquire external environmental scenes, user attributes, or user interaction gestures; or, detector 230 includes a sound acquisition device, such as a microphone, for receiving external sounds.

[0038] In some embodiments, device interface 240 is used to connect to an external device.

[0039] In some embodiments, the controller 250 is used to control the overall operation of the display device 200. The controller 250 may include at least one of a central processing unit (CPU), a video processor, an audio processor, a graphics processing unit (GPU), and a power processor, and a first to an nth interface for input / output. The controller 250 controls the operation of the display device 200 and responds to user operations through various software control programs stored in memory.

[0040] In some embodiments, the controller 250 and the tuner 210 may be located in different separate devices, that is, the tuner 210 may also be located in an external device of the main device where the controller 250 is located, such as an external set-top box.

[0041] In some embodiments, the display 260 is used to receive and display image signals output from the controller 250. The display 260 may include display function components for presenting images and driving components for driving image display.

[0042] In some embodiments, a user can input user commands on a graphical user interface (GUI) displayed on a display 260, and a user input interface 280 can receive user commands through the GUI.

[0043] In some embodiments, the audio output device 270 may be a built-in speaker of the display device 200 or an external audio output device connected to the display device 200.

[0044] In some embodiments, the user input interface 280 can be used to receive instructions from user input.

[0045] In some embodiments, to enable user interaction, the display device 200 may run an operating system. An operating system is a computer program that manages and controls the hardware and software resources of the display device 200. The operating system can control the display device to provide a user interface; for example, the operating system can directly control the display device to provide a user interface, or it can provide a user interface by running applications. The operating system also allows users to interact with the display device 200.

[0046] The operating system can be a native operating system based on a specific operating platform, a third-party operating system that is deeply customized based on a specific operating platform, or an independent operating system specifically developed for display devices 200.

[0047] like Figure 3 As shown, Figure 3 The diagram below illustrates the software configuration of a display device according to some embodiments of this application. In some embodiments, the system of the display device 200 can be divided into three layers, from top to bottom: the application layer, the middleware layer, and the hardware layer.

[0048] The application layer mainly includes Store applications, HbbTV applications, etc., which are used to receive user loading requests.

[0049] The middleware layer includes a runtime environment identification module, a script loading module, a dynamic script parsing module, and a script injection module, ensuring that user scripts can only be used in the current runtime environment.

[0050] The hardware layer provides hardware-level path isolation through memory, the controller executes script injection, and the display outputs the displayed image.

[0051] In this embodiment, the layered architecture supports precise matching of user scripts, reduces security risks and improves script injection efficiency through environment isolation and dynamic parsing.

[0052] It should be noted that the above examples are merely a simple division of operating system functions and do not limit the specific form of the operating system of the display device 200 in this application embodiment. Depending on the function of the display device, the type of operating system, and other factors, the number of levels and the specific level type of the operating system may be expressed in other forms.

[0053] Providing customized user scripts for Store applications and HbbTV broadcast television applications within the smart TV operating system environment faces multiple technical obstacles. Traditional script injection mechanisms rely heavily on browser UI components or static configuration files, such as the Chrome UI framework or predefined manifest.json declarations. These methods are inefficient on resource-constrained smart TVs and cannot meet lightweight requirements. The maintenance process is complex, making dynamic script updates and online upgrades difficult. Existing technologies lack effective isolation mechanisms for runtime environments, allowing user scripts to be indiscriminately loaded into various runtime environments, including Store applications, HbbTV applications, and general browsers. This lack of isolation directly leads to interface exposure issues. In general browser scenarios, the arbitrary injection of user-defined scripts further exacerbates the risk of exposing high-risk interfaces, posing a risk of user data leakage.

[0054] For example, when a Store application initiates a loading request, the system controller loads user scripts from a shared script storage area using a traditional mechanism, which does not differentiate between runtime environments. In this scenario, the Store application may be injected with user scripts containing HbbTV interface call instructions, causing the application to attempt to access unauthorized broadcast television function modules. During the loading process of the HbbTV application, Store application-specific scripts may be injected, triggering interface call conflicts, directly causing application execution flow disorder, reduced system resource scheduling efficiency, and continuous amplification of security vulnerabilities.

[0055] To address the aforementioned issues, the display device 200 provided in this application provides isolated hardware-level script storage paths for different operating environments, thereby preventing user scripts from being loaded indiscriminately and reducing the risk of high-risk interface exposure and user data leakage.

[0056] Figure 4The flowchart for the script injection performed by the display device 200 in this embodiment is as follows: Step S401: In response to the application's loading request, identify the runtime environment used to load the application.

[0057] The operating environment can be either the first operating environment or the second operating environment.

[0058] It should be noted that the memory is configured to store a first user script corresponding to a first runtime environment and a second user script corresponding to a second runtime environment. The first user script corresponds to a first script storage path, and the second user script corresponds to a second script storage path. Both the first script storage path and the second script storage path are hardware-level paths. The first script storage path is bound to the first runtime environment, and the second script storage path is bound to the second runtime environment. The first script storage path and the second script storage path are isolated from each other.

[0059] When a user launches an application, the controller receives the corresponding loading request. During this process, the controller identifies the current runtime environment of the application.

[0060] In this embodiment of the application, both the first script storage path and the second script storage path are hardware-level paths, that is, the script storage paths have physical or logical isolation characteristics at the file system or storage medium level.

[0061] The first script storage path is bound to the first runtime environment, and the second script storage path is bound to the second runtime environment. This correspondence can be organized through the directory structure of the file system. For example, a dedicated directory can be allocated for the first runtime environment, and another dedicated directory can be allocated for the second runtime environment.

[0062] Step S402: Based on the runtime environment, determine the target script storage path bound to the runtime environment.

[0063] After identifying the application's runtime environment, the controller determines the target script storage path it is bound to based on that runtime environment.

[0064] For example, if the runtime environment is identified as the first runtime environment, the controller will query the preset binding relationships to determine the first script storage path as the target script storage path. If the runtime environment is identified as the second runtime environment, the second script storage path will be determined as the target script storage path.

[0065] It should be noted that the target script storage path bound to the runtime environment can be determined by looking up a table, reading the configuration, or making specific interface calls, ensuring that the script storage path specific to each runtime environment can be found accurately.

[0066] Step S403: Load the target user script from the target script storage path.

[0067] Once the target script storage path is determined, the controller loads the target user script from that path. For example, the controller can iterate through all user scripts under the target script storage path and read them into memory.

[0068] It should be noted that, in order to improve efficiency, the loaded scripts can be cached to avoid repeated reading.

[0069] Step S404: Execute script injection based on the target user's script.

[0070] Through script injection, user scripts can modify the behavior of an application, add new features, or interact with the application's existing interfaces.

[0071] In one possible implementation, the first operating environment is an app store environment, and the second operating environment is a broadcast television environment.

[0072] For example, when a user launches an application called "Smart Shopping" via a remote control, the controller responds to the application's loading request. The controller identifies the runtime environment used to load the application. It is determined that the "Smart Shopping" application is in an app store environment, therefore its runtime environment is identified as the first runtime environment. Based on the identified first runtime environment, the controller determines the target script storage path bound to that runtime environment.

[0073] After determining the target script storage path, the controller loads the target user script from that path. The controller loads a script named "mart_shopping_sensor.user.js" from the " / Store / " path in the file system as the target user script. During this process, the system strictly prohibits loading scripts from a second script storage path or any other path, thus ensuring the isolation and security of the runtime environment at the hardware level.

[0074] The controller will execute subsequent script parsing and injection processes based on the loaded target user script to implement corresponding customized functions in the "Smart Shopping" application.

[0075] As can be seen from this embodiment, the present invention ensures that user scripts in different operating environments cannot be loaded cross-loaded through a hardware-level path isolation mechanism, fundamentally avoiding the security risks caused by mixed interface exposure, and realizing on-demand and secure loading of scripts.

[0076] The above solution ensures that user scripts in different operating environments cannot be cross-loaded by providing isolated hardware-level script storage paths for different operating environments. This avoids security risks caused by interface exposure, reduces the risk of user data leakage, achieves secure loading of user scripts, and improves the overall security and stability of the smart TV application environment.

[0077] In order to ensure that the subsequently injected user scripts are executed in a safe and controlled environment and to avoid the risks of interface exposure and data leakage in traditional script injection mechanisms, this embodiment of the application adopts a strict binding mechanism between the execution context and the application's display window.

[0078] Figure 5 This is a flowchart illustrating the context binding process performed by the display device 200 in this embodiment of the application. The specific steps are as follows: Step S501: After identifying the runtime environment used to load the application, an execution context corresponding to the runtime environment of the application is created.

[0079] After identifying the runtime environment of the loaded application, the controller creates a corresponding execution context based on the identified runtime environment.

[0080] Step S502: Bind the execution context to the application's display window.

[0081] In this embodiment, the execution context is bound to the application's display window to establish an association between the execution context and the application's user interface or its core resources in the application's runtime environment.

[0082] In this embodiment of the application, the controller executes script injection based on the target user's script, and is specifically configured as follows: Inject the target user's script into the execution context corresponding to the display window for execution.

[0083] After identifying the runtime environment of the loaded application, the controller creates a corresponding execution context based on the identified runtime environment.

[0084] The execution context is designed to provide a controlled and secure execution space for user scripts, preventing scripts from making unauthorized access to system resources or interfering with the operation of other applications.

[0085] The execution context encapsulates all the state information required for code execution, including variables, functions, scope chains, and access permissions to the host environment's application programming interface.

[0086] In one possible implementation, the execution context can be a standalone JavaScript virtual machine instance that is completely isolated from the main application's JavaScript environment, has its own global objects and scope, thus ensuring a high degree of isolation.

[0087] In another possible implementation, the execution context can be a lightweight sandbox environment that ensures security by restricting access to specific interfaces.

[0088] In this embodiment, the execution context is bound to the application's display window, and an association is established between the execution context and the application's user interface or its core resources in the application's runtime environment.

[0089] The display window typically represents the visible interface of an application or its independent view within the operating system, serving as the primary medium for application-user interaction. Binding the execution context to the application's display window ensures that when a target user script is injected and executed, it operates precisely on the specific interface of the application, avoiding impacts on other unrelated applications or system components.

[0090] In one possible implementation, the controller can set a reference to the created execution context as a property of the application's display window through a specific interface in the application's rendering module, so that the script can access the specific interface it needs through the display window.

[0091] In another possible implementation, binding the execution context to the application's display window can be achieved through inter-process communication (IPC) mechanisms. That is, the controller passes the identifier of the execution context to the application's rendering process, which is responsible for logically associating the execution context with a specific window instance of the application, thereby allowing the script to interact with the display window in a controlled environment.

[0092] For example, when a user clicks to launch the "Smart Shopping" application, the system creates a new display window for the application and assigns it a dedicated execution context 'StoreMode Context' based on the application's runtime environment, such as 'StoreMode'.

[0093] The strict binding between the display window and the execution context ensures that all operations and script executions of the "Smart Shopping" application are confined to this runtime environment and cannot access or affect other contexts.

[0094] In the above scheme, after identifying the application's runtime environment, the controller creates a dedicated, isolated execution context for the application and binds it to the application's display window. This mechanism ensures that subsequently injected user scripts execute in a safe and controlled environment, effectively avoiding the risks of interface exposure and data leakage inherent in traditional script injection mechanisms.

[0095] In this embodiment, the independent execution context provides strict isolation for user scripts in different runtime environments, preventing cross-contamination between scripts. Binding the execution context to the application's display window allows user scripts to precisely act on the specific interface of their target application, improving the accuracy and security of user script execution.

[0096] Figure 6 The timing diagram for the execution script injection of the display device 200 in this embodiment shows that when the user initiates an application loading request, the application layer receives the request and sends a startup command to the environment recognition module.

[0097] The environment identification module responds to the application loading request, identifies the current runtime environment type, creates the corresponding execution context, and binds it to the application window.

[0098] The environment identification module passes the runtime environment to the script loading module, which then loads the target user script from a dedicated path in the hardware layer storage based on the runtime environment.

[0099] The script loading module sends the script data to the dynamic script parsing module.

[0100] The dynamic script parsing module parses the script header metadata, constructs script configuration information through a regular expression engine, and generates an extended object containing a complete execution context.

[0101] The extended object is transferred to the script injection manager of the rendering process via the IPC mechanism.

[0102] When the page loads, the script injection manager monitors the DOM state machine and verifies whether the current page URL matches the script's Uniform Resource Locator (URL) matching rules. If it matches, the script injection manager injects the script into the page execution context.

[0103] To achieve dynamic matching during script injection, Figure 7 The flowchart for the script injection performed by the display device 200 in this embodiment is as follows: Step S701: Parse the metadata of the target user script to obtain script description information.

[0104] The script description information includes the Uniform Resource Locator (URL) matching rules.

[0105] In this embodiment, the script description information provides information such as the script's attributes, behaviors, and scope of application. Metadata can be embedded in the header of the user's script file in the form of comment blocks. Metadata provides a structured description of the script, enabling the system to parse it dynamically.

[0106] In one possible implementation, the metadata of the target user script is parsed using regular expression matching.

[0107] Regular expression matching is used to match and extract specific fields from metadata.

[0108] Regular expression matching is a text processing technique based on pattern matching that can efficiently extract specific information from unstructured or semi-structured text.

[0109] By introducing a regular expression matching mechanism, the controller can efficiently and flexibly extract key information from the metadata of the target user script, overcoming the limitations of traditional static parsing.

[0110] In another possible implementation, the metadata is in a structured format, and the controller can directly read the corresponding key-value pairs through a parser such as a JSON parser to obtain script description information and Uniform Resource Locator (URL) matching rules.

[0111] Step S702: Dynamically construct script configuration information based on script description information.

[0112] The parsed script description information is converted into a configuration structure that can be directly used within the system for subsequent processing.

[0113] In one possible implementation, the controller can instantiate a predefined configuration object or data structure based on script description information such as script name, version, matching rules, injection timing, etc., and populate its attributes.

[0114] Step S703: Generate an extended object based on the script configuration information.

[0115] The extended object is used to encapsulate the execution information of the target user script.

[0116] In this embodiment, the script's configuration information and execution logic are encapsulated into a unified, transferable object, which facilitates management and cross-process communication.

[0117] To improve the efficiency of generating extended objects Figure 8 The flowchart for generating an extended object for the display device 200 in this embodiment is as follows: Step S801: Add the script configuration information to the manifest dictionary to make the script configuration information structured.

[0118] Step S802: Generate the corresponding extended object based on the list dictionary.

[0119] The script configuration information is obtained by parsing the metadata of the target user's script and includes various parameters required for script injection, such as Uniform Resource Locator (URL) matching rules and injection timing identifiers.

[0120] It should be noted that a list dictionary is a data structure used to store and organize script configuration information.

[0121] In this embodiment of the application, adding script configuration information to the manifest dictionary aims to structure and standardize the scattered script configuration information.

[0122] In one possible implementation, the controller can parse the various fields in the script configuration information and store them as key-value pairs in a manifest dictionary. For example, by iterating through the attributes of the script configuration information, each attribute name can be used as a key and its value as a value, and stored in the manifest dictionary.

[0123] In another possible implementation, a structure template for a list dictionary is predefined, and then the data from the script configuration information is populated into the fields corresponding to that template.

[0124] In this embodiment, the controller dynamically generates a list dictionary containing various configuration parameters of the script, avoiding the tediousness of manually maintaining static configuration files.

[0125] In this embodiment, the extended object is an entity that encapsulates the target user's script execution information. It is typically a custom software object that contains script configuration parameters extracted from the manifest dictionary and methods for managing and executing script injection logic.

[0126] The above solution, by introducing a manifest dictionary as an intermediate structure, achieves a better mechanism for generating extended objects. Adding script configuration information to the manifest dictionary standardizes the storage of potentially scattered or unstructured configuration information, significantly improving the efficiency of configuration information management. This structured data representation ensures that extended objects can be created based on clear and ordered data, thereby improving the efficiency of extended object generation.

[0127] Furthermore, the introduction of the manifest dictionary improves the efficiency of dynamic updates to script configuration information and the ease of maintenance. When the target user's script is modified, only the corresponding entry in the manifest dictionary needs to be updated to quickly synchronize to the extended object, reducing the complexity and maintenance cost of the script injection process.

[0128] Step S704: Transfer the extended object to the application's rendering module.

[0129] In one possible implementation, the controller can send the serialized extended object to the process where the rendering module resides through inter-process communication mechanisms such as message queues, shared memory, or sockets.

[0130] Step S705: When the application loads the page content to be displayed, determine whether the Uniform Resource Locator (URL) of the page content to be displayed satisfies the URL matching rules.

[0131] In step S706, if the conditions are met, the target user script is injected into the execution context corresponding to the page content to be displayed through the rendering module, so as to execute the target user script in the application.

[0132] In this embodiment of the application, when the application loads the page content to be displayed, the controller determines whether the Uniform Resource Locator (URL) of the page content to be displayed satisfies the URL matching rules, ensuring that the script is executed only on the expected page, avoiding unnecessary injection and potential security risks.

[0133] When the rendering module receives a page load request, it obtains the Uniform Resource Locator (URL) of the current page and performs string matching or regular expression matching against the URL matching rules contained in the extended object.

[0134] If the conditions are met, the target user script is injected into the execution context corresponding to the page content to be displayed through the rendering module, so that the target user script can be executed in the application.

[0135] The above solution resolves the dynamic matching issue during script injection, improving both efficiency and security. It checks whether the Uniform Resource Locator (URL) matches the rules when loading page content, precisely controlling the injection timing. Execution only occurs when the URL matches, preventing invalid injection. This achieves efficient and secure script injection, effectively avoiding the risks of interface exposure and data leakage.

[0136] In this embodiment of the application, script injection is performed based on the target user's script to achieve customized script functions. However, since the specific timing of script injection is not specified, it may lead to improper injection timing, affecting page loading efficiency or increasing security risks.

[0137] Based on this, in one possible implementation, the script configuration information also includes an injection timing identifier.

[0138] It should be noted that the injection timing identifier represents the page content loading stage, which includes the loading start stage, the loading completion stage, and the idle stage after loading is completed.

[0139] The controller is also configured as follows: When the Uniform Resource Locator (URL) of the page content to be displayed satisfies the URL matching rules, the target user script is injected according to the loading stage corresponding to the injection timing identifier.

[0140] In this embodiment, the injection timing identifier is a key parameter used to precisely control the injection time of the target user's script. The introduction of the injection timing identifier makes script injection no longer random, but allows for fine-grained scheduling based on actual needs.

[0141] In one possible implementation, the rendering module can maintain an internal page loading state machine, and the injection timing identifier directly corresponds to a specific state node in the state machine.

[0142] In this embodiment, the loading phase specifically includes a loading start phase, a loading completion phase, and an idle phase after loading is completed, providing multi-level control points for script injection.

[0143] The initial loading phase refers to the early stage when the browser begins parsing the document and building the DOM tree. Injecting scripts during this phase allows for modifications to the page structure as early as possible.

[0144] The "loading complete" stage refers to a stage where the Document Object Model (DOM) content has been fully loaded and parsed, but external resources such as images and videos are still loading in the background. Injecting scripts at this stage ensures that the scripts can access the complete DOM structure and perform DOM-dependent initialization operations.

[0145] The idle phase after loading is complete refers to the period when all page resources have been loaded and the browser is in an idle state, no longer performing important rendering tasks.

[0146] When executing script injection, the controller first determines whether the Uniform Resource Locator (URL) of the page content to be displayed meets the preset URL matching rules. If it does, the controller does not immediately inject the script, but instead coordinates with the page loading state of the application rendering module based on the injection timing identifier contained in the target user script's script configuration information.

[0147] For example, the controller can pass an extended object containing an injection timing identifier to the application's rendering module. The script injection manager inside the rendering module places the script into the corresponding waiting queue based on the injection timing identifier in the extended object. When the page loads to the stage corresponding to the injection timing identifier, the rendering module or script injection manager retrieves the target user script from the corresponding queue and injects it into the execution context corresponding to the page content to be displayed.

[0148] The above solution, by introducing injection timing indicators and clearly defining the page loading phase, allows the controller to execute injection operations at the most appropriate time based on the actual needs of the script. This not only avoids the potential for blocking page rendering due to premature script injection but also prevents the inability to respond to user actions promptly due to late script injection. This fine-grained timing control, combined with Uniform Resource Locator (URL) matching rules, ensures the accuracy, efficiency, and security of script injection, thereby improving application loading efficiency, reducing potential security risks, and enhancing the user experience.

[0149] To achieve efficient management of extended objects, Figure 9 The flowchart for the script injection performed by the display device 200 in this embodiment is as follows: Step S901: The extended object is transferred to the application's rendering module through the inter-process communication interface.

[0150] Step S902: Save the extended object to the script injection manager through the application's rendering module.

[0151] Step S903: Using the script injection manager, the extended objects are categorized and stored in different waiting queues according to the injection timing identifier.

[0152] It's important to note that an inter-process communication (IPC) interface is a mechanism that allows independently running processes to exchange and synchronize data. In a multi-process architecture, different applications or system components typically run in independent process spaces to achieve resource isolation. IPC interfaces ensure the safe and orderly transfer of data between these isolated processes.

[0153] In one possible implementation, a message-passing-based IPC mechanism is used, where one process encapsulates data into a message and sends it to another process, and the receiving process receives and processes the message through a predefined interface.

[0154] In this embodiment, the script injection manager is a component within the rendering module, specifically responsible for receiving, storing, and scheduling extension objects to be injected. Its main function is to centrally manage all user scripts that need to be injected, and based on preset rules, such as injection timing, determine when and which script to inject into the page's execution context, thereby avoiding the disorder of script injection and improving the accuracy and efficiency of injection.

[0155] The waiting queue is a data structure within the script injection manager used to categorize and store extended objects. Each queue corresponds to an injection timing identifier; for example, there is a "start loading" queue, a "loading complete" queue, and an "idle" queue. By placing extended objects into the appropriate queues based on their injection timing identifiers, this categorized storage mechanism allows the rendering module to accurately and orderly retrieve and inject the corresponding target user scripts at different stages of page loading, thereby avoiding the disorderly nature of script injection and improving the accuracy and efficiency of injection.

[0156] The above solution, by employing an inter-process communication interface to transmit extended objects, ensures strict isolation between different application processes and the rendering module, avoids the exposure of high-risk interfaces, improves system security, and ensures orderly data transmission. By introducing a script injection manager within the application's rendering module, efficient management of extended objects is achieved, enabling secure and efficient user script injection.

[0157] To improve the judgment logic for script injection and make user script injection more secure and controllable under different operating environments, the script configuration information in this embodiment also includes a Uniform Resource Locator (URL) exclusion rule. Before the controller determines whether the URL of the page content to be displayed satisfies the URL matching rule, it is further configured as follows: Iterate through the Uniform Resource Locator (URL) exclusion rules; If the Uniform Resource Locator (URL) of the page content to be displayed matches the URL exclusion rule, it is determined that the page content to be displayed does not meet the script injection conditions.

[0158] It should be noted that the Uniform Resource Locator (URL) exclusion rules are used to identify the set of URLs that should not be used for script injection.

[0159] The controller first filters according to the Uniform Resource Locator (URL) exclusion rules. Specifically, after receiving the URL of the page to be displayed, the controller first iterates through the URL exclusion rules. If the URL of the page to be displayed matches any URL exclusion rule, the controller immediately determines that the page does not meet the script injection conditions and terminates the subsequent matching process. Only when the URL of the page to be displayed is not filtered out by any exclusion rule will the controller continue to execute the matching step according to the URL matching rules.

[0160] The above solution employs a "filter-then-match" judgment process to ensure the accuracy and security of script injection. By introducing this exclusion rule, it effectively avoids accidental script injection on sensitive or known security risky pages, thereby significantly reducing the risk of high-risk interface exposure and the possibility of user data leakage, and enhancing the security protection capabilities of display devices. It also improves the utilization rate of system resources and avoids executing script injection on unnecessary pages.

[0161] The above solution proposes to determine the target script storage path bound to the runtime environment based on the runtime environment, and load the target user script from the target script storage path to achieve isolation. However, in this process, if the runtime environment is a general browser, loading the user script may lead to the exposure of high-risk interfaces and the risk of user data leakage.

[0162] In this regard, this application further proposes that, after identifying the runtime environment used to load the application, the controller is also configured to: When the runtime environment is a third runtime environment, user scripts are not loaded.

[0163] In this embodiment of the application, the third operating environment is a general browser environment.

[0164] Before determining the target script storage path to which it is bound based on the runtime environment, the controller performs a security check. This check aims to determine whether the currently identified runtime environment is a third runtime environment. A "third runtime environment" typically refers to a runtime environment that is different from the first runtime environment (e.g., the Store application environment) and the second runtime environment (e.g., the HbbTV application environment).

[0165] It should be noted that general-purpose web browser environments allow users to access any external webpage, and their internal interfaces may be more easily exploited by malicious scripts.

[0166] In one possible implementation, the controller can determine whether an application is a third runtime environment by identifying its startup parameters or the sandbox environment identifier it runs in. For example, the system maintains a whitelist or blacklist of runtime environments; if an identified runtime environment is not in the whitelist or is in the blacklist, it is classified as a third runtime environment. Once the controller determines that the current runtime environment is a third runtime environment, it will execute the "do not load user scripts" operation. This means that the controller will directly skip subsequent steps such as "loading the target user script from the target script storage path" and "performing script injection based on the target user script," thereby effectively preventing any user-defined scripts from being injected and executed in this high-risk environment.

[0167] The above solution incorporates a security check of the runtime environment before determining the target script's storage path, thus mitigating the security risks of script injection in high-risk environments. It effectively prevents user scripts from being injected into environments with easily exposed interfaces, such as general-purpose browsers, thereby reducing the risk of exposing high-risk interfaces and ensuring the security of user data.

[0168] In some of the embodiments described above in this application, a controller is proposed to load the target user script based on the runtime environment to perform script injection. However, in its implementation, when the user script is modified, the system cannot automatically update the script configuration information, resulting in low maintenance efficiency and poor user experience.

[0169] Based on this, this application further proposes that the controller can dynamically respond to changes in user scripts during application execution, thereby improving the system's flexibility and maintenance efficiency.

[0170] In this embodiment of the application, the controller is further configured as follows: Listen for user script change events in the target script storage path; When a target user's script is detected to have been modified, the script configuration information and the corresponding extended objects are dynamically updated. Synchronize the updated extended objects to the script injection manager.

[0171] The monitoring mechanism enables the system to detect any modifications, additions, or deletions of user scripts in the target script storage path in real time, without relying on manual triggering.

[0172] When a modification to the target user script is detected, the controller is configured to dynamically update the script configuration information and the corresponding extended object. For example, the controller can reread the modified target user script, parse its metadata to obtain the latest script description information, and reconstruct the script configuration information based on this. Subsequently, the controller regenerates the corresponding extended object based on the updated script configuration information. This extended object encapsulates the latest execution information of the target user script. This process does not require an application restart, ensuring the real-time nature of the script configuration information and the corresponding extended object.

[0173] Furthermore, the controller is configured to synchronize the updated extension object to the script injection manager. After the extension object is dynamically updated, to ensure that the application's rendering module can inject using the latest script logic, the controller transmits the new extension object to the component responsible for managing script injection. For example, the controller can send the updated extension object to the application's rendering module via an inter-process communication interface, and the rendering module will then save it to the script injection manager. In this way, the script injection manager can immediately obtain and use the latest script execution information, ensuring that subsequent script injection operations are based on the latest user scripts.

[0174] The above solution effectively solves the problem of user scripts not automatically updating after modification. The controller monitors user script change events in the target script storage path in real time, enabling it to instantly detect any modifications. Once a change is detected, it dynamically updates the relevant script configuration information and extended objects, synchronizing them to the script injection manager, thus improving system maintenance efficiency and responsiveness. Users can experience the latest script functionality without interrupting application use, thereby enhancing the user experience.

[0175] The above scheme is illustrated by a more specific example below: In a smart TV device, the operating system needs to provide customized user scripts for different types of applications to ensure the isolation and security of the operating environment.

[0176] For example, the device runs an "App Store app," an "HbbTV Broadcast TV app," and a generic "Browser app."

[0177] Smart TV devices include a display for presenting various application interfaces. The device's internal memory is configured to store script storage paths corresponding to different operating environments.

[0178] For the first runtime environment corresponding to the "App Store Application", a first user script is stored in the memory, and the first user script is located in the first script storage path. For the second runtime environment corresponding to the "HbbTV Broadcast Television Application", a second user script is stored in the memory, and the second user script is located in the second script storage path.

[0179] It should be noted that these script storage paths are all hardware-level paths. The first script storage path is bound to the first runtime environment, and the second script storage path is bound to the second runtime environment.

[0180] The user launches an app store application called "Smart Shopping". This application requires a user script to dynamically acquire data from the TV's hardware sensors, such as ambient light sensor data, in order to automatically adjust the display of product images based on the room's brightness.

[0181] When a user clicks to launch the "Smart Shopping" application, the controller first identifies the current runtime environment used to load the application as a Store application. The system creates a dedicated "StoreMode Context" for this application and binds it to the application's display window. At this point, the system stipulates that only user scripts located under the " / Store / " path are allowed to be loaded. Any scripts located under the " / Hbbtv / " path or scripts in a general browser environment will be strictly prohibited from loading, thus ensuring environmental isolation and security at the physical path level.

[0182] Next, following the instructions of the "StoreMode Context", the controller scans the " / Store / " directory and locates the "smart_shopping_sensor.user.js" user script file. It parses the metadata in the script header to generate an extended object containing the complete execution context. This extended object is then securely transferred via IPC to the rendering process responsible for rendering the "Smart Shopping" application pages and stored by the script injection manager.

[0183] When a product details page in the "Smart Shopping" application begins loading, the script injection manager dynamically matches the current page's URL against the matching rules of the "smart_shopping_sensor.user.js" user script. If a match is found, and the injection timing flag is specified as "document-start," the script is precisely injected early in the page's DOM construction. The injected script executes immediately, retrieves ambient light sensor data, and dynamically adjusts the brightness of the product images based on the data.

[0184] The above solution enables dynamic, secure, and precise injection of user scripts for Store applications, avoiding interference from scripts in other environments and the exposure of high-risk interfaces.

[0185] This invention also provides a script injection method, as detailed below: In response to an application's loading request, identify the runtime environment used to load the application; It should be noted that the operating environment is either a first operating environment or a second operating environment; wherein, a first user script corresponding to the first operating environment and a second user script corresponding to the second operating environment are pre-stored, wherein the first user script corresponds to a first script storage path and the second user script corresponds to a second script storage path, both the first script storage path and the second script storage path are hardware-level paths, the first script storage path is bound to the first operating environment and the second script storage path is bound to the second operating environment, and the first script storage path and the second script storage path are isolated from each other.

[0186] Based on the runtime environment, determine the target script storage path bound to the runtime environment; Load the target user script from the target script storage path; Script injection is performed based on the target user's script.

[0187] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the discussion in some embodiments is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the contents of this disclosure, thereby enabling those skilled in the art to better utilize the embodiments.

Claims

1. A display device, characterized in that, include: monitor; The memory is configured to store a first user script corresponding to a first runtime environment and a second user script corresponding to a second runtime environment, wherein the first user script corresponds to a first script storage path, the second user script corresponds to a second script storage path, both the first script storage path and the second script storage path are hardware-level paths, the first script storage path is bound to the first runtime environment, the second script storage path is bound to the second runtime environment, and the first script storage path and the second script storage path are isolated from each other. The controller is configured as follows: In response to an application loading request, the runtime environment for loading the application is identified, wherein the runtime environment is a first runtime environment or a second runtime environment; Based on the aforementioned runtime environment, determine the target script storage path bound to the runtime environment; Load the target user script from the target script storage path; Script injection is performed based on the target user's script.

2. The display device according to claim 1, characterized in that, After identifying the runtime environment used to load the application, the controller is further configured to: Create an execution context corresponding to the runtime environment of the application; Bind the execution context to the display window of the application; The controller executes script injection based on the target user's script, and is specifically configured as follows: The target user script is injected into the execution context corresponding to the display window and executed.

3. The display device according to claim 1, characterized in that, The target user script includes metadata, and the controller performs script injection based on the target user script, specifically configured as follows: Parse the metadata of the target user's script to obtain script description information; the script description information includes Uniform Resource Locator (URL) matching rules; Dynamically construct script configuration information based on the script description information; An extended object is generated based on the script configuration information; the extended object is used to encapsulate the execution information of the target user script. The extended object is transferred to the application's rendering module; When the application loads the page content to be displayed, it determines whether the Uniform Resource Locator (URL) of the page content to be displayed satisfies the URL matching rules. If the conditions are met, the target user script is injected into the execution context corresponding to the page content to be displayed through the rendering module, so as to execute the target user script in the application.

4. The display device according to claim 3, characterized in that, When the controller generates the extended object based on the script configuration information, it is specifically configured as follows: The script configuration information is added to the manifest dictionary to make the script configuration information structured; Generate corresponding extended objects based on the list dictionary.

5. The display device according to claim 3, characterized in that, The script configuration information also includes an injection timing identifier, which represents the page content loading stage. The loading stage includes the start loading stage, the loading completion stage, and the idle stage after loading is completed. The controller is also configured to: When the Uniform Resource Locator (URL) of the page content to be displayed satisfies the URL matching rule, the target user script is injected according to the loading stage corresponding to the injection timing identifier.

6. The display device according to claim 5, characterized in that, The controller transmits the extended object to the application's rendering module, specifically configured as follows: The extended object is transmitted to the rendering module of the application via an inter-process communication interface; The extended object is saved to the script injection manager through the application's rendering module; The script injection manager categorizes and stores the extended objects in different waiting queues based on the injection timing identifier.

7. The display device according to claim 3, characterized in that, The script configuration information also includes Uniform Resource Locator (URL) exclusion rules. Before the controller determines whether the URL of the page content to be displayed meets the URL matching rules, it is also configured as follows: Iterate through the Uniform Resource Locator (URL) exclusion rules; If the Uniform Resource Locator (URL) of the page content to be displayed matches the URL exclusion rule, it is determined that the page content to be displayed does not meet the script injection conditions.

8. The display device according to claim 1, characterized in that, After identifying the runtime environment used to load the application, the controller is further configured to: When the runtime environment is a third runtime environment, user scripts are not loaded.

9. The display device according to claim 1, characterized in that, The controller is also configured to: Listen for user script change events under the target script storage path; When the target user script is detected to have been modified, the script configuration information and the corresponding extended object are dynamically updated. Synchronize the updated extended object to the script injection manager.

10. A script injection method, characterized in that, The method includes: In response to an application loading request, the runtime environment for loading the application is identified, wherein the runtime environment is a first runtime environment or a second runtime environment; wherein a first user script corresponding to the first runtime environment and a second user script corresponding to the second runtime environment are pre-stored, wherein the first user script corresponds to a first script storage path, the second user script corresponds to a second script storage path, both the first script storage path and the second script storage path are hardware-level paths, the first script storage path is bound to the first runtime environment, the second script storage path is bound to the second runtime environment, and the first script storage path and the second script storage path are isolated from each other; Based on the aforementioned runtime environment, determine the target script storage path bound to the runtime environment; Load the target user script from the target script storage path; Script injection is performed based on the target user's script.

Images