fix(docs-infra): preserve text fragment highlights during initial navigation#67216
Closed
yogeshwaran-c wants to merge 1 commit intoangular:mainfrom
Closed
fix(docs-infra): preserve text fragment highlights during initial navigation#67216yogeshwaran-c wants to merge 1 commit intoangular:mainfrom
yogeshwaran-c wants to merge 1 commit intoangular:mainfrom
Conversation
…igation Chrome and other browsers clear text fragment highlights (#:~:text=...) whenever history.pushState or history.replaceState is called. During Angular's initial navigation, the router calls replaceState to update the history state with a navigationId, which strips the highlight and breaks the browser's native "Copy link to highlight" feature. This adds a new environment initializer that temporarily suppresses pushState/replaceState calls during the initial navigation when text fragment support is detected via document.fragmentDirective. The original methods are restored after the first navigation completes. Fixes angular#65119
Member
|
This just doesn't works. |
yogeshwaran-c
added a commit
to yogeshwaran-c/angular
that referenced
this pull request
Feb 24, 2026
…igation Chromium-based browsers clear text fragment highlights whenever history.pushState or history.replaceState is called. During the initial navigation, Angular's Router and the navigation adapter both call replaceState, which strips the text highlight and removes the :~:text= fragment from the URL. The previous approach (PR angular#67216) suppressed replaceState/pushState entirely via a separate environment initializer, but this conflicted with the navigation adapter which also calls replaceState during NavigationStart. The adapter's replaceState call triggers a Navigation API intercept for browser loading indicators. This fix resolves the conflict by: 1. Checking whether the current URL contains a text fragment directive (:~:) instead of checking the fragmentDirective browser feature 2. Registering the suppression initializer BEFORE the navigation adapter, so replaceState/pushState are already no-ops when the adapter fires on NavigationStart 3. Restoring the originals after the first navigation completes The navigation adapter's replaceState call being suppressed during the initial navigation is acceptable because the browser already shows a loading indicator for the initial page load. Fixes angular#65119
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What kind of change does this PR introduce?
Bug fix
What is the current behavior?
When using the browser's "Copy link to highlight" feature on the Angular documentation site (angular.dev), the text highlight briefly appears but then disappears as the page finishes loading. The
#:~:text=...fragment is also removed from the URL.This happens because Chrome and other browsers clear text fragment highlights whenever
history.pushStateorhistory.replaceStateis called. During Angular's initial client-side navigation (after SSR hydration), the router callsreplaceStateto update the history state with anavigationId, which strips the highlight.Closes #65119
What is the new behavior?
Text fragment highlights are preserved when navigating to an angular.dev URL that contains a
#:~:text=...fragment. The browser's native "Copy link to highlight" feature works as expected.This is achieved by adding a new environment initializer (
preserveTextFragmentHighlight) that:document.fragmentDirectivehistory.pushState/history.replaceStatecalls during the initial navigationNavigationEnd,NavigationCancel, orNavigationErrorThe suppression only affects the very first navigation (the initial page load) and only activates in browsers that support text fragment directives. Subsequent navigations work normally.
Additional context
history.replaceStatecall, but was correctly rejected by the reviewer becausewindowis already injected via theWINDOWtoken and the guards did not address the root cause.pushState/replaceStatestrips text fragment highlights per the Text Fragments spec, including the router's own state management call.https://angular.dev/guide/signals#:~:text=signal%20is%20a-,wrapper,-around%20a%20value- the highlight appears briefly then vanishes.