angular: routerLink directive does not respect `event.preventDefault()` to prevent navigation

I’m submitting a…


[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

Attempting to prevent navigation for an anchor with a routerLink by calling event.preventDefault() on the click event has no effect.

Expected behavior

When event.preventDefault() is called on the click event, navigation should be prevented.

Minimal reproduction of the problem with instructions

Link to Repro

Clicking on “catalog” still navigates to the catalog view, event though the <a> tag contains (click)="$event.preventDefault()

What is the motivation / use case for changing the behavior?

Environment

Angular version: 5.2.0

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 41
  • Comments: 32 (12 by maintainers)

Commits related to this issue

Most upvoted comments

i updated from 5.0.2 to 5.3.2 and now its working: (click)="partcipate();$event.preventDefault();$event.stopPropagation()"

We have a need to allow an HTML page to open a routerLink in a new tab via right-click context menu. However, when user clicks in a normal case we have a component click event that builds an object and passes it up a couple parent levels to open in a side-panel. I am trying to intercept the default behavior of the routerLink using preventDefault() in an ‘anchor-tag-directive’ we rolled but am not having success. Currently the link still opens in the current page, the default behavior for the routerLink tag.

I hope this helps explain why one might want to have a preventDefault() for a routerLink on a clickable element.

I’ve just had some success with a similar issue: having an array of nav links in an ngFor, some required [routerLink], while others required (click) - my issue was that all links relied on [routerLink] for [routerLinkActive], so I had to stop routerLink, without touching it’s value.

<a [routerLink]="item.link" routerLinkActive="isActive"> <span (click)="item.click ? item.click($event) : void> </a>

with:

click: ($event) => { $event.stopPropagation(); // Only seems to $event.preventDefault(); // work with both // Custom onClick logic } As the span is inside, you can be sure the cancelling of the event happens before it bubbles up to [routerLink], while routerLinkActive will still apply.

Any update on this issue? I just ran into it and google let me here.

Regardless of the outcome of the debate over whether routerLink should respect defaultPrevented, it’s clear there is a need for the ability to disable the routerLink navigation. This would be addressed in #35393/#31154. If/when that PR is merged, maybe this issue can be closed as well.

@hansih91 Angular 5.3.2 ?? RLY ? 🤔

I have read the thread. The real problem is that RouterLink click listener does not care about the event and its defaultPrevented value. An issue with order can REALLY EASILY be overcome by wrapping text into span inside the routerLink element and preventing default on click handler inside that span. Real links respect preventDefault and routerLink should too. How you prevent default is another story.

As discussed in https://github.com/angular/angular/issues/21457#issuecomment-361758239 and other places, preventDefault will not be respected. This issue is mainly kept open for discoverability as there are others that also track the need for disabling links.
I was looking these for v12 but as you can probably tell from the release notes, there was a lot of other stuff going on. The components TL and I will be meeting soon and will come up with an answer that considers accessibility as well.

@digeomel Well I think you have to do 2 seperate Ng If Conditions because its not possible to do it with one directive, like you described… or change framework because Angular is not that well maintained anymore (was it ever? IMHO)

@atscott the related PR is closed due to inactivity and I just ran into the same issue. Any suggestions?