Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

Deployed adev-preview for ef02159 to: https://ng-dev-previews-fw--pr-angular-angular-66491-adev-prev-y2vol4z3.web.app

Note: As new commits are pushed to this pull request, this link is updated after the preview is rebuilt.

This doesn't fix the mentionned issue. Are you sure about the intended fix ? Did you leverage LLMs for this PR ?

My comment still stands.

Appreciate the review let me explain what Im trying to do and how I want it to work.. The issue is caused by the replaceState call that runs unconditionally during NavigationStart. It takes away the #:~:text= fragment before the browser finishes its native text hover highlighting work.. This change will not change how navigation works. It just stops replaceState from running when there is a text fragment, which lets the browser do the highlight to link work as it should.

I agree it doesn t fix every possible navigation problem, but it does fix the problem I wrote about the most: the highlight appears for a sec then goes away when Angular finishes navigation and the fragment gets removed from the URL.. As for LLMs I did not directly use any generated code to create this change. I based it on debugging the navigation flow manually and watching what happens to the fragment relative to NavigationStart. If there s a better way to do this, like saving off replaceState until later in the navigation process, I m happy to change the code.

Ok I see.
This still isn't the right fix as you can observe with this link:

https://ng-dev-previews-fw--pr-angular-angular-66491-adev-prev-y2vol4z3.web.app/guide/components#using-components:~:text=By%20default%2C%20Angular%20components%20are%20standalone

As you will see there is another replaceState responsible for the path change. I haven't looked more deeply on the why this happens.

Maybe @atscott can shed some light here.

Yea this change seems to miss that the function returns early at the top of view transitions aren’t defined, as would’ve the case in SSR

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}