When creating an element with a target set to _blank
to open in a new tab is ignored. When clicking on the link, it opens the page in the current window.
<a href="https://..." target="_blank">Link</a>
Hi Elio, can you provide slightly more information on where this was done. Was this a page or a custom web part or something else? Classic / modern etc? Currently that looks like a browser issue but assuming that there's something else behind, which simply was not shared. Thx.
Sure @VesaJuvonen, my links are created in a web part as follows:
<a href="https://tenant.sharepoint.com/sites/sitename/SitePages/Test-page-1.aspx" target="_blank">Test page 1</a>
<a href="https://tenant.sharepoint.com/sites/sitename/SitePages/Test-page-2.aspx" target="_blank">Test page 2</a>
If the web part renders and I click on the link, it does not open the page in a new tab, instead, it will open it in the current one. Here is an example of what I see:
In the above GIF you can see that target="_blank" is configured on the link, and when I click on it it opens the second page in the same window. Here is another example where I use a dialog which shows it even better:
You see that the page gets loaded in the background, but the dialog stays in the front.
This only occurs on hosts equal to the tenant. If you put www.foo.org it opens in a new window. Seems it's the modern smart loading hooking into links with the same tenant.
I'm also running into this issue. If I have two sites that are both children to the same hub site, the target
property on the anchor tag is ignored when I click on it to navigate from one to another. However, if I'm navigating to another site that is unrelated, it respects the target
property.
@VesaJuvonen
It seems to be an issue directly related with SharePoint because it's not only happening with SPFX web parts but also with native web parts such as the "Quick Links" one.
You can also reproduce this behavior by editing directly the DOM of a SharePoint page in your browser and adding a link (e.g. on a SharePoint Online modern page https://XXX.sharepoint.com/sites/XXX/SitePages/page.aspx add a link to another page : <a href="https://XXX.sharepoint.com/sites/XXX/SitePages/page2.aspx" target="_blank">test</a>
) and if you follow it, it will open the new page in the same tab.
I'm experiencing the same issue. Adding a anchor tag to a custom web part with target="_blank" seems to always open on the same tab when pointing to an internal url.
See
https://julieturner.net/2018/08/spfx-anchor-tags-hitting-the-target/ for a
solution.
-mikael
fre. 2. nov. 2018 kl. 19:07 skrev Joel Rodrigues notifications@github.com:
I'm experiencing the same issue. Adding a anchor tag to a custom web part
with target="_blank" seems to always open on the same tab when pointing to
an internal url.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/SharePoint/sp-dev-docs/issues/1582#issuecomment-435442371,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADHoPgrXoTS1H2tNrX2ntgJO0-gvxLXks5urInegaJpZM4TFPKJ
.
Thanks for that, I had forgotten about this blog post :)
Haven't tried it, but the first workaround seems to increase the page load, which is not an option for me as this is going into the home page of the main site collection where all users will go. There is also the possibility of having multiple anchor elements, so not sure if loading time would increase exponentially?
Would be good to know if there are any plans for changing this behaviour in the future.
We use the workaround and you only need it on target=_blank, so no impact on load times.
I mean when navigating to the target page. But feels like you are not experiencing any slowdown, so may give it a try. Thanks a lot for that Mikael
When opening a new page in a tab it will load all elements always - no smart loading in a new tab. You can only smartload in the existing tab.
You can just add the following attribute to the anchor tag: data-interception='off'
This is ignore the smart loading done by modern SharePoint.
This is the same way the text webpart works with anchor tags:
@VesaJuvonen @estruyf maybe we can close this as "by design" as adding the data-interception
attribute is the way to solve this one?
Thanks for the workaround/fix all!
We just implemented this for one of our clients.
@VesaJuvonen Can we rely on the data-interception fix?
Kind regards
Any updates on this? Still hesitant to add data-interception
unless it's been officially documented at this point.
Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues
Most helpful comment
See
https://julieturner.net/2018/08/spfx-anchor-tags-hitting-the-target/ for a
solution.
-mikael
fre. 2. nov. 2018 kl. 19:07 skrev Joel Rodrigues notifications@github.com: