Webpage control method, apparatus, electronic device, medium, and system
Patent Information
- Application Number
- CN202611139724.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-29
- Publication Date
- 2026-10-27
AI Technical Summary
所述嵌入式网页运行端还用于通过所述网页端自治拦截入口执行所述栈控制指令,更新所述嵌入式网页运行端对应的浏览历史栈状态;
Smart Images

Figure CN122986203A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of mobile Internet technology, and more specifically, to a webpage control method, device, electronic device, computer-readable storage medium, and system. Background Technology
[0002] With the increasing popularity of mini-program applications, more and more business pages are being implemented by embedding web pages within mini-program pages. These applications typically load web page content within the mini-program page, allowing the web application to reuse existing front-end page capabilities while leveraging the entry points, distribution, and page display capabilities provided by the mini-program to complete the business presentation. In this hybrid operation scenario, the native mini-program page and the embedded web page usually have their own page history management mechanisms, placing higher demands on the coordination of page navigation, page return, and page refresh processing.
[0003] Existing page history coordination solutions typically handle this by maintaining a unified history record on the mini-program side, cross-platform message communication, or using intermediate bridging pages. For example, some solutions establish a unified history record array on the mini-program side to record navigation information between native mini-program pages and internal web pages; some solutions receive web page route change notifications through message channels and maintain a virtual page stack on the mini-program side; and some solutions introduce bridging pages during page navigation and control subsequent navigation actions through state management logic within the bridging pages.
[0004] However, the existing solutions mentioned above usually require joint modifications to both the mini-program and web page, which can easily increase cross-platform communication links, state synchronization logic, and page stack maintenance logic, resulting in a complex implementation architecture. At the same time, after multiple levels of navigation within the web page, issues such as overlapping layers, repeated returns, or repeated accumulation of root pages can easily occur between the mini-program's return operation and the web page's history, making the return path inconsistent with the user's expectations. In addition, bridging pages or cross-platform messaging mechanisms may introduce additional navigation processes or communication delays, making it difficult to meet the requirements for lightweight, low-intrusion, and centralized navigation stack control in mini-program embedded web page scenarios. Summary of the Invention
[0005] This application provides a web page control method, apparatus, electronic device, computer-readable storage medium, and system to at least alleviate the aforementioned technical problems.
[0006] A webpage control method, comprising: In response to a webpage navigation trigger request from an embedded webpage, obtain the webpage container running identifier, the front-end route object, the current page route status, and the target page route status; Based on the front-end routing object, an original navigation reference is generated, and when the webpage container runtime identifier matches the mini-program webpage container environment, an autonomous interception entry point on the webpage is generated based on the original navigation reference. Based on the current page routing state and the target page routing state, a navigation scene identifier is generated, and stack control instructions are generated according to the navigation scene identifier; The stack control instruction is executed through the autonomous interception entry point on the web page to update the browsing history stack state corresponding to the embedded web page; Based on the updated browsing history stack state and the execution feedback of the stack control instructions, control result data representing the webpage navigation stack control results is generated.
[0007] A webpage control device, comprising: The navigation status acquisition unit is used to respond to the webpage navigation trigger request of the embedded webpage and acquire the webpage container running identifier, the front-end route object, the current page route status, and the target page route status. The interception entry generation unit is used to generate an original navigation reference based on the front-end routing object, and generate a web-side autonomous interception entry based on the original navigation reference when the web page container running identifier matches the mini-program web page container environment. The stack control instruction generation unit is used to generate a navigation scene identifier based on the current page routing state and the target page routing state, and to generate stack control instructions according to the navigation scene identifier; The stack state update unit is used to execute the stack control instruction through the autonomous interception entry of the web page to update the browsing history stack state corresponding to the embedded web page. The control result generation unit is used to generate control result data representing the control result of the web page navigation stack based on the updated browsing history stack state and the execution feedback of the stack control instructions.
[0008] An electronic device includes a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, implements the above-described webpage control method.
[0009] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described webpage control method.
[0010] A web page control system includes a mini-program application terminal and an embedded web page runtime terminal, wherein the mini-program application terminal is used to provide a mini-program web page container environment and load the embedded web page runtime terminal in the mini-program web page container environment; The embedded web page runtime is used to respond to the web page navigation trigger request of the embedded web page and obtain the web page container runtime identifier, front-end routing object, current page routing status and target page routing status; The embedded web page runtime is also used to generate an original navigation reference based on the front-end routing object, and generate a web page autonomous interception entry based on the original navigation reference when the web page container runtime identifier matches the mini program web page container environment. The embedded web page runtime is also used to generate a navigation scene identifier based on the current page routing state and the target page routing state, and to generate stack control instructions according to the navigation scene identifier; The embedded web page runtime is also used to execute the stack control instruction through the autonomous interception entry of the web page, and update the browsing history stack state corresponding to the embedded web page runtime. The embedded web page runtime is also used to generate control result data representing the web page navigation stack control result based on the updated browsing history stack state and the execution feedback of the stack control instructions.
[0011] The technical advantages of the technical solution provided in this application are: This application's webpage control method addresses the technical shortcomings of existing page history coordination schemes in mini-program embedded webpage scenarios, which require joint modification of both the mini-program and webpage ends, involve complex cross-platform communication links, and have scattered state synchronization logic. By responding to the embedded webpage's navigation trigger request, it obtains the webpage container's runtime identifier, front-end routing object, current page routing state, and target page routing state. Based on the front-end routing object, it generates an original navigation reference. When the webpage container's runtime identifier matches the mini-program's webpage container environment, it generates a self-governing interception entry point on the webpage side based on the original navigation reference, thus centralizing navigation processing on the embedded webpage side. Compared to traditional solutions that rely on the mini-program to maintain a unified history record, message channels, or bridging pages, this application executes subsequent stack control instructions through a self-governing interception entry point on the webpage side. This reduces the need for cross-platform communication and mini-program modification, resulting in a lower architectural complexity for mini-program embedded webpage navigation control and correspondingly lower deployment and maintenance costs.
[0012] This application further generates a navigation scene identifier based on the current page routing state and the target page routing state, and generates stack control instructions according to the navigation scene identifier. This solves the problems of overlapping return levels, repeated accumulation of root pages, and increasing history depth due to subpage jumps in traditional solutions. Traditional processing methods often struggle to distinguish the different hierarchical relationships between the current page and the target page, easily accumulating page items that do not conform to the return intent in the browsing history. However, this application determines the navigation scene identifier by jointly determining the current page routing state and the target page routing state, and then generates corresponding stack control instructions from the navigation scene identifier. This allows different page level combinations to trigger differentiated stack control processing, making the browsing history stack state closer to the actual return requirements of embedded web pages in the mini-program environment.
[0013] This application executes stack control instructions and updates the browsing history stack state of the embedded webpage through a webpage-based autonomous interception entry point. This further solves the problems of repeated stack pushing, increased stack depth, or unstable return paths that are prone to occur in traditional solutions during scenarios such as root page parameter updates, subpage switching, and subpage return to the root page. Since the stack control instructions are executed in the webpage-based autonomous interception entry point, and the execution results are directly fed back into the browsing history stack state update process, there is no need to rely on the mini-program to synchronously clean up the webpage history, nor is it necessary to indirectly infer webpage history changes through the virtual page stack. This makes the stack state update chain more centralized, reduces the sources of exceptions, and relatively increases the stability of the page return path.
[0014] Finally, this application generates control result data based on the updated browsing history stack state and the execution feedback of stack control instructions, enabling a single webpage navigation stack control process to generate returnable and recordable result information. In traditional solutions, the results of cross-platform communication or bridging processing are often scattered across different platforms or different page processes, making it difficult to uniformly reflect the stack state changes after navigation processing. In contrast, this application combines the updated browsing history stack state and execution feedback into control result data, which helps subsequent callers identify whether the navigation control is complete, whether the browsing history stack state has been updated, and the feedback status corresponding to the executed stack control instructions, thereby improving the closed-loop nature and maintainability of the embedded webpage navigation control process in the mini-program. Attached Figure Description
[0015] Figure 1 This is a flowchart illustrating a webpage control method according to an embodiment of this application.
[0016] Figure 2 This is a schematic diagram of the structure of a webpage control device according to an embodiment of this application.
[0017] Figure 3 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application.
[0018] Figure 4 This is a schematic diagram of the structure of a computer-readable storage medium according to an embodiment of this application.
[0019] Figure 5 This is a schematic diagram of the structure of a web page control system according to an embodiment of this application. Detailed Implementation
[0020] like Figure 1 As shown, this is an embodiment of a webpage control method according to this application, including: In response to a webpage navigation trigger request from an embedded webpage, obtain the webpage container running identifier, the front-end route object, the current page route status, and the target page route status; Based on the front-end routing object, an original navigation reference is generated, and when the webpage container runtime identifier matches the mini-program webpage container environment, an autonomous interception entry point on the webpage is generated based on the original navigation reference. Based on the current page routing state and the target page routing state, a navigation scene identifier is generated, and stack control instructions are generated according to the navigation scene identifier; The stack control instruction is executed through the autonomous interception entry point on the web page to update the browsing history stack state corresponding to the embedded web page; Based on the updated browsing history stack state and the execution feedback of the stack control instructions, control result data representing the webpage navigation stack control results is generated.
[0021] In this application, an embedded webpage refers to a web application page loaded within a mini-program webpage container environment. An embedded webpage has a browsing history stack state independent of the mini-program page, which records the order and hierarchy of loaded page items within the embedded webpage. Page navigation within an embedded webpage is typically triggered by a front-end routing object, which then uses the browsing history stack state's write capability to change the webpage address. Within the mini-program webpage container environment, the mini-program page itself also has a mini-program page return management mechanism. The browsing history stack state and the mini-program page return management mechanism are not automatically synchronized. Therefore, when multiple page navigations occur within an embedded webpage, the mini-program page return management mechanism can easily backtrack along the browsing history stack state, leading to problems such as repeated dwell on entry-level pages, accumulation of stack depth after switching non-entry-level pages, and return paths that do not conform to navigation intent. This application adopts a webpage-side autonomous processing method, completing webpage container runtime identifier recognition, front-end routing object takeover, navigation scene identifier generation, and stack control instruction execution within the embedded webpage. This allows the browsing history stack state to be directly controlled on the webpage side, without requiring the mini-program application side to maintain the browsing history stack state additionally.
[0022] In this application, the webpage navigation trigger request is request data generated when page navigation is triggered within an embedded webpage. The webpage navigation trigger request can originate from page navigation triggered by page controls or route navigation triggered by code within the page. The webpage navigation trigger request includes a target address parameter, which is subsequently used to generate the target page route state. In response to the webpage navigation trigger request from the embedded webpage, firstly, the runtime environment description field corresponding to the current runtime environment of the embedded webpage is read, and a webpage container runtime identifier is generated based on the runtime environment description field; then, the front-end routing object currently used by the embedded webpage is read, enabling the front-end routing object to participate in the generation of the original navigation reference and the webpage-side autonomous interception entry; subsequently, the current webpage address is read and the target address parameter in the webpage navigation trigger request is parsed to form the current page route state and the target page route state respectively. Through the above processing, the webpage container runtime identifier is used to determine whether to enable the webpage-side autonomous interception entry, the front-end routing object is used to retain the original navigation capabilities and generate the taken-over webpage-side autonomous interception entry, and the current page route state and the target page route state are used to determine the page hierarchy change corresponding to this navigation.
[0023] In this application, the webpage container runtime identifier is used to indicate the type of webpage container the embedded webpage is currently in. The webpage container runtime identifier is not the page stack data passed from the mini-program application, but rather the environment identification result generated by the embedded webpage after reading the runtime environment description field from its own runtime environment. The front-end routing object is the routing object that manages page navigation within the embedded webpage, and it contains callable navigation entry points. The current page routing state describes the hierarchy and address parameters of the page the embedded webpage is currently in before the webpage navigation trigger request occurs, while the target page routing state describes the hierarchy and address parameters of the page the webpage navigation trigger request intends to enter. The current page routing state and the target page routing state are not simply address strings, but routing state data formed after path normalization processing, reflecting whether the current page and the target page belong to the entry-level page or a non-entry-level page, respectively.
[0024] In this application, when generating the original navigation reference based on the front-end routing object, the navigation call entry is first read from the front-end routing object, and then the navigation call entry is bound to the call context to form the original navigation reference. The original navigation reference is used to retain the navigation processing capabilities of the front-end routing object before it is taken over, so that in subsequent navigation processes corresponding to the root page and subpage scene identifiers, the original navigation reference can still be called to complete the page push processing that conforms to the regular history structure of the webpage. When the webpage container runtime identifier matches the mini-program webpage container environment, it indicates that the embedded webpage is in a runtime scenario where the browsing history stack state and the mini-program page return management mechanism interact. At this time, a webpage-side autonomous interception entry is generated based on the original navigation reference. The webpage-side autonomous interception entry is used to receive subsequent webpage navigation trigger requests and complete the processing of the current page routing state, target page routing state, navigation scene identifier, and stack control instructions before the original navigation reference is actually called.
[0025] In this application, the navigation scene identifier is used to represent the page hierarchy combination relationship between the current page routing state and the target page routing state. When generating the navigation scene identifier, the current page hierarchy identifier is parsed from the current page routing state, and the target page hierarchy identifier is parsed from the target page routing state. Then, based on the combination relationship between the current page hierarchy identifier and the target page hierarchy identifier, it is determined whether the current navigation belongs to root page update, root page to subpage, subpage switch, or subpage back to root page. In this application, the navigation scene identifier is not a simple category label, but directly determines the generation method of stack control instructions. Stack control instructions are used to convert the navigation scene identifier into executable browsing history stack state control actions. Stack control instructions can cause the same webpage navigation trigger request to enter different stack update paths under different page hierarchy combinations.
[0026] In this application, when executing stack control instructions through the web-side autonomous interception entry, the web-side autonomous interception entry first receives the stack control instructions, and then calls the navigation call entry matching the stack control instructions to update the browsing history stack state corresponding to the embedded webpage. The browsing history stack state is used to record the order and hierarchical relationship of the loaded page items within the embedded webpage. The updated browsing history stack state reflects the retention status of entry-level page items and non-entry-level page items after the execution of the stack control instructions. The execution feedback of the stack control instructions is used to characterize whether the stack control instructions have completed the corresponding stack update process. Generating control result data based on the updated browsing history stack state and the execution feedback of the stack control instructions allows for a unified result output in this webpage navigation stack control process, facilitating continued page state recording, navigation completion callbacks, or exception handling within the embedded webpage based on the control result data.
[0027] Optionally, obtaining the webpage container running identifier includes: reading the running environment description field of the embedded webpage, extracting the mini-program container feature field from the running environment description field; obtaining a preset container source verification rule, performing container source verification on the mini-program container feature field according to the preset container source verification rule, and obtaining the webpage container running identifier; The method further includes: when the webpage container running identifier matches the mini-program webpage container environment, executing the step of generating a webpage-side autonomous interception entry based on the original navigation reference; when the webpage container running identifier does not match the mini-program webpage container environment, calling the original navigation reference for navigation, and generating regular navigation feedback based on the navigation result.
[0028] Specifically, in this application, the runtime environment description field can be read from the webpage runtime environment of the embedded webpage. The runtime environment description field describes the source, rendering environment, and platform tags of the current webpage runtime container. The runtime environment description field may include browser environment description information from the webpage runtime object, or environment description information injected by the mini-program webpage container when loading the embedded webpage. After reading the runtime environment description field, it is segmented to extract the mini-program container feature field. The mini-program container feature field characterizes whether the current runtime environment possesses the environmental characteristics of the mini-program webpage container environment. The mini-program container feature field can be represented by container source tags, platform type tags, or webpage view container tags related to the mini-program webpage container environment.
[0029] Specifically, in this application, the preset container source verification rule is the environment judgment rule configured during the initialization of the embedded webpage. When configuring the preset container source verification rule, a container source verification rule table can be generated, and the container source tag corresponding to the mini-program webpage container environment can be written into the container source verification rule table, as can the container source tag corresponding to the ordinary browser environment. The container source verification rule table can also be configured with a field reading order, so that the container source verification first reads the container source tag, then the platform type tag, and finally the webpage view container tag. With this setting, even if different mini-program platforms have different field positions in the runtime environment description field, the webpage container runtime identifier can still be obtained through the same preset container source verification rule.
[0030] Specifically, in this application, when verifying the container source of a mini-program container feature field according to a preset container source verification rule, the mini-program container feature field is first converted into a unified field format to form a container source verification field. This verification field is used to eliminate the influence of differences in field case, field separators, and field position on the verification result. Then, the verification field is matched with the container source marker in the preset container source verification rule to obtain the container source matching result. This matching result is used to generate a webpage container running identifier. If the matching result indicates that the verification field matches the container source marker corresponding to the mini-program webpage container environment, then the webpage container running identifier matches the mini-program webpage container environment, and the subsequent step of generating a webpage-side autonomous interception entry based on the original navigation reference is executed. If the matching result indicates that the verification field does not match the mini-program webpage container environment, then the webpage container running identifier does not match the mini-program webpage container environment, and the original navigation reference is called for navigation, and regular navigation feedback is generated based on the navigation result.
[0031] Specifically, in this application, regular navigation feedback refers to the navigation result data returned after the original navigation reference performs navigation. Regular navigation feedback can include results such as whether navigation is complete, whether the target page has been loaded, and whether any exceptions occurred during the navigation process. Regular navigation feedback is used to distinguish it from the execution feedback of stack control instructions in the mini-program webpage container environment, ensuring that the embedded webpage maintains the original navigation behavior of the front-end routing object in a normal browser environment. Through environment-based traffic splitting processing using the webpage container runtime identifier, this application generates an autonomous interception entry point on the webpage side only when the webpage container runtime identifier matches the mini-program webpage container environment, avoiding changes to the original navigation processing in a normal browser environment, thereby reducing the impact on page navigation in a normal browser environment.
[0032] Optionally, the step of generating an original navigation reference based on the front-end routing object, and generating a web-side autonomous interception entry based on the original navigation reference when the web page container runtime identifier matches the mini-program web page container environment, includes: Read the navigation call entry point from the front-end route object, and generate the original navigation reference based on the navigation call entry point; Obtain the preset route processing order, and generate a custom navigation entry based on the original navigation reference and the preset route processing order; When the webpage container runtime identifier matches the mini-program webpage container environment, the custom navigation entry is configured as the webpage-side autonomous interception entry, so that the webpage-side autonomous interception entry calls the original navigation reference according to the preset routing processing order.
[0033] Specifically, in this application, the navigation call entry point is a callable entry point in the front-end route object used to initiate page navigation. When reading the navigation call entry point in the front-end route object, the page push entry point can be read from the navigation properties of the front-end route object, or the page navigation entry point can be read from the navigation method table of the front-end route object. After reading the navigation call entry point, a call context binding is performed on the navigation call entry point to generate the original navigation reference. Call context binding is used to retain the original calling object of the front-end route object, so that when the original navigation reference is called, it can still access the path resolution configuration, history writing configuration, and navigation completion callback configuration in the front-end route object. The original navigation reference is generated by the navigation call entry point, and subsequent custom navigation entries retain their original navigation capabilities through the original navigation reference.
[0034] Specifically, in this application, the preset route processing order is the navigation takeover processing order configured during the embedded webpage initialization phase. The preset route processing order can include environment identification order, route state generation order, scene identification order, instruction generation order, and original navigation reference invocation order. The environment identification order is used to first obtain the webpage container's running identifier; the route state generation order is used to generate the current page route state and the target page route state before the actual page loads; the scene identification order is used to generate a navigation scene identifier based on the current page route state and the target page route state; the instruction generation order is used to generate stack control instructions according to the navigation scene identifier; and the original navigation reference invocation order is used to invoke the original navigation reference when the stack control instructions require the retention of regular page push processing. After the preset route processing order enters the custom navigation entry point, the custom navigation entry point can complete navigation interception and navigation distribution according to a fixed timing sequence, avoiding the technical breakpoint of executing page loading before the route state is generated after the navigation invocation entry point is replaced.
[0035] Specifically, in this application, when generating a custom navigation entry based on the original navigation reference and the preset route processing order, a navigation reference storage item containing the original navigation reference is first generated. This navigation reference storage item is used to store the call address and call context of the original navigation reference. Then, a route processing sequence item containing the preset route processing order is generated. This route processing sequence item is used to record the execution order of each processing step within the webpage-side autonomous interception entry. Subsequently, the navigation reference storage item and the route processing sequence item are combined to generate the custom navigation entry. After receiving a webpage navigation trigger request, the custom navigation entry first reads the webpage container's running identifier, then generates the current page route state and the target page route state, then generates a navigation scene identifier and stack control instructions, and finally determines whether to call the original navigation reference based on the stack control instructions. The custom navigation entry is generated jointly by the original navigation reference and the preset route processing order, which can preserve the original navigation capabilities while bringing the navigation scene recognition process forward to before page loading.
[0036] Specifically, in this application, when the webpage container runtime identifier matches the mini-program webpage container environment, the custom navigation entry is configured as the webpage-side autonomous interception entry. The configuration process can be completed by replacing the navigation call entry in the front-end routing object. After the replacement, when a webpage navigation trigger request enters the front-end routing object, it will first reach the webpage-side autonomous interception entry. The webpage-side autonomous interception entry then determines whether the original navigation reference should be called according to the preset routing processing order. Thus, the webpage-side autonomous interception entry and the original navigation reference are not mutually exclusive. Instead, the webpage-side autonomous interception entry first generates the navigation scene identifier and stack control instructions, and then calls the original navigation reference or the navigation call entry matching the stack control instructions according to the stack control instructions. This ensures that the front-end routing object retains its original navigation capabilities even after being taken over.
[0037] Optionally, the current page routing state is generated in the following way: Obtain the current webpage address of the embedded webpage, and extract the current path field and the current query field from the current webpage address; According to the preset entry path rules, the current path field is normalized to obtain the current page level identifier; The current page routing state is generated based on the current page level identifier and the current query field.
[0038] Specifically, in this application, the current webpage address is the address information corresponding to the embedded webpage before the webpage navigation trigger request occurs. When obtaining the current webpage address, it can be read from the address status of the embedded webpage or from the current route record of the front-end route object. The current webpage address includes a current path field and a current query field. The current path field indicates the path hierarchy of the current page, and the current query field indicates the parameter content in the current webpage address used to distinguish the page content status. For the error notebook page in the WeChat Mini Program embedded webpage, the current path field can point to the error notebook homepage, the error details page, or the error list page, and the current query field can indicate the question identifier, question category identifier, or page filter condition currently displayed on the page.
[0039] Specifically, in this application, when extracting the current path field and the current query field from the current webpage address, the current webpage address is first parsed to obtain the current address structure parsing result. The current address structure parsing result includes the current path part and the current query part. Then, the current path part is written into the current path field, and the current query part is written into the current query field. The current path field subsequently undergoes path normalization processing, and the current query field, together with the current page level identifier, generates the current page routing state. After this processing, the current page level identifier is used to participate in the generation of navigation scenario identifiers, and the current query field is used to retain the differences between different content states under the same page level, avoiding misjudgments of changes in entry-level page parameters as root page to subpage or subpage switching.
[0040] Specifically, in this application, the pre-defined entry path rule is used to determine whether the current path field corresponds to an entry-level page. The pre-defined entry path rule can be configured during the embedded webpage initialization phase. It includes an entry path field, an entry path equivalence field, and a path end separator processing method. The entry path field represents the path of the embedded webpage's entry-level page; the entry path equivalence field represents empty paths, default paths, and other path formats equivalent to the entry-level page; and the path end separator processing method eliminates differences in path end separators. The pre-defined entry path rule does not depend on the mini-program application's page stack but is determined by the routing configuration within the embedded webpage, thus enabling processing on the same end as the webpage's autonomous entry interception.
[0041] Specifically, in this application, when normalizing the current path field according to the preset entry path rules, the domain name and page fragment portions are first removed to obtain the current path body field. Then, the current path body field is formatted according to the path end separator method to form the current normalized path field. Subsequently, the current normalized path field is matched with the entry path field and entry path equivalent field in the preset entry path rules to generate the current page level identifier. If the current normalized path field matches the entry path field or an entry path equivalent field, the current page level identifier represents the entry level; if the current normalized path field does not match either the entry path field or the entry path equivalent field, the current page level identifier represents a non-entry level. After the current page level identifier is generated, it is used together with the current query field to generate the current page routing state. Therefore, the current page routing state retains both the current page's level attribute and the current page's query parameter state, and can subsequently participate in the generation of navigation scenario identifiers.
[0042] Optionally, the target page routing state is generated in the following manner: Parse the target address parameter in the webpage navigation trigger request to obtain the target path field and the target query field; According to the preset entry path rules, the target path field is normalized to obtain the target page level identifier; The target page routing status is generated based on the target page hierarchy identifier and the target query field.
[0043] Specifically, in this application, the target address parameter is a parameter indicating the target page address in the webpage navigation trigger request. The target address parameter can be passed in when a page component triggers a redirect, or it can be generated when the front-end routing object initiates navigation. When parsing the target address parameter in the webpage navigation trigger request, the target address text in the target address parameter is first read, and then the target address text is parsed to obtain the target address structure parsing result. The target address structure parsing result includes a target path part and a target query part. The target path part is written to the target path field, and the target query part is written to the target query field. The target path field is used to represent the path hierarchy of the target page, and the target query field is used to represent the content status that the target page needs to load. For the error correction notebook page, the target path field can point to the error correction details page or the error correction notebook homepage, and the target query field can carry the target question identifier, target question filter conditions, or target page display parameters.
[0044] Specifically, in this application, before the target path field enters the path normalization process, it needs to be converted into the same path expression format as the current path field. This process is used to avoid the impact on page level determination when the target address parameter contains relative paths, absolute paths, or default paths. The path normalization process first expands the relative path relationships in the target path field to obtain the target path body field; then, it unifies the format of the target path body field according to the path tail separator processing method in the preset entry path rules to form the target normalized path field; subsequently, it matches the target normalized path field with the entry path field and entry path equivalent field in the preset entry path rules to generate the target page level identifier. If the target normalized path field matches the entry path field or the entry path equivalent field, the target page level identifier represents the entry level; if the target normalized path field does not match the entry path field and does not match the entry path equivalent field, the target page level identifier represents the non-entry level.
[0045] Specifically, in this application, the target page level identifier and the target query field jointly generate the target page routing state. The target page routing state subsequently participates in both the generation of navigation scene identifiers and the generation of stack control instructions. The target page level identifier is used to enable the navigation scene identifier to identify whether the target page belongs to the entry level or a non-entry level; the target query field is used to generate the root page update address during the processing corresponding to the root page update scene identifier, and also to generate the entry level update address during the processing corresponding to the subpage return-to-root page scene identifier. By incorporating both the target page level identifier and the target query field into the target page routing state, this application can distinguish between changes in the target page level and changes in target page parameters, thereby reducing the situation where the same entry level page is repeatedly pushed into the browsing history stack state due to parameter changes.
[0046] Optionally, generating a navigation scene identifier based on the current page routing state and the target page routing state includes: The current page level identifier is parsed from the current page routing state, and the target page level identifier is parsed from the target page routing state; The current page level identifier and the target page level identifier are combined and identified to obtain the level combination identification result; If the hierarchical combination identification result indicates that both are entry levels, a root page update scenario identifier is generated; if it indicates that only the target page hierarchical identifier is a non-entry level, a root page to subpage scenario identifier is generated; if it indicates that both are non-entry levels, a subpage switching scenario identifier is generated; if it indicates that only the target page hierarchical identifier is an entry level, a subpage back to root page scenario identifier is generated. The generated scene identifier is used as the navigation scene identifier.
[0047] Specifically, in this application, during the process of generating navigation scene identifiers for the current page routing state and the target page routing state, the current page level identifier and the target page level identifier are first parsed separately. The current page level identifier reflects the page level of the embedded webpage before the current navigation occurred, and the target page level identifier reflects the page level to be entered during this navigation. The combination relationship between the current page level identifier and the target page level identifier determines which update method should be used for the browsing history stack state. If stack control instructions are generated only based on the target page routing state, the current page level information will be lost, making it impossible to distinguish between different scenarios such as root page update, subpage switching, and subpage returning to the root page; if stack control instructions are generated only based on the current page routing state, it is impossible to determine whether the target page needs to be retained in the browsing history stack state. Therefore, this application performs level combination recognition on the current page level identifier and the target page level identifier to obtain the level combination recognition result.
[0048] Specifically, in this application, the hierarchical combination recognition result can be generated through a preset hierarchical combination rule table. The hierarchical combination rule table is configured during the embedded webpage initialization phase and includes the correspondence between the current page hierarchical identifier, the target page hierarchical identifier, and the navigation scene identifier. When generating the hierarchical combination recognition result, the current page hierarchical identifier is first written into the hierarchical combination recognition input item, then the target page hierarchical identifier is written into the hierarchical combination recognition input item, and subsequently, the hierarchical combination recognition result matching the hierarchical combination recognition input item is read according to the hierarchical combination rule table. The hierarchical combination recognition result is used to express the hierarchical change method between the current page and the target page, and subsequently directly participates in the generation of the navigation scene identifier.
[0049] Specifically, in this application, when the hierarchy combination identification result indicates that both the current page hierarchy identifier and the target page hierarchy identifier are entry-level, a root page update scenario identifier is generated. The root page update scenario identifier indicates that this navigation only updates the query parameters or content status of the entry-level page, and should not add new entry-level page items to the browsing history stack. When the hierarchy combination identification result indicates that the current page hierarchy identifier is an entry-level page and the target page hierarchy identifier is a non-entry-level page, a root page to subpage scenario identifier is generated. The root page to subpage scenario identifier indicates that this navigation needs to enter a non-entry-level page from an entry-level page, and the browsing history stack should retain the entry-level page item and push the non-entry-level page item onto it. When the hierarchy combination identification result indicates that both the current page hierarchy identifier and the target page hierarchy identifier are non-entry-level, a subpage switching scenario identifier is generated. The subpage switching scenario identifier indicates that this navigation occurs between non-entry-level pages, and the browsing history stack should not continuously add non-entry-level page items. When the hierarchy combination recognition result indicates that the current page hierarchy is a non-entry level and the target page hierarchy is an entry level, a subpage-to-root-page scenario identifier is generated. The subpage-to-root-page scenario identifier indicates that this navigation needs to return from a non-entry level page to an entry level page. The browsing history stack should first return to an existing entry level page item before updating the entry level page item.
[0050] Specifically, in this application, after the generated scene identifier is used as the navigation scene identifier, the navigation scene identifier enters the stack control instruction generation process. The navigation scene identifier is not a separately stored state label, but rather the direct basis for the generation of subsequent stack control instructions. The root page update scene identifier guides the generation of root page replacement instructions, the root page to child page scene identifier guides the generation of child page push instructions, the child page switch scene identifier guides the generation of child page replacement instructions, and the child page back to root page scene identifier guides the generation of back replacement instructions. Through this hierarchical combination recognition process, this application transforms the page hierarchy into an executable stack control direction, enabling different webpage navigation trigger requests to be executed according to the corresponding browsing history stack state update method.
[0051] Optionally, generating stack control instructions according to the navigation scenario identifier includes: Obtain the navigation scene identifier and the target page routing status; If the navigation scenario identifier is a root page update scenario identifier, then a root page replacement instruction is generated based on the target page routing status; If the navigation scenario identifier is a root page to subpage scenario identifier, then a subpage push instruction is generated based on the original navigation reference and the target page routing state; If the navigation scenario identifier is a subpage switching scenario identifier, then a subpage replacement instruction is generated based on the target page routing status; If the navigation scenario identifier is a subpage to root page scenario identifier, then a back-to-back replacement instruction is generated based on the target page routing status; The generated instructions are used as the stack control instructions.
[0052] Specifically, in this application, the stack control instruction is a stack state update instruction that can be executed by the autonomous interception entry point on the webpage. When generating the stack control instruction, it is necessary to simultaneously obtain the navigation scene identifier and the target page routing state. The navigation scene identifier indicates the type of stack control instruction, while the target page routing state provides the basis for instruction generation, such as the target page hierarchy identifier, target path field, and target query field. If the stack control instruction is generated only based on the navigation scene identifier, it cannot determine the target address to be loaded; if it is generated only based on the target page routing state, it cannot distinguish whether the current page item should be replaced or a newly added page item should be pushed. Therefore, this application inputs both the navigation scene identifier and the target page routing state into the stack control instruction generation process.
[0053] Specifically, in this application, if the navigation scenario identifier is a root page update scenario identifier, a root page replacement instruction is generated based on the target page routing state. The root page replacement instruction includes the root page update address corresponding to the target query field and the invocation method for replacing the navigation entry point. The root page replacement instruction is used to update the entry-level page item to the entry-level page item corresponding to the target page routing state, ensuring that no new entry-level page item is added to the browsing history stack due to changes in entry-level page parameters. This process differs from page push processing, which adds new page items to the browsing history stack, while the root page replacement instruction updates existing entry-level page items using the target page routing state.
[0054] Specifically, in this application, if the navigation scenario identifier is a root page to subpage scenario identifier, a subpage push instruction is generated based on the original navigation reference and the target page routing state. The subpage push instruction includes the target path field in the original navigation reference and the target page routing state. The subpage push instruction needs to use the original navigation reference because the root page to subpage scenario identifier corresponds to the page push processing from an entry-level page to a non-entry-level page, and the browsing history stack state needs to retain entry-level page items and add non-entry-level page items. The original navigation reference retains the original page push capability of the front-end routing object. Therefore, the subpage push instruction implements page push processing through the original navigation reference, so that the browsing history stack state forms a page item order with entry-level page items first and non-entry-level page items last.
[0055] Specifically, in this application, if the navigation scenario identifier is a subpage switching scenario identifier, a subpage replacement instruction is generated based on the target page routing state. The subpage replacement instruction includes the subpage update address corresponding to the target path field and the method for invoking the replacement navigation entry. The subpage replacement instruction is used to replace the current non-entry-level page item in the browsing history stack with the non-entry-level page item corresponding to the subpage update address, ensuring that switching between non-entry-level pages does not continuously increase the depth of the browsing history stack. This processing is suitable for scenarios such as switching from the incorrect question details page to the incorrect question list page, or switching from the incorrect question list page to another incorrect question details page. The browsing history stack retains the entry-level page item and updates the current non-entry-level page item with the non-entry-level page item corresponding to the subpage update address.
[0056] Specifically, in this application, if the navigation scenario identifier is a subpage-to-root-page scenario identifier, a fallback replacement instruction is generated based on the target page's routing state. The fallback replacement instruction includes the target routing information corresponding to the target page's routing state, the fallback navigation entry call method, and the replacement navigation entry call method. The fallback replacement instruction does not directly push the target page onto the browsing history stack; instead, it triggers a process of first falling back to an existing entry-level page item and then updating that entry-level page item. This process reduces the occurrence of multiple entry-level page items in the browsing history stack, lowering the probability of repeated fallbacks between entry-level page items. After generating the fallback replacement instruction, it is used as a stack control instruction, subsequently executed by the webpage's autonomous interception entry. Through the above processing, the navigation scenario identifier is transformed into a root page replacement instruction, a subpage push instruction, a subpage replacement instruction, or a fallback replacement instruction, thus giving the stack control instruction a clear execution direction and target routing basis.
[0057] Optionally, the step of executing the stack control instruction through the autonomous interception entry point on the webpage to update the browsing history stack state corresponding to the embedded webpage includes: When the stack control instruction is the root page replacement instruction, the target query field is parsed from the target page routing state, and the root page update address is generated based on the target query field. The root page update address is loaded by calling the replacement navigation entry through the autonomous interception entry on the web page, so that an entry-level page item is retained in the browsing history stack state; Based on the entry-level page item, the execution feedback of the root page replacement instruction is generated as the execution feedback of the stack control instruction.
[0058] Specifically, in this application, the root page replacement instruction is used to handle parameter update scenarios between entry-level pages. An entry-level page is the entry page of an embedded webpage, and an entry-level page item is the page item recorded in the browsing history stack. The root page replacement instruction does not add new entry-level page items to the browsing history stack; instead, it replaces existing entry-level page items with the entry-level page item corresponding to the root page update address. The target page routing state includes a target query field, which describes the target content state of the entry-level page. For example, when switching from one question filter to another on the homepage of the error correction notebook, the target query field can represent the changed question filter. The path hierarchy of the entry-level page remains unchanged, therefore, no new entry-level page item needs to be added for this navigation.
[0059] Specifically, in this application, when parsing the target query field from the target page routing state, the target page hierarchy identifier in the target page routing state is read first; when the target page hierarchy identifier indicates an entry level, the target query field in the target page routing state is then read. After reading the target query field, the target query field is normalized to form the root page query field. The root page query field is used to retain the page content parameters in the target query field and eliminate invalid separator differences in the target query field. Subsequently, the root page update address is generated according to the entry path field in the preset entry path rule and the root page query field. The root page update address includes the entry path field and the root page query field, and the root page update address is used to point to the updated entry level page. The root page update address is generated by the target query field, and the root page update address is subsequently loaded by the replaced navigation entry, thereby enabling the target query field to participate in the update process of the browsing history stack state.
[0060] Specifically, in this application, the replacement navigation entry is a navigation call entry used to perform page replacement loading. The replacement navigation entry differs from the original navigation reference. While the original navigation reference retains the original page push processing capabilities of the front-end route object, the replacement navigation entry is used to replace the current page item. When the web-side autonomous interception entry calls the replacement navigation entry to load the root page update address, the replacement navigation entry updates the current entry-level page item according to the root page update address, changing the address information of existing entry-level page items in the browsing history stack to the root page update address. This process ensures that only one entry-level page item remains in the browsing history stack, rather than forming multiple entry-level page items. For scenarios where entry-level page parameters change, this process reduces the likelihood of the mini-program's page return management mechanism repeatedly backtracking between multiple entry-level page items.
[0061] Specifically, in this application, the execution feedback of the root page replacement instruction is generated by the entry-level page item. After the replacement navigation entry loads the root page update address, the entry-level page item in the browsing history stack state is read, and it is verified whether the page address of the entry-level page item corresponds to the root page update address. If the entry-level page item corresponds to the root page update address, a root page replacement completion status is generated based on the entry-level page item, and the root page replacement completion status is written into the execution feedback of the root page replacement instruction. If the entry-level page item does not correspond to the root page update address, a root page replacement exception status is generated based on the entry-level page item, and the root page replacement exception status is written into the execution feedback of the root page replacement instruction. The execution feedback of the root page replacement instruction is used as the execution feedback of the stack control instruction and enters the subsequent control result data generation process, so that the control result data can reflect the changes in the browsing history stack state after the execution of the root page replacement instruction.
[0062] Optionally, the step of executing the stack control instruction through the autonomous interception entry point on the webpage to update the browsing history stack state corresponding to the embedded webpage includes: When the stack control instruction is the subpage replacement instruction, the target path field is parsed from the target page routing state, and the subpage update address is generated based on the target path field. Read the current non-entry-level page item from the browsing history stack state; The webpage autonomous interception entry is used to call and replace the navigation entry to load the subpage update address, so that the current non-entry level page item is covered by the page item corresponding to the subpage update address; Based on the currently non-entry level page item after overwriting, the execution feedback of the subpage replacement instruction is generated as the execution feedback of the stack control instruction.
[0063] Specifically, in this application, the subpage replacement instruction is used to handle switching scenarios between non-entry-level pages. A non-entry-level page is a page entered after an entry-level page, such as a question details page or a question list page. The current non-entry-level page item is the non-entry-level page item currently at the top or currently displayed position in the browsing history stack. The subpage replacement instruction is used to overwrite the current non-entry-level page item with the non-entry-level page item corresponding to the subpage update address, so that switching between non-entry-level pages does not further increase the number of non-entry-level page items in the browsing history stack. This processing differs from page pushing processing, which adds new non-entry-level page items to the browsing history stack, while the subpage replacement instruction retains the entry-level page item and replaces the current non-entry-level page item.
[0064] Specifically, in this application, when parsing the target path field from the target page routing state, the target page hierarchy identifier in the target page routing state is read first; when the target page hierarchy identifier indicates a non-entry level, the target path field in the target page routing state is then read. The target path field is used to represent the path hierarchy of the target non-entry level page. After reading the target path field, path normalization processing is performed on the target path field to form a subpage path field. The subpage path field is used to eliminate relative path differences, tail segment differences, and page fragment differences in the target path field. When generating the subpage update address based on the subpage path field, the subpage path field is combined with the target query field in the target page routing state so that the subpage update address includes both the path hierarchy of the target non-entry level page and the content parameters of the target non-entry level page. The subpage update address is subsequently loaded by the replacement navigation entry to participate in the overwriting processing of the current non-entry level page item.
[0065] Specifically, in this application, when reading the current non-entry-level page item from the browsing history stack, the page item order in the browsing history stack is read first, and then the page item corresponding to the currently displayed page is determined based on the page item order. If the page item corresponding to the currently displayed page has a non-entry-level page, then the page item corresponding to the currently displayed page is determined as the current non-entry-level page item. The current non-entry-level page item is used to participate in the page item overwrite process. If there is no current non-entry-level page item in the browsing history stack, a subpage replacement exception state can be generated based on the subpage update address, and the subpage replacement exception state can be written into the execution feedback of the subpage replacement instruction to avoid continuing to execute the page item overwrite process when there is no replaceable page item.
[0066] Specifically, in this application, after the webpage autonomous interception entry calls the replacement navigation entry to load the subpage update address, the replacement navigation entry writes the non-entry-level page item corresponding to the subpage update address to the current non-entry-level page item's location, thus overwriting the current non-entry-level page item with the non-entry-level page item corresponding to the subpage update address. The overwritten current non-entry-level page item remains in the original position of the current non-entry-level page item in the browsing history stack, only its page address and page parameters change to those corresponding to the subpage update address. Through this page item overwriting process, entry-level page items in the browsing history stack are still retained, and the number of non-entry-level page items in the browsing history stack does not continuously increase due to the page switching scenario identifier.
[0067] Specifically, in this application, when generating the execution feedback of the subpage replacement instruction based on the overwritten current non-entry-level page item, the page address of the overwritten current non-entry-level page item is first read, and then the page address of the overwritten current non-entry-level page item is compared with the subpage update address. If the overwritten current non-entry-level page item corresponds to the subpage update address, a subpage replacement completion status is generated and written into the execution feedback of the subpage replacement instruction. If the overwritten current non-entry-level page item does not correspond to the subpage update address, a subpage replacement exception status is generated and written into the execution feedback of the subpage replacement instruction. The execution feedback of the subpage replacement instruction participates in the subsequent control result data generation process as the execution feedback of the stack control instruction, enabling the control result data to reflect the update result of the subpage replacement instruction on the browsing history stack state.
[0068] Optionally, the step of executing the stack control instruction through the autonomous interception entry point on the webpage to update the browsing history stack state corresponding to the embedded webpage includes: When the stack control instruction is the rollback replacement instruction, a pending navigation state is generated according to the target page routing state. The pending navigation state includes target routing information, navigation completion feedback entry, and navigation failure feedback entry. The web-based autonomous interception entry calls the back navigation entry to perform a back operation, generating a waiting route change state; The pending navigation state is associated with the waiting route change state so that the waiting route change state can be used to trigger subsequent update processing of the browsing history stack state.
[0069] Specifically, in this application, the back-and-replace instruction is used to handle scenarios where a non-entry-level page returns to an entry-level page. If this scenario directly enters the entry-level page through page push processing, the browsing history stack will retain existing entry-level page items, the current non-entry-level page items, and newly added entry-level page items, making it easy to repeatedly switch between multiple entry-level page items when returning later. If this scenario directly loads the entry-level page by replacing the navigation entry, the current non-entry-level page items in the browsing history stack will be replaced by entry-level page items, while existing entry-level page items may still be retained, resulting in multiple entry-level page items still existing. This application triggers a back-and-replace operation first through the back-and-replace instruction, and then updates the entry-level page items after the back-and-replace operation is completed, so that the browsing history stack returns to the existing entry-level page items before being updated.
[0070] Specifically, in this application, when generating the pending navigation state based on the target page routing state, the target page level identifier in the target page routing state is first read. When the target page level identifier indicates an entry level, the target query field and target path field in the target page routing state are read, and target routing information is generated based on the target query field and target path field. The target routing information describes the entry level page address that needs to be loaded after the fallback operation is completed. Subsequently, a navigation completion feedback entry and a navigation failure feedback entry are generated. The navigation completion feedback entry is used to generate fallback replacement completion feedback after the fallback replacement instruction is successfully completed, and the navigation failure feedback entry is used to generate fallback execution feedback when the fallback replacement instruction is not completed as expected. The target routing information, the navigation completion feedback entry, and the navigation failure feedback entry together form the pending navigation state, so that the subsequent asynchronous navigation process has a readable target address basis and a returnable feedback entry.
[0071] Specifically, in this application, the back navigation entry is a navigation call entry used to perform browsing history stack state rollback processing. When the web-side autonomous interception entry calls the back navigation entry to perform a rollback operation, the back navigation entry rolls the browsing history stack state back from the current non-entry-level page item to an existing entry-level page item. After the rollback operation is executed, it cannot be immediately determined that the browsing history stack state has completed the rollback, because the rollback result of the browsing history stack state needs to be confirmed through route post-change events. Therefore, the web-side autonomous interception entry generates a waiting route change state after calling the back navigation entry. The waiting route change state is used to indicate that it is currently waiting for a route post-change event triggered by the rollback operation. The waiting route change state subsequently participates in route post-change event listening and also participates in timeout entry association.
[0072] Specifically, in this application, when associating a pending navigation state with a waiting route change state, the status identifier of the pending navigation state can be written into the waiting route change state, or vice versa. The associated pending navigation state can provide the waiting route change state with target route information, navigation completion feedback entry, and navigation failure feedback entry; the associated waiting route change state can trigger subsequent update processing of the browsing history stack state. Through this association, the route post-change event after the rollback operation is completed can find its corresponding pending navigation state and continue to execute the entry-level page item update processing based on the target route information in the pending navigation state.
[0073] Optionally, after generating the waiting-for-route-change-change-state, the following is also included: Based on the waiting route change state, listen for subsequent route change events; When the route post-change event matches the navigation state to be processed, an entry-level update address is generated based on the target route information in the navigation state to be processed. By calling the navigation entry through the autonomous interception entry on the web page, the entry level update address is loaded, so that the entry level page items in the browsing history stack are updated according to the entry level update address; Clear the pending navigation state and the waiting route change state, and generate a fallback replacement completion feedback through the navigation completion feedback entry; The feedback indicating that the rollback replacement is completed is used as the execution feedback for the rollback replacement instruction.
[0074] Specifically, in this application, the route post-change event is an event triggered after the webpage route change is completed. The route post-change event indicates that the embedded webpage has completed the page route change after the back navigation entry point performs a back operation. When listening for the route post-change event based on the waiting route change state, the state identifier corresponding to the waiting route change state is first read, and then this state identifier is written into the route post-change event listening condition, so that the listened-for route post-change event can establish a correspondence with the waiting route change state. Since the waiting route change state is already associated with the pending navigation state, after the route post-change event is listened to, it can be further matched with the pending navigation state.
[0075] Specifically, in this application, when a route post-change event matches a pending navigation state, it indicates that the route post-change event is a route post-change event generated after the rollback operation corresponding to the rollback replacement instruction is completed. The matching process can be determined based on the target route information in the pending navigation state, the status identifier of the waiting route change state, and the current page hierarchy information in the route post-change event. If the current page hierarchy information in the route post-change event indicates that the user has returned to the entry level page, and the route post-change event can be associated with the waiting route change state, then the route post-change event matches the pending navigation state. After matching, the target route information is read from the pending navigation state, and the entry level update address is generated based on the target route information.
[0076] Specifically, in this application, the entry-level update address is used to update the entry-level page item that has been returned to after a back navigation operation. When generating the entry-level update address, the target path field and target query field can be read from the target routing information. The target path field is used to determine the path portion of the entry-level page, and the target query field is used to determine the parameter portion of the entry-level page. After combining the target path field and target query field to form the entry-level update address, the entry-level update address enters the loading process for replacing the navigation entry. Through the entry-level update address, the existing entry-level page item returned to by the back navigation operation can be updated to the entry-level page item corresponding to the target page routing state, instead of pushing a new entry-level page item onto the browsing history stack.
[0077] Specifically, in this application, when the webpage autonomously intercepts the entry point and calls the replacement navigation entry point to load the entry level update address, the replacement navigation entry point updates the entry level page items in the browsing history stack state according to the entry level update address. This update process occurs after the rollback operation is completed, therefore, the updated items are the existing entry level page items in the browsing history stack state. After the entry level page items in the browsing history stack state are updated, the target route information in the pending navigation state has completed its corresponding page loading purpose, and the waiting route change state has also completed its corresponding route change waiting purpose. Therefore, the pending navigation state and the waiting route change state are cleared. Clearing the pending navigation state and the waiting route change state can reduce the possibility of mismatches in subsequent route change events and also reduce the continuous occupation of webpage runtime memory by useless states.
[0078] Specifically, in this application, when generating the fallback / replacement completion feedback through the navigation completion feedback entry, the update result of the entry-level page item is read and written into the fallback / replacement completion feedback. The fallback / replacement completion feedback indicates that the fallback / replacement instruction has completed the update of the browsing history stack state through the fallback operation and replacement loading. After using the fallback / replacement completion feedback as the execution feedback of the fallback / replacement instruction, the execution feedback of the fallback / replacement instruction is further used as the execution feedback of the stack control instruction and enters the control result data generation process. In this way, the control result data can reflect whether the fallback / replacement instruction has completed the update of the entry-level page item through the route post-change event under the subpage to root page scenario identifier.
[0079] Optionally, after generating the waiting-for-route-change-change-state, the following is also included: Start the timeout entry corresponding to the pending navigation state, and associate the timeout entry with the waiting route change state; When the timeout entry expires and no route post-change event matching the pending navigation state is detected, a fallback replacement address is generated based on the target route information in the pending navigation state. The web-based autonomous interception entry calls the replacement navigation entry to load the fallback replacement address, causing the entry-level page items in the browsing history stack to be updated according to the fallback replacement address; Clear the pending navigation state and the waiting route change state, and generate fallback execution feedback through the navigation failure feedback entry; The fallback execution feedback is used as the execution feedback for the rollback replacement instruction.
[0080] Specifically, in this application, the timeout entry is used to handle the situation where no matching route change event is detected after a rollback operation. Generating a waiting route change state indicates that the rollback replacement instruction has entered the waiting route change phase. If the waiting route change state does not receive a matching route change event for an extended period, neither the navigation completion feedback entry nor the navigation failure feedback entry in the pending navigation state can be triggered, potentially causing the webpage navigation trigger request to remain in a non-response state. To mitigate this, a timeout entry corresponding to the pending navigation state is started after generating the waiting route change state, ensuring that the rollback replacement instruction can still enter the fallback processing path even if the route change event does not occur in time.
[0081] Specifically, in this application, the timeout entry can be configured after the pending navigation state is generated, or after the waiting route change state is generated. The timeout entry includes a timing start point, a timing period, and a timing expiration action. The timing start point can correspond to the time when the fallback navigation entry is invoked, the timing period can be configured according to the page route change response time of the embedded webpage, and the timing expiration action is used to trigger the generation of a fallback replacement address. When associating the timeout entry with the waiting route change state, the status identifier of the waiting route change state can be written into the timeout entry, so that the waiting route change state can be located after the timeout entry expires; alternatively, the entry identifier of the timeout entry can be written into the waiting route change state, so that the timeout entry can be canceled when the route post-change event matches successfully in advance.
[0082] Specifically, in this application, when the timeout entry expires and no route post-change event matching the pending navigation state is detected, it indicates that the rollback operation has not triggered a route post-change event that can be used to continue loading replacements within the timeout period. At this time, the target route information is read from the pending navigation state, and a fallback replacement address is generated based on the target route information. Both the fallback replacement address and the entry-level update address originate from the target route information, but their uses differ: the entry-level update address is used to update entry-level page items after a route post-change event is matched, while the fallback replacement address is used for alternative updates when a route post-change event is not matched. The fallback replacement address ensures that entry-level page items in the browsing history stack can still be updated according to the target route information, reducing the likelihood of no feedback from rollback replacement commands.
[0083] Specifically, in this application, when the web-based autonomous interception entry calls the replacement navigation entry to load the fallback replacement address, the replacement navigation entry updates the entry-level page item in the browsing history stack state according to the fallback replacement address. If the browsing history stack state has fallen back to the entry-level page item, the replacement navigation entry directly updates the entry-level page item with the fallback replacement address; if the browsing history stack state has not fallen back to the entry-level page item, the replacement navigation entry can replace the current page item with the fallback replacement address and generate fallback execution feedback based on the replacement result. After the fallback replacement address is loaded, the pending navigation state and the waiting route change state no longer need to be retained, so the pending navigation state and the waiting route change state are cleared, and fallback execution feedback is generated through the navigation failure feedback entry.
[0084] Specifically, in this application, the fallback execution feedback is used to indicate that the fallback replacement instruction entered the fallback processing path when no matching route post-change event was detected. The fallback execution feedback may include the fallback replacement address, the fallback replacement address loading result, and the update result of the entry-level page item in the browsing history stack state. By using the fallback execution feedback as the execution feedback for the fallback replacement instruction, the execution feedback of the fallback replacement instruction can reflect the fallback processing triggered by the timeout entry. This execution feedback then enters the control result data generation process, enabling the caller to know that the fallback replacement instruction corresponding to the current subpage to root page scenario identifier was not completed through a route post-change event, but rather through the fallback replacement address to update the browsing history stack state.
[0085] Optionally, generating a custom navigation entry based on the original navigation reference and the preset route processing order includes: Read the route library type identifier of the front-end route object; The navigation adaptation rules are determined based on the routing library type identifier. The navigation adaptation rules are used to limit the calling format and calling return format of the original navigation reference. A route call adaptation entry is generated based on the navigation adaptation rules; Based on the route call adaptation entry, the original navigation reference, and the preset route processing order, the custom navigation entry is generated, and the custom navigation entry triggers the route call adaptation entry according to the preset route processing order, and calls the original navigation reference through the route call adaptation entry; Configure the custom navigation entry as the web-based autonomous interception entry.
[0086] Specifically, in this application, the route library type identifier is used to indicate the route implementation type to which the front-end route object belongs. Different front-end route objects differ in their navigation call entry points, call parameter formats, and call return formats. When reading the route library type identifier of a front-end route object, it can be read from the object properties of the front-end route object, or it can be generated based on the navigation call entry name, navigation return result format, and route record structure in the front-end route object. The route library type identifier is subsequently used to determine navigation adaptation rules, enabling custom navigation entries to call the original navigation reference according to the calling format of the front-end route object.
[0087] Specifically, in this application, navigation adaptation rules are invocation adaptation rules configured during the embedded webpage initialization phase or the route takeover phase. Navigation adaptation rules are used to define the invocation format and return format of the original navigation reference. The invocation format describes the parameter structure required when the original navigation reference receives the target page's routing status, and the return format describes the data structure returned by the original navigation reference after completing navigation. When determining navigation adaptation rules based on the route library type identifier, the navigation adaptation rule corresponding to the route library type identifier can be read from the preset navigation adaptation rule table. The preset navigation adaptation rule table includes the correspondence between route library type identifiers and navigation adaptation rules. This correspondence can be configured during the embedded webpage packaging phase or read from the local route configuration when the embedded webpage starts.
[0088] Specifically, in this application, when generating a route call adaptation entry based on navigation adaptation rules, the call format in the navigation adaptation rules is first read, and parameter conversion processing is generated based on the call format; then, the call return format in the navigation adaptation rules is read, and return conversion processing is generated based on the call return format. The parameter conversion processing is used to convert the target page route state into navigation parameters that the original navigation reference can receive, and the return conversion processing is used to convert the data returned by the original navigation reference into navigation feedback that the custom navigation entry can recognize. The parameter conversion processing and the return conversion processing together form the route call adaptation entry. The route call adaptation entry is used to connect the custom navigation entry with the original navigation reference, so that the custom navigation entry does not need to directly depend on the specific call format of a certain type of front-end route object.
[0089] Specifically, in this application, when generating a custom navigation entry based on the route invocation adaptation entry, the original navigation reference, and the preset route processing order, the route invocation adaptation entry is first associated with the original navigation reference, enabling the route invocation adaptation entry to invoke the original navigation reference; then, the preset route processing order is written into the custom navigation entry, enabling the custom navigation entry to trigger the route invocation adaptation entry according to the preset route processing order. After receiving a webpage navigation trigger request, the custom navigation entry first generates the current page route state, the target page route state, the navigation scene identifier, and the stack control instruction according to the preset route processing order; when the stack control instruction needs to invoke the original navigation reference, the custom navigation entry triggers the route invocation adaptation entry; the route invocation adaptation entry converts the target page route state into navigation parameters that the original navigation reference can receive, and completes the corresponding navigation processing through the original navigation reference.
[0090] Specifically, in this application, after configuring the custom navigation entry as a web-side autonomous interception entry, the web-side autonomous interception entry can maintain the same external processing flow under different front-end routing objects. For different front-end routing objects, the web-side autonomous interception entry first generates a navigation scenario identifier based on the current page routing state and the target page routing state, and then generates stack control instructions according to the navigation scenario identifier. When the stack control instructions require calling the original navigation reference, the route call adaptation entry completes the call format adaptation and call return format adaptation. In this way, an executable call chain is formed between the route library type identifier, navigation adaptation rules, route call adaptation entry, original navigation reference, and preset route processing order, which can reduce the dependence of the custom navigation entry on the specific implementation of the front-end routing object.
[0091] Optionally, before generating the control result data, the method further includes: Collect entry-level page items and non-entry-level page items from the updated browsing history stack; Obtain the navigation scene identifier, and determine the stack level verification rule from the preset stack level verification rule table based on the navigation scene identifier; The entry-level page item and the non-entry-level page item are verified according to the stack-level verification rules to obtain the stack-level verification result; The execution feedback of the stack control instruction is generated based on the stack level verification result, so that the execution feedback participates in the generation of the control result data.
[0092] Specifically, in this application, entry-level page items and non-entry-level page items are page item types in the browsing history stack state. Entry-level page items represent the entry-level pages of embedded web pages, while non-entry-level page items represent subsequent pages accessed from entry-level pages. When collecting entry-level and non-entry-level page items in the updated browsing history stack state, the page item order in the updated browsing history stack state is first read, and then each page item in the page item order is identified hierarchically according to preset entry path rules. The identification result indicates that entry-level page items are collected as entry-level page items, and the identification result indicates that non-entry-level page items are collected as non-entry-level page items. The subsequent entry-level and non-entry-level page items are then subject to the stack hierarchy verification process.
[0093] Specifically, in this application, the preset stack hierarchy verification rule table is a verification rule table configured during the embedded webpage initialization phase. The preset stack hierarchy verification rule table includes the correspondence between navigation scene identifiers and stack hierarchy verification rules. For the root page update scene identifier, the stack hierarchy verification rule may require that one entry-level page item be retained in the browsing history stack state, and no new non-entry-level page items be added; for the root page to subpage scene identifier, the stack hierarchy verification rule may require that the entry-level page item be retained in the browsing history stack state and new non-entry-level page items be added; for the subpage switching scene identifier, the stack hierarchy verification rule may require that non-entry-level page items in the browsing history stack state be replaced instead of continuously added; for the subpage back to root page scene identifier, the stack hierarchy verification rule may require that the entry-level page items in the browsing history stack state be updated according to the entry-level update address or the fallback replacement address.
[0094] Specifically, in this application, when determining the stack level verification rule from the preset stack level verification rule table based on the navigation scene identifier, the navigation scene identifier corresponding to the current navigation is first read, and then the stack level verification rule corresponding to the navigation scene identifier is searched in the preset stack level verification rule table. The stack level verification rule is used to limit the expected relationship between entry-level page items and non-entry-level page items in the updated browsing history stack state. This expected relationship is not simply a judgment of the number of page items, but a verification basis for the page item hierarchy relationship determined by the navigation scene identifier. Through this process, the stack level verification rule can be kept consistent with the navigation scene identifier, so that the stack level verification result can reflect whether the stack control instruction has completed the browsing history stack state update according to the current navigation scene.
[0095] Specifically, in this application, when verifying entry-level page items and non-entry-level page items according to the stack hierarchy verification rules, the number of entry-level page items, the page addresses of entry-level page items, and the page addresses of non-entry-level page items are first read. Then, the hierarchy relationship of entry-level page items and non-entry-level page items is verified according to the stack hierarchy verification rules. The hierarchy relationship verification may include entry-level page item retention verification, non-entry-level page item overwriting verification, and entry-level page item update verification. After verification, a stack hierarchy verification result is generated. The stack hierarchy verification result is used to indicate whether the updated browsing history stack state conforms to the page item hierarchy relationship corresponding to the navigation scenario identifier.
[0096] Specifically, in this application, when generating execution feedback for stack control instructions based on stack level verification results, if the stack level verification results indicate that the entry-level page item and non-entry-level page items meet the stack level verification rules, then stack state update completion feedback is generated and used as execution feedback for stack control instructions; if the stack level verification results indicate that the entry-level page item and non-entry-level page items do not meet the stack level verification rules, then stack state update exception feedback is generated and used as execution feedback for stack control instructions. The execution feedback of stack control instructions subsequently participates in the generation of control result data, ensuring that the control result data includes not only the browsing history stack state itself but also the feedback information after the browsing history stack state has been verified by the stack level verification rules.
[0097] Optionally, the control result data includes the webpage container running identifier, the navigation scene identifier, the stack control instructions, the updated browsing history stack status, and the execution feedback of the stack control instructions; The step of generating control result data characterizing the webpage navigation stack control result based on the updated browsing history stack state and the execution feedback of the stack control instructions includes: Obtain the webpage container running identifier, the navigation scene identifier, the stack control instructions, the updated browsing history stack status, and the execution feedback of the stack control instructions; The control result data is obtained by encapsulating the webpage container running identifier, the navigation scene identifier, the stack control instruction, the updated browsing history stack status, and the execution feedback of the stack control instruction according to the preset result field order.
[0098] Specifically, in this application, the control result data refers to the result data of this webpage navigation stack control process. The control result data characterizes the result formed after the webpage navigation trigger request enters the webpage's autonomous interception entry point, following environment identification, scene identification, instruction generation, instruction execution, and stack state update. The control result data includes the webpage container running identifier, navigation scene identifier, stack control instructions, the updated browsing history stack state, and the execution feedback of the stack control instructions. The webpage container running identifier characterizes whether this navigation occurs within a mini-program webpage container environment; the navigation scene identifier characterizes the page hierarchy relationship corresponding to this navigation; the stack control instructions characterize the stack control method used for this navigation; the updated browsing history stack state characterizes the page item state after the stack control instructions are executed; and the execution feedback of the stack control instructions characterizes the execution result corresponding to the stack control instructions.
[0099] Specifically, in this application, when obtaining the webpage container running identifier, navigation scenario identifier, stack control instructions, updated browsing history stack state, and execution feedback of stack control instructions, the information is read in the order of generation during the webpage navigation stack control process. First, the webpage container running identifier is read to record whether the current navigation uses webpage-side autonomous interception entry; then, the navigation scenario identifier is read to record the root page update, root page to subpage, subpage switch, or subpage back to root page scenario corresponding to this navigation; subsequently, the stack control instructions are read to record whether the current navigation executes a root page replacement instruction, subpage push instruction, subpage replacement instruction, or back replacement instruction; then, the updated browsing history stack state is read to record entry-level page items and non-entry-level page items in the browsing history stack state; finally, the execution feedback of the stack control instructions is read to record the execution result of the stack control instructions.
[0100] Specifically, in this application, the preset result field order is the result encapsulation order configured during the embedded webpage initialization phase. The preset result field order can include, in sequence, an environment field, a scene field, a command field, a stack state field, and a feedback field. The environment field is used to write the webpage container's running identifier, the scene field is used to write the navigation scene identifier, the command field is used to write the stack control commands, the stack state field is used to write the updated browsing history stack state, and the feedback field is used to write the execution feedback of the stack control commands. The purpose of the preset result field order is to ensure that the control result data has a stable data structure, allowing subsequent navigation completion callbacks, page state recordings, or exception handling to read the control result data according to fixed fields.
[0101] Specifically, in this application, when encapsulating control result data according to the preset result field order, the webpage container running identifier is first written to the environment field, then the navigation scene identifier is written to the scene field, followed by the stack control instructions to the instruction field, then the updated browsing history stack state to the stack state field, and finally the execution feedback of the stack control instructions to the feedback field. After each field is written, the control result data is formed. After the control result data is generated, it can be returned to the caller corresponding to the webpage navigation trigger request, or it can be stored internally as a navigation record within the embedded webpage. Since the control result data simultaneously includes the webpage container running identifier, navigation scene identifier, stack control instructions, the updated browsing history stack state, and the execution feedback of the stack control instructions, the control result data can reflect the environment identification results, scene identification results, instruction generation results, stack state changes, and execution feedback of this webpage navigation stack control process.
[0102] Specifically, in this application, the control result data can also be used for subsequent page state processing, which includes stack state update anomaly location and page state recovery. When the execution feedback of the stack control instructions in the control result data indicates a stack state update anomaly, the page hierarchy combination relationship where the anomaly occurred can be determined based on the navigation scenario identifier in the control result data, and the stack control method where the anomaly occurred can be determined based on the stack control instructions in the control result data. Then, the page item states of the entry-level page items and non-entry-level page items can be read based on the updated browsing history stack state in the control result data. Through this reading process, the embedded webpage can determine whether it needs to re-execute the replacement navigation entry loading or whether it needs to generate regular navigation feedback based on the control result data. Therefore, the control result data is not only used to characterize the navigation results but also to provide readable data basis for subsequent page state processing within the embedded webpage.
[0103] As a more specific implementation, the embedded webpage can be a web application page loaded through a webpage container component within the "Error Correction Notes" mini-program. This webpage container component is the web-view component described in the handover document, and the web application page is the H5 application page described in the handover document. This web application page uses a front-end routing object for page navigation management, which can be a Vue Router object. The navigation call entry point in the front-end routing object can be the `router.push` method, the original navigation reference can be the `originalPush` variable, and the webpage-side autonomous interception entry point can be the custom `customPush` navigation method formed after replacing the `router.push` method. This processing can be written into the webpage-side utility file in the project, for example, in "src / utils / wechatEnvRouterPush.ts", to complete runtime environment detection, `router.push` method retention, `router.push` method replacement, navigation scene identifier generation, stack control instruction generation, and asynchronous navigation processing. Once the web application page initialization phase is completed, the web-based tool file does not require modification of the page stack management code on the mini-program application side, nor does it require the mini-program application side to maintain the internal navigation history of the web application page.
[0104] Specifically, during the initialization phase of the web application page, the `user-agent` field in the web runtime environment is first read. In this embodiment, the `user-agent` field corresponds to the runtime environment description field, used to indicate the source and platform environment of the current web runtime container. When the `user-agent` field contains a marker corresponding to the mini-program web container environment, a web container runtime identifier representing the mini-program web container environment is generated; when the `user-agent` field does not contain a marker corresponding to the mini-program web container environment, a web container runtime identifier representing the ordinary browser environment is generated. After generating the web container runtime identifier representing the mini-program web container environment, the web application page reads the `router.push` method in the Vue Router route object and saves the `router.push` method as the `originalPush` variable, which is the original navigation reference. Subsequently, the web application page replaces the `router.push` method with the `customPush` custom navigation method, which is the autonomous interception entry point on the web page. After the replacement, the page components in the web application page continue to call the router.push method in the original way, but actually enter the customPush custom navigation method first. The customPush custom navigation method completes the processing of the current page routing state, the target page routing state, the navigation scene identifier, and the stack control instructions before executing the original navigation processing.
[0105] In this embodiment, the current page routing state can be generated by the current route record of the Vue Router route object, and the target page routing state can be generated by the target address parameter received by the router.push method. For example, the current path field in the current page routing state can be " / ", " / detail", or " / list", and the current query field can be query parameters such as "id=1" or "updated=true"; the target path field in the target page routing state can be " / ", " / detail", or " / list", and the target query field can be query parameters such as "id=2" or "updated=true". In this embodiment, the page with the path " / " corresponds to the root page, which is the aforementioned entry-level page; the page with the path not " / " corresponds to the child page, which is the aforementioned non-entry-level page. Therefore, both the current page level identifier and the target page level identifier can be obtained by determining whether the path is equal to " / ": when the current path field is " / ", the current page level identifier indicates the entry level; when the current path field is " / detail" or " / list", the current page level identifier indicates a non-entry level; when the target path field is " / ", the target page level identifier indicates the entry level; when the target path field is " / detail" or " / list", the target page level identifier indicates a non-entry level.
[0106] Within the error notebook, the root page can be understood as the error notebook homepage, and the subpages as error detail pages or error list pages. When using pages A, B, and C to represent different page items in the browsing history stack, page A corresponds to the error notebook homepage " / ", page B corresponds to the error detail page " / detail", and page C corresponds to the error list page " / list". If the original `router.push` method is used for continuous navigation, as the user navigates from page A to page B, then to page C, then back to page A, then back to page B, and back to page C, the browsing history stack may form a continuously accumulating sequence of page items such as " / , page B, page C, page A, page B, page C". When the user clicks the mini-program's back button, they will return layer by layer according to this browsing history stack, resulting in repeated layered returns such as page C returning to page B, page B returning to page A, and page A returning to page C. Pages A, B, and C mentioned above are only used to illustrate the order of page items in the browsing history stack. In actual implementation, they can be mapped to the homepage of the error notebook, the error details page, and the error list page, respectively.
[0107] For scenarios involving navigation within the root page, the current page's routing state can be " / ?id=1", and the target page's routing state can be " / ?id=2". In this scenario, both the current path field and the target path field are " / ", and both the current page's hierarchy identifier and the target page's hierarchy identifier represent the entry level. Therefore, the hierarchy combination recognition result indicates that both are entry levels, generating a root page update scenario identifier. The `customPush` custom navigation method generates a root page replacement instruction based on the root page update scenario identifier and parses the target query field "id=2" from the target page's routing state. The target query field "id=2" corresponds to the page content parameter that needs to be updated on the entry level page. Based on the entry path field " / " and the target query field "id=2", the root page update address " / ?id=2" is generated. Subsequently, the `customPush` custom navigation method does not call the `originalPush` variable but instead calls the `router.replace` method to load the root page update address " / ?id=2". In this embodiment, the `router.replace` method replaces the navigation entry point. After execution, the browsing history stack state changes from "[ / ?id=1]" to "[ / ?id=2]", but an entry-level page item is still retained in the browsing history stack state. Therefore, the filtering parameters of the error correction notebook homepage change, but a new entry-level page item corresponding to the root page is not added to the browsing history stack state.
[0108] For the root page to subpage scenario, the current page routing state can be " / ", and the target page routing state can be " / detail". In this scenario, the current page level identifier represents the entry level, and the target page level identifier represents the non-entry level. Therefore, the level combination recognition result indicates that only the target page level identifier is a non-entry level, generating a root page to subpage scenario identifier. The customPush custom navigation method generates a subpage push instruction based on the root page to subpage scenario identifier. The subpage push instruction uses the originalPush variable and the target page routing state to perform page push processing, that is, it continues to call the originalPush variable to load " / detail". After the originalPush variable is called, the browsing history stack state is updated from "[ / ]" to "[ / , / detail]", where " / " corresponds to the entry level page item, and " / detail" corresponds to the non-entry level page item. This processing preserves the page item order from the error notebook homepage to the error details page, so that users can return to the error notebook homepage from the error details page when returning.
[0109] For scenarios involving navigation between subpages, the current page's routing state can be " / detail", and the target page's routing state can be " / list". In this scenario, both the current page's hierarchy identifier and the target page's hierarchy identifier represent non-entry levels. Therefore, the hierarchy combination recognition result indicates that both are non-entry levels, generating a subpage switching scenario identifier. The `customPush` custom navigation method generates a subpage replacement instruction based on the subpage switching scenario identifier and parses the target path field " / list" from the target page's routing state. The target path field " / list" corresponds to the path hierarchy of the target non-entry level page, and a subpage update address " / list" is generated based on the target path field " / list". Subsequently, the `customPush` custom navigation method calls the `router.replace` method to load the subpage update address " / list", causing the current non-entry level page item " / detail" in the browsing history stack to be overwritten by the non-entry level page item corresponding to the subpage update address " / list". After execution, the browsing history stack state is updated from "[ / , / detail]" to "[ / , / list]", instead of being updated to "[ / , / detail, / list]". In this way, when switching from the incorrect question details page to the incorrect question list page, non-entry-level page items will not accumulate continuously, and the subsequent return path will still use the incorrect question book homepage as the entry-level page item.
[0110] For scenarios where a subpage returns to the root page, the current page's routing state can be " / detail", and the target page's routing state can be " / " or " / ?updated=true". In this scenario, the current page's hierarchy identifier indicates a non-entry level, while the target page's hierarchy identifier indicates an entry level. Therefore, the hierarchy combination recognition result indicates that only the target page's hierarchy identifier is an entry level, generating a subpage-to-root-page scenario identifier. The `customPush` custom navigation method generates a back-and-forth replacement instruction based on the subpage-to-root-page scenario identifier. The back-and-forth replacement instruction first generates a pending navigation state based on the target page's routing state, which can be specifically a `pendingNavigation` state. The `pendingNavigation` state stores the target routing information, the navigation completion feedback entry, and the navigation failure feedback entry. The target routing information can be a combination of the target path " / " and the target query field "updated=true"; the navigation completion feedback entry can correspond to the `resolve` callback function in the `Promise` object; and the navigation failure feedback entry can correspond to the `reject` callback function in the `Promise` object. In this embodiment, the `Promise` object is used to represent the final completion or failure result of this asynchronous navigation process.
[0111] After generating the pendingNavigation state, the customPush custom navigation method first calls the router.back method to perform a fallback operation. In this embodiment, the router.back method corresponds to the fallback navigation entry point, used to fall back the browsing history stack state from the current non-entry-level page item " / detail" to the existing entry-level page item " / ". If the current browsing history stack state is "[ / , / detail]", after calling the router.back method, the browsing history stack state is expected to change to "[ / ]". Since the page route change triggered by the router.back method is not completed synchronously, the customPush custom navigation method will not immediately execute the router.replace method, but will generate a waiting route change state and listen for the fallback operation through the route post-change event. The afterEach event in the specification is the route post-change event, which belongs to the navigation post-processing entry point provided by the Vue Router route object, used to trigger subsequent processing after the route change is completed.
[0112] When the `afterEach` route change event is triggered and the route change result of the `afterEach` route change event corresponds to the `pendingNavigation` state, it means that the `router.back` method has returned the web application page to the existing entry-level page item. At this time, the `customPush` custom navigation method reads the target route information from the `pendingNavigation` state and generates the entry-level update address based on the target route information. For example, if the target route information includes the target path " / " and the target query field "updated=true", the entry-level update address is " / ?updated=true". Subsequently, the `customPush` custom navigation method calls the `router.replace` method to load the entry-level update address, so that the entry-level page item in the browsing history stack is updated according to " / ?updated=true". After execution, the browsing history stack state is updated from "[ / ]" to "[ / ?updated=true]". Since the entry-level page item is updated by the router.replace method after the router.back method returns to the existing entry-level page item, the browsing history stack will not retain the entry-level page items corresponding to the two root pages at the same time.
[0113] In the scenario described above where a subpage returns to the root page, the timing of clearing the pendingNavigation state and the return timing of the Promise object should also be specifically defined. After the router.replace method loads the updated address at the entry level, the customPush method clears the pendingNavigation state and the waiting-for-route-change state. Subsequently, the customPush method generates a fallback replacement completion feedback through the resolve callback function. This feedback is used as the execution feedback for the fallback replacement instruction and is entered into the control result data. If the router.back method does not trigger the afterEach route change event, or if the afterEach route change event cannot match the pendingNavigation state after it is triggered, it indicates that the fallback operation did not enter the subsequent replacement timing as expected. In this case, a timeout fallback handling path needs to be entered to prevent the webpage navigation trigger request from remaining in a state without feedback for an extended period.
[0114] In the timeout fallback handling path, a timeout entry can be started after generating the waiting route change state. This timeout entry can specifically correspond to the timeout timer in the disclosure document, and the timeout period can be configured according to the page route change response time; for example, it can be 50 milliseconds. 50 milliseconds is merely an example illustrating the asynchronous route change waiting time; in actual implementation, it can be configured to other durations based on the routing response speed of the web application page. When the timeout entry expires and no afterEach route change event matching the pendingNavigation state is detected, the customPush custom navigation method reads the target route information from the pendingNavigation state and generates a fallback replacement address based on the target route information. The fallback replacement address can be the same as the entry-level update address, for example, " / ?updated=true". Subsequently, the customPush custom navigation method calls the router.replace method to load the fallback replacement address, clears the pendingNavigation state and the waiting route change state, and then generates fallback execution feedback through the reject callback function or the navigation failure feedback entry. The fallback execution feedback is used to indicate that this rollback replacement instruction was not completed through the normal afterEach route post-change event, but was completed through timeout fallback processing to update the browsing history stack state.
[0115] Taking the Vue Router object as an example, the specific code structure can be understood as follows: After route initialization, the `router.push` method is read and saved as the `originalPush` variable; then, the `router.push` method is replaced with the `customPush` custom navigation method; the `customPush` custom navigation method receives the target address parameter, reads the current route record, and determines whether the current path and the target path are equal to " / "; when both the current path and the target path are equal to " / ", the `router.replace` method is called; when the current path is equal to " / " and the target path is not equal to " / ", the `originalPush` variable is called; when the current path is not equal to " / " and the target path is not equal to " / ", the `router.replace` method is called; when the current path is not equal to " / " and the target path is equal to " / ", the `pendingNavigation` state is created first, then the `router.back` method is called, and the `router.replace` method is called again in the `afterEach` route post-change event. Here, the `router.push` method corresponds to pushing the page, the `router.replace` method corresponds to replacing and loading the page, the `router.back` method corresponds to going back in the browsing history stack, the `afterEach` route change event corresponds to the route change event, the `pendingNavigation` state corresponds to the pending navigation state, the `resolve` callback function corresponds to the navigation completion feedback entry, and the `reject` callback function corresponds to the navigation failure feedback entry.
[0116] If implemented using React Router, the aforementioned `router.push`, `router.replace`, and `router.back` methods can be mapped to navigation function calls in React Router, jump functions returned by custom Hooks, and navigation history back calls, respectively. Specifically, the `useNavigate` and `useLocation` functions can be encapsulated in a custom Hook. The `useLocation` function retrieves the current page's route state, and the `useNavigate` function loads the target page's route state. Internally, the custom Hook generates a navigation scenario identifier based on the current and target page's route states, and selects the original navigation, the replacement navigation, or the navigation after backtracking according to the navigation scenario identifier. If implemented using native browser history management capabilities, the aforementioned `router.push` method can be mapped to the `pushState` method, the `router.replace` method to the `replaceState` method, and the `router.back` method to the `history.back` method. The `afterEach` route change event can be equivalently implemented through route change callbacks or page address change listener events. The names may differ in different implementations, but they can all be mapped to the following processing elements: original navigation reference, replacement navigation entry, fallback navigation entry, route post-change event, and navigation state to be processed.
[0117] Through the above specific embodiments, in the web page container scenario of the Error Notes mini-program, this application only completes route interception and browsing history stack state control on the web application page side. For a jump from " / ?id=1" to the root page of " / ?id=2", the browsing history stack state is updated from "[ / ?id=1]" to "[ / ?id=2]"; for a jump from " / " to the root page of " / detail" to a subpage, the browsing history stack state is updated from "[ / ]" to "[ / , / detail]"; for a jump from " / detail" to a subpage of " / list", the browsing history stack state is updated from "[ / , / detail]" to "[ / , / list]"; for a return from " / detail" to the subpage of " / ?updated=true" to the root page, the browsing history stack state is first rolled back from "[ / , / detail]" to "[ / ]" via the router.back method, and then updated to "[ / ?updated=true]" via the router.replace method. None of the above scenarios require the mini-program application to maintain a unified history record, nor do they require cross-platform message notifications to the mini-program application to synchronize the internal navigation history of the web application page. This enables those skilled in the art to directly implement the web page control method of this application based on the runtime environment detection, router.push method replacement, path hierarchy judgment, router.replace method call, router.back method listening for afterEach route change events, pendingNavigation state cleanup, and timeout fallback handling described in this application.
[0118] like Figure 2 As shown, a webpage control device according to an embodiment of this application includes: The navigation status acquisition unit is used to respond to the webpage navigation trigger request of the embedded webpage and acquire the webpage container running identifier, the front-end route object, the current page route status, and the target page route status. The interception entry generation unit is used to generate an original navigation reference based on the front-end routing object, and generate a web-side autonomous interception entry based on the original navigation reference when the web page container running identifier matches the mini-program web page container environment. The stack control instruction generation unit is used to generate a navigation scene identifier based on the current page routing state and the target page routing state, and to generate stack control instructions according to the navigation scene identifier; The stack state update unit is used to execute the stack control instruction through the autonomous interception entry of the web page to update the browsing history stack state corresponding to the embedded web page. The control result generation unit is used to generate control result data representing the control result of the web page navigation stack based on the updated browsing history stack state and the execution feedback of the stack control instructions.
[0119] like Figure 3 As shown, an electronic device according to an embodiment of this application includes a processor and a memory. The memory stores a computer program, which, when executed by the processor, implements the above-described webpage control method.
[0120] like Figure 4 As shown, this is a computer-readable storage medium according to an embodiment of the present application. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the above-described webpage control method.
[0121] like Figure 5 As shown, this is an embodiment of a web page control system, including a mini-program application terminal and an embedded web page runtime terminal. The mini-program application terminal is used to provide a mini-program web page container environment and load the embedded web page runtime terminal in the mini-program web page container environment. The embedded web page runtime is used to respond to the web page navigation trigger request of the embedded web page and obtain the web page container runtime identifier, front-end routing object, current page routing status and target page routing status; The embedded web page runtime is also used to generate an original navigation reference based on the front-end routing object, and generate a web page autonomous interception entry based on the original navigation reference when the web page container runtime identifier matches the mini program web page container environment. The embedded web page runtime is also used to generate a navigation scene identifier based on the current page routing state and the target page routing state, and to generate stack control instructions according to the navigation scene identifier; The embedded web page runtime is also used to execute the stack control instruction through the autonomous interception entry of the web page, and update the browsing history stack state corresponding to the embedded web page runtime. The embedded web page runtime is also used to generate control result data representing the web page navigation stack control result based on the updated browsing history stack state and the execution feedback of the stack control instructions.
[0122] Figures 2-5 For an exemplary description, please refer to the above. Figure 1 This will not be elaborated upon here.
Claims
1. A webpage control method, characterized in that, include: In response to a webpage navigation trigger request from an embedded webpage, obtain the webpage container running identifier, the front-end route object, the current page route status, and the target page route status; Based on the front-end routing object, an original navigation reference is generated, and when the webpage container runtime identifier matches the mini-program webpage container environment, an autonomous interception entry point on the webpage is generated based on the original navigation reference. Based on the current page routing state and the target page routing state, a navigation scene identifier is generated, and stack control instructions are generated according to the navigation scene identifier; The stack control instruction is executed through the autonomous interception entry point on the web page to update the browsing history stack state corresponding to the embedded web page; Based on the updated browsing history stack state and the execution feedback of the stack control instructions, control result data representing the webpage navigation stack control results is generated.
2. The method according to claim 1, characterized in that, The step of obtaining the webpage container running identifier includes: reading the running environment description field of the embedded webpage, extracting the mini-program container feature field from the running environment description field; obtaining a preset container source verification rule, performing container source verification on the mini-program container feature field according to the preset container source verification rule, and obtaining the webpage container running identifier; The method further includes: when the webpage container running identifier matches the mini-program webpage container environment, executing the step of generating a webpage-side autonomous interception entry based on the original navigation reference; when the webpage container running identifier does not match the mini-program webpage container environment, calling the original navigation reference for navigation, and generating regular navigation feedback based on the navigation result.
3. The method according to claim 1, characterized in that, The step of generating an original navigation reference based on the front-end routing object, and generating a web-side autonomous interception entry based on the original navigation reference when the web page container runtime identifier matches the mini-program web page container environment, includes: Read the navigation call entry point from the front-end route object, and generate the original navigation reference based on the navigation call entry point; Obtain the preset route processing order, and generate a custom navigation entry based on the original navigation reference and the preset route processing order; When the webpage container runtime identifier matches the mini-program webpage container environment, the custom navigation entry is configured as the webpage-side autonomous interception entry, so that the webpage-side autonomous interception entry calls the original navigation reference according to the preset routing processing order.
4. The method according to claim 1, characterized in that, The current page routing state is generated in the following way: Obtain the current webpage address of the embedded webpage, and extract the current path field and the current query field from the current webpage address; According to the preset entry path rules, the current path field is normalized to obtain the current page level identifier; The current page routing state is generated based on the current page level identifier and the current query field.
5. The method according to claim 1, characterized in that, The target page routing state is generated in the following way: Parse the target address parameter in the webpage navigation trigger request to obtain the target path field and the target query field; According to the preset entry path rules, the target path field is normalized to obtain the target page level identifier; The target page routing status is generated based on the target page hierarchy identifier and the target query field.
6. The method according to claim 1, characterized in that, The step of generating a navigation scene identifier based on the current page routing state and the target page routing state includes: The current page level identifier is parsed from the current page routing state, and the target page level identifier is parsed from the target page routing state; The current page level identifier and the target page level identifier are combined and identified to obtain the level combination identification result; If the hierarchical combination identification result indicates that both are entry levels, a root page update scenario identifier is generated; if it indicates that only the target page hierarchical identifier is a non-entry level, a root page to subpage scenario identifier is generated; if it indicates that both are non-entry levels, a subpage switching scenario identifier is generated; if it indicates that only the target page hierarchical identifier is an entry level, a subpage back to root page scenario identifier is generated. The generated scene identifier is used as the navigation scene identifier.
7. A webpage control device, characterized in that, include: The navigation status acquisition unit is used to respond to the webpage navigation trigger request of the embedded webpage and acquire the webpage container running identifier, the front-end route object, the current page route status, and the target page route status. The interception entry generation unit is used to generate an original navigation reference based on the front-end routing object, and generate a web-side autonomous interception entry based on the original navigation reference when the web page container running identifier matches the mini-program web page container environment. The stack control instruction generation unit is used to generate a navigation scene identifier based on the current page routing state and the target page routing state, and to generate stack control instructions according to the navigation scene identifier; The stack state update unit is used to execute the stack control instruction through the autonomous interception entry of the web page to update the browsing history stack state corresponding to the embedded web page. The control result generation unit is used to generate control result data representing the control result of the web page navigation stack based on the updated browsing history stack state and the execution feedback of the stack control instructions.
8. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, implements the webpage control method as described in any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the webpage control method as described in any one of claims 1 to 6.
10. A webpage control system, characterized in that, It includes a mini-program application and an embedded web page runtime, wherein the mini-program application is used to provide a mini-program web page container environment and load the embedded web page runtime in the mini-program web page container environment; The embedded web page runtime is used to respond to the web page navigation trigger request of the embedded web page and obtain the web page container runtime identifier, front-end routing object, current page routing status and target page routing status; The embedded web page runtime is also used to generate an original navigation reference based on the front-end routing object, and generate a web page autonomous interception entry based on the original navigation reference when the web page container runtime identifier matches the mini program web page container environment. The embedded web page runtime is also used to generate a navigation scene identifier based on the current page routing state and the target page routing state, and to generate stack control instructions according to the navigation scene identifier; The embedded web page runtime is also used to execute the stack control instruction through the autonomous interception entry of the web page, and update the browsing history stack state corresponding to the embedded web page runtime. The embedded web page runtime is also used to generate control result data representing the web page navigation stack control result based on the updated browsing history stack state and the execution feedback of the stack control instructions.