Ponyfilling window.open

[compulim]

Fix #368.

Background

To support Bot Framework Emulator and other hosting scenarios, all open URL actions should be customizable in JavaScript to allow different handling options.

Design decisions

Some design decisions have been made while preparing this work.

Function signature

window.open has a signature of (url: string, windowName: string, windowFeatures: string) => void.

Instead of adopting a similar signature of (url: string) => void, we prefer ({ cardAction: any }) => (url: string) => void.

This allow us to send in cardAction and additional data, and not messing up with current signature of window.open.

Intercepting <a>

Currently, we do not intercept <a> because it should be up to the hosting app on how to intercept them. And we believe the host should have ability to intercept them.

Intercepting <a> is a challenge because interception might break middle-click on them (normally it should open the link in a new window.)

OAuth support

Today, OAuth flow do the following:

• Call window.open() with nothing, remember the result as popup variable
• Call ABS getSessionId() for code_challenge
• Update popup.location.href with a URL with code_challenge embedded in

The 1st and 3rd point is required to be separated to overcome popup blocker restrictions. We are advised not to pre-fetch code_challenge until the user click on it.

The function signature design allows us to do the job as of today, without intervention from popup blocker.

Changelog

Added

• component: Allow ponyfilling window.open, by @compulim, in PR #1704

Samples

• component: Customizing open URL behavior, in PR #1704

[coveralls]

Coverage increased (+2.5%) to 56.654% when pulling 0b946bd on compulim:feat-window-open-ponyfill into 28b4e4d on Microsoft:master.

[a-b-r-o-w-n]

This doesn't really feel like a ponyfill, its more of a custom url click handler

[a-b-r-o-w-n]

I'm not convinced this should be about "ponyfilling" window.open. It looks to be more of allowing users to customize how to handle card clicks. For example, what if don't even want to open the link but instead do something else?

Given that, I think we should re-think the name.

[compulim]

If we name it "urlHandler" or similar, the user will have an impression that it could handle all <a>, which we don't. And in some cases, we can't control <a> too. Naming it "urlHandler" would give them a false impression that we will handle all URL in Web Chat, in fact, we don't and we can't.

But if we name it as window.open ponyfill, they know this is only for changing the behavior of programmatic access to a new window (a.k.a. popup). Not <a>. I want to be clear on this point.

Web Chat only use the first argument of window.open. And we don't use windowName and windowFeatures (2nd and 3rd argument). The user pass in the ponyfill, we only use certain features of the ponyfill, and we are using the ponyfill without changing its shape/signature. I think it didn't conflict with the idea of ponyfill.

[compulim]

We can name it "cardActionOpenUrlHandler". Or we make the whole onCardAction replaceable using middleware pattern.

cardActionOpenUrlHandler seems too narrow on its usage I don't prefer it.

If we are working on cardActionMiddleware, the dev will need to understand signin card action and how to construct the URL, and open in their own style of popups. Currently there is some limitations over signin card action, we cannot construct the URL before the user click on the "Sign in" button. I talked to people behind it yesterday and confirmed about the limitation.

[cwhitten]

I agree that the way this is written, full control is yielded to the caller and we would be presumptive that their implementation would always fall back to a closure that invokes window.open. we should give it a name that better describes that. how about scopeCardActionHandler?

[compulim]

@cwhitten If this is named scopeCardActionHandler, it will need to understand how "signin" card action lead to a popup. I.e. it must construct a URL by calling Direct Line service (DLJS.getSessionId), get back the result, and construct a URL, then open it. I think the implementer shouldn't need to know about these mechanics.

Changed from window.open ponyfill into a full-fledged onCardAction middleware

[cwhitten]

@compulim nice work! let's rebase this and get it merged.

[tonyanziano]

Looks good to me.