Contacting FDC3 agent from a dialog

[shipswake]

I have the case where I would like to show a popup dialog via an intent. Two issues are arising:

1. When I open the app which is in an iframe in a popup I get a permission error when trying to connect to the agent. The popup is in the same DOM as the application.

2. Where is the best place to respond to the intent to open the popup?

[kriswest]

Hi @shipswake, can we assume you are retrieving the agent using the new FDC3 2.2 getAgent function in your app, and connecting to a Desktop Agent that supports FDC3 2.2 in a web browser?

If yes, then are you able to connect to the desktop agent from the parent window that hosts the iframe? That window will normally be a 'child' of the Desktop Agent's window, having been spawned from it via window.open() or as an iframe with in it. This allows for discovery of the 'parent' desktop agent via the window.opener or window.parent reference to start Comms with the Desktop Agent. That discovery is recursive (as described at https://fdc3.finos.org/docs/api/specs/browserResidentDesktopAgents#launching-apps) meaning should also work from the further iframe you've added... Hence, try getAgent from the parent window first and if doesn't work there then your popup/iframe is not the problem.

If it does work in the parent window, your next problem maybe that the desktop agent is either not able to validate your apps identity or may be rejecting it as it didn't start it itself. If that's the case you/we may need to get into the details of the specific agent..

Where is the best place to respond to the intent to open the popup?

If the parent window is an FDC3 app, it's probably there. It will be able to add the iframe in to the DOM and load content into it, etc..

If there's any more info you can provide on the use case, it might help us navigate you to the correct solution. Also worth noting that we 've been talking at OSFF today about related topics, such as allowing for multiple Desktop agent API instances in a window (so you wouldn't need the iframe). The videos from the talks should be available soon and may answer some of your questions.

[shipswake]

All of the apps are running as localhost:

We are using the open source FDC3 web implementation 2.2 code to implement FDC3

[shipswake]

[shipswake]

I have been able to debug to the point that getAgent throws the error when the intent is raised.

[kriswest]

I believe thats intended behaviour unfortunately. FDC3 for Web Browsers was built around the idea of a Desktop Agent handling the launch of apps within its scope, either in iframes or child windows opened with window.open. The case of an app launched by another app inside its window was not considered. We are currently considering an extension of it for FDC3 2.3 that would allow an (or a component thereof) to request additional API endpoints in the same window/DOM so that parts of the application can talk to each other in the same way that separate applications can through the API.

Part of the problem with this use case (an app started in an iframe by another app) is the Desktop Agent's in ability to validate the identity of the application and its window. Where the DA has started the app, creating either the iframe or window, it has a reference to the windowProxy for it and can use that to compare to the windowProxy received via the source field of messages, which is part of validating the app and instance identity during the connection phase when a MessagePort is set up.

With the getSubAgent proposal, we're allowing either the parent app or its components to create additional API endpoints, that will be related to the parent in some way (details still to be determined). This is intended to support 'composite apps' built through module bundling and similar techniques where there are several logical apps inside a single window frame. This may work for your case as, if the iframe is from the same origin, you would be able to access its DOM and pass an API endpoint across I imagine.

In the mean time, I would suggest rethinking the approach to this dialog. For example, you could load it in the same DOM instead of an iframe. If you need to do that dynamically, you could perhaps load into an iframe and then use the adoptNode API to transfer it into your apps own DOM where it can use the parent app's API instance.

[shipswake]

Thanks for the quick and in depth response Kris