Hi, i think it's intended and was never a requirement. Feel free anaylze it more and work on a PR. The JS itself is quite good documented + contains many logging + the mechanism itself is quite good documented in the DS docu.
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virenfrei. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> Am Mi., 9. Okt. 2019 um 20:49 Uhr schrieb Christian Beikov < [email protected]>: > Hey, > > I'm currently having trouble with the CLIENTWINDOW strategy when using > frames. In my current case the problem is due to the usage of the > Primefaces Dialog-Framework which makes use of iframes for the dialogs. > The frame has a special contentWindow which is inspected by the DS code > for a window id but it can't find it, because it's on the parent window. > > Using window scoped beans is impossible in the iframe as it gets a new > window id which makes previous state inaccessible. > > Would you consider this a bug or is this intended? Can I somehow append > a dsrid or dswid to the URL to get the same window id in the iframe? > Using the top window for the window id storage by default would make it > impossible to change that aspect selectively and requires changes in the > JS file which will probably take some time to bake, so I would prefer > the append approach if possible. I can't think of a case where one would > want to treat an iframe like a different window but to stay flexible I > understand if you want to stick to the current logic, still, do you have > a use case like that? > > Regards, > > Christian > >
