-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
discoverProxyCandidates example code does not find all candidates correctly #1468
Comments
I believe that this was deliberate at the time - we had considered a need for searching up the tree of parents and to any opener of each, but not parents of the opener. However,whats in the current implementation PR(s) does search for parents of the opener via recursion: /**
* Recursive search for all possible parent frames (windows) that we may
* target with the WCP.
* @param startWindow window object to search
* @param found window objects found so far
*/
function collectPossibleTargets(startWindow: Window, found: Window[]) {
_recursePossibleTargets(startWindow, startWindow, found);
Logger.debug(`Possible parent windows/frames found: ${found.length}`);
}
function _recursePossibleTargets(startWindow: Window, w: Window, found: Window[]) {
if (w) {
if (found.indexOf(w) == -1 && w != startWindow) {
found.push(w);
}
if (!!w.opener) {
_recursePossibleTargets(startWindow, w.opener, found);
}
if (w.parent != w) {
_recursePossibleTargets(startWindow, w.parent, found);
}
}
} which is similar to what you propose - with one key difference, it won't return the window you start with and hence won't send messages to the app window. If you see a use case for the DA to be the parent of an opening iFrame I'm happy to raise a PR to replace that function in the docs. |
We discussed this today and I think we do have a use case that requires deep window hierarchies (and would need a recursive search for parents using window.opener). We have apps that have quite complex structures with many deeply nested iframes and tabs and so on. It is very likely that some of these web pages will open a new window with |
@Roaders in anticipation I've updated the code snippet to what we've used in the implementation in PR #1466 FDC3/website/docs/api/specs/webConnectionProtocol.md Lines 150 to 180 in f2b1b1d
We hope to merge that PR before tomorrow's meeting into fdc3-for-web-impl, then fdc3-for-web-impl into main as soon as we can get reviews thereafter (fingers crossed). |
Area of Issue
Issue Description:
The sample code for discovering proxy candidates here:
https://fdc3.finos.org/docs/next/api/specs/webConnectionProtocol#12-desktop-agent-discovery
Is not complete. It does not add parents of the opener. These parent could also have openers of course. We actually need a recursive function I think. Something like:
The text was updated successfully, but these errors were encountered: