fix(docs-infra): preserve text fragment highlights during initial navigation#67235
Closed
yogeshwaran-c wants to merge 1 commit intoangular:mainfrom
Closed
fix(docs-infra): preserve text fragment highlights during initial navigation#67235yogeshwaran-c wants to merge 1 commit intoangular:mainfrom
yogeshwaran-c wants to merge 1 commit intoangular:mainfrom
Conversation
…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
Member
|
This obviously has not been tested in the adev app because it still doesn't work. Please continue if you'd like to get banned. |
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 (reworked from closed PR #67216)
What is the current behavior?
When using the browser's "Copy link to highlight" feature on angular.dev, the text highlight briefly appears but disappears as the page finishes loading. The
:~:text=...fragment is also removed from the URL. This happens because Angular's Router and the navigation adapter both callhistory.replaceStateduring the initial navigation, which causes Chromium to clear text fragment highlights.Closes #65119
What is the new behavior?
Text fragment highlights are preserved after the initial page load. The
:~:text=...fragment remains in the URL and the browser's text highlighting feature works correctly on angular.dev.How this differs from the previous approach (PR #67216)
The previous PR added a
preserveTextFragmentHighlightinitializer that suppressedhistory.replaceState/pushStatewith no-ops, but it was registered AFTERinitializeNavigationAdapter. This caused a conflict because the navigation adapter callsreplaceStateduringNavigationStartto trigger a Navigation API intercept (for browser loading indicators), and the suppression broke this adapter entirely.This reworked fix resolves the conflict by:
URL-based detection instead of feature detection: Checks
window.location.href.includes(':~:')to detect an active text fragment, rather than checkingfragmentDirective in document. This is more precise -- it only activates when there is actually a text fragment in the current URL.Correct initialization order: The
preserveTextFragmentHighlightinitializer is registered BEFOREinitializeNavigationAdapter, soreplaceState/pushStateare already suppressed when the adapter subscribes to router events and tries to callreplaceStateonNavigationStart.Acceptable trade-off: The navigation adapter's
replaceStatecall being suppressed during the initial navigation means the Navigation API intercept won't trigger for the first navigation. This is acceptable because the browser already shows a loading indicator during the initial page load.Additional context
The fix includes unit tests that verify: