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
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
- fix(router): null/undefined routerLink should disable navigation The current behavior of `routerLink` for `null` and `undefined` inputs is treat the input the same as `[]`. This creates several unres... — committed to atscott/angular by atscott 3 years ago
- fix(router): null/undefined routerLink should disable navigation The current behavior of `routerLink` for `null` and `undefined` inputs is treat the input the same as `[]`. This creates several unres... — committed to atscott/angular by atscott 3 years ago
- fix(router): null/undefined routerLink should disable navigation The current behavior of `routerLink` for `null` and `undefined` inputs is treat the input the same as `[]`. This creates several unres... — committed to atscott/angular by atscott 3 years ago
- fix(router): null/undefined routerLink should disable navigation The current behavior of `routerLink` for `null` and `undefined` inputs is treat the input the same as `[]`. This creates several unres... — committed to atscott/angular by atscott 3 years ago
- fix(router): null/undefined routerLink should disable navigation The current behavior of `routerLink` for `null` and `undefined` inputs is treat the input the same as `[]`. This creates several unres... — committed to atscott/angular by atscott 3 years ago
- fix(router): null/undefined routerLink should disable navigation The current behavior of `routerLink` for `null` and `undefined` inputs is treat the input the same as `[]`. This creates several unres... — committed to atscott/angular by atscott 3 years ago
- fix(router): null/undefined routerLink should disable navigation The current behavior of `routerLink` for `null` and `undefined` inputs is to treat the input the same as `[]`. This creates several un... — committed to atscott/angular by atscott 3 years ago
- fix(router): null/undefined routerLink should disable navigation The current behavior of `routerLink` for `null` and `undefined` inputs is to treat the input the same as `[]`. This creates several un... — committed to atscott/angular by atscott 3 years ago
- fix(router): null/undefined routerLink should disable navigation (#43087) The current behavior of `routerLink` for `null` and `undefined` inputs is to treat the input the same as `[]`. This creates s... — committed to TeriGlover/angular by atscott 3 years ago
- fix(router): null/undefined routerLink should disable navigation (#43087) The current behavior of `routerLink` for `null` and `undefined` inputs is to treat the input the same as `[]`. This creates s... — committed to TeriGlover/angular by atscott 3 years ago
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 respectdefaultPrevented
, it’s clear there is a need for the ability to disable therouterLink
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 intospan
inside the routerLink element and preventing default on click handler inside thatspan
. 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?