Open scch1002 opened 4 years ago
We added this feature in our custom version of WebChat V3 and very much support this feature request. Please also think about the OpenUrlAction in adaptivecards and herocards.. and consider allowing target="_parent"
for those who run WebChat in an iframe 🤫
I'm not sure if this is already possible using cardActionMiddleware in V4 though.
@tdurnford Can you please take a look at this?
@EdwinOtten that would work for the action buttons on cards but not embedded links.
@EdwinOtten that would work for the action buttons on cards but not embedded links.
Would it be possible to have some kind of markdownMiddleware that allows to customize how embedded links are rendered?
@scch1002 I think the Web Chat team would be open to adding an openInExistingWindow
style option; however, we'd need to investigate if a style option is capable of covering all of the possible cases such as markdown, Adaptive Cards buttons and tap actions, and file download links.
In terms of markdown links, Web Chat implements a custom markdown renderer that sets the target to _blank
. Developers can currently pass their own markdown renderer to Web Chat that does not set the target. Take a look at the code snippet and screen capture below for more details.
<script src="https://cdnjs.cloudflare.com/ajax/libs/markdown-it/10.0.0/markdown-it.js"></script>
<script>
(async function() {
const res = await fetch('https://webchat-mockbot.azurewebsites.net/directline/token', { method: 'POST' });
const { token } = await res.json();
const markdownIt = window.markdownit();
window.WebChat.renderWebChat(
{
directLine: window.WebChat.createDirectLine({ token }),
renderMarkdown: text => markdownIt.render(text)
},
document.getElementById('webchat')
);
document.querySelector('#webchat > *').focus();
})().catch(err => console.error(err));
</script>
Ok, I will take a look at creating a custom markdown renderer.
I am also interested in the openInExistingWindow style option. :)
Hi @scch1002. openInExistingWindow
style option seems totally reasonable. I'll work with the team to formalize this API. Realistically we'd be looking at a May '20 or August '20 release that introduces this behavior.
This is targeted to land in an upcoming release.
openUrl
card action<a>
) and card actions (Adaptive Cards, hero card, suggested actions, etc){ rel: 'noopener noreferrer', target: '_blank' }
window.open
for card actions<span>
instead of <a>
) or disabled button, depends on its appearancewindow.open
<a>
generated by Markdown, because <a>
is not 100% replaceable by window.open
(middle-click is not emulat-able)We are using the following HTML markup tag in an answer with and without follow-up adaptive cards:
When used without a follow-up adaptative card the page in being rendered exactly as we coded it. That is the html element is rendered as BEFORE A HEARING.
However, if there are follow-up adaptive cards this html element gets altered to: BEFORE A HEARING
As you can see that the class ="ac-anchor" target="_blank" attributes have been added by the botframework .
We are requesting that whatever we enter in QnAMaker not be altered in any way and should be kept in tack as is. This is causing issues with our application as we are not able to utilized the function: onClick: navigateToPage to navigate to the utilizing the following WebChat function as it is be pre-empted from reaching this code:
window.WebChat.renderWebChat({
directLine: window.WebChat.createDirectLine({ token }), store, styleOptions, renderMarkdown: markdownIt.render.bind(markdownIt)
}, wc);
Related to #3087
@scch1002 I think the Web Chat team would be open to adding an
openInExistingWindow
style option; however, we'd need to investigate if a style option is capable of covering all of the possible cases such as markdown, Adaptive Cards buttons and tap actions, and file download links.In terms of markdown links, Web Chat implements a custom markdown renderer that sets the target to
_blank
. Developers can currently pass their own markdown renderer to Web Chat that does not set the target. Take a look at the code snippet and screen capture below for more details.Web Chat v4
<script src="https://cdnjs.cloudflare.com/ajax/libs/markdown-it/10.0.0/markdown-it.js"></script> <script> (async function() { const res = await fetch('https://webchat-mockbot.azurewebsites.net/directline/token', { method: 'POST' }); const { token } = await res.json(); const markdownIt = window.markdownit(); window.WebChat.renderWebChat( { directLine: window.WebChat.createDirectLine({ token }), renderMarkdown: text => markdownIt.render(text) }, document.getElementById('webchat') ); document.querySelector('#webchat > *').focus(); })().catch(err => console.error(err)); </script>
Screen capture
Relevant Code
>Developers can currently pass their own markdown renderer to Web Chat"
I'm about to try and work around issues with a QnA bot running in Web Chat, and I'm wondering whether this is still the preferred method ? (Custom Renderer). Also - are there any plans to change this ability ? I see the word "currently" , and dont want to back myself into a corner
Feature Request
Is your feature request related to a problem? Please describe. Embedded web links in messages that are for the same domain open in new tabs. It would be nice to be able to control whether an embedded link in the same domain opens in a new tab or in the same tab.
For example,
If the webchat is active in the web domain of 'test' and an embedded link is for a domain 'test1' then the link will be.
<a href='https://test1/...' target='_blank' />
else if the domain of the embedded link is for the same domain as the webchat then the link will be
<a href='https://test/...' target='_self' />
Describe the suggestion or request in detail It would be nice to have a webchat style option to control whether a link within the same domain as the webchat opens in a new tab or the same tab.
https://github.com/Microsoft/BotFramework-WebChat/blob/master/packages/component/src/Styles/defaultStyleOptions.js
Describe alternatives you have considered The only other solutions to solve this problem is to implement a work around using DOM manipulation or to implement a custom webchat client from scratch.
Additional context
This is an issue with embedded links in messages not action buttons that appear on the bottom of cards. Though it would make sense that this feature would also affect the behavior of action buttons as well.