I have a web application that relies heavily on the host page (static - never changes) talking to a popup window. The popup window pages change as the user navigates around the website.
The host page is IE and has an embedded ActiveX. The ActiveX fires events and the host page reacts to these events. In turn, the host page makes changes to the popup page via the reference to that page created by window.open in the host page.
Users navigate around the website in the popup window. The popup pages are rendered in IE (some have other embedded ActiveX) with the exception of a single page which is rendered in GCF.
The problem is that the communications between the host and the popup are broken due to the way that GCF is implemented.
Is there a way to set up a communications path between the windows that's reliable and the same for both the IE pages and the GCF page that are in the popup?
I have looked at the method of having the GCF ActiveX in the host page and opening the popup page but that seems to render the popup in GCF despite the tag "<meta http-equiv="X-UA-Compatible" content="chrome=1">" NOT being included; the popup IS, however, wrapped in an IE window. This does not seem to be a satisfactory solution.
I have looked at rendering the whole site in GCF but I have too many ActiveX pages and I cannot load them in the GCF page. I do need to wrap the site in IE since it's a standalone application on a single computer. This is required in order to open the pages in kiosk mode (full screen with no menus).
If anyone understands the above scenario and can offer some advice or assistance then it would be greatly appreciated.
It would appear that the only real way that this may be achieved is via cookies in some way. I am assuming that there's no technical way to achieve a solution otherwise "window.opener" would be available to the popup.
The situation you describe -- the opener sending events to the opened
window -- will indeed be broken by GCF being triggered in the opened window
if the parent isn't a GCF-rendered document.
I think your suggestion below to poll on cookies isn't terrible, and I'm
sorry it's necessary. It doesn't strike me that the normal bag of
window.open()-based tricks will work here to create a channel between the
windows. Nor, I'm afraid, will postMessage as the window with the GCF
document won't be the thing you have a handle to from the parent document.
One possible solution might be to not use the header/meta for this single
document and, instead, host a GCF ActiveX control (iframe-style) full-page
in the popped-up window. That would allow you to keep the scripting
connection between parent/child and still use postMessage/onmessage to
communicate with the contents of the GCF document.
Sounds like a possibility. Will investigate. I am currently working on a means of passing messages with cookies and, once that's working fully, I'll move onto your idea. No harm in getting both working then making a choice as to which suits best.
On Wednesday, 18 July 2012 19:16:31 UTC+1, Alex Russell wrote:
> Hi Donald,
> Sorry for the slow response. Vacation, etc.
> The situation you describe -- the opener sending events to the opened > window -- will indeed be broken by GCF being triggered in the opened window > if the parent isn't a GCF-rendered document.
> I think your suggestion below to poll on cookies isn't terrible, and I'm > sorry it's necessary. It doesn't strike me that the normal bag of > window.open()-based tricks will work here to create a channel between the > windows. Nor, I'm afraid, will postMessage as the window with the GCF > document won't be the thing you have a handle to from the parent document.
> One possible solution might be to not use the header/meta for this single > document and, instead, host a GCF ActiveX control (iframe-style) full-page > in the popped-up window. That would allow you to keep the scripting > connection between parent/child and still use postMessage/onmessage to > communicate with the contents of the GCF document.
> On Wednesday, 18 July 2012 19:16:31 UTC+1, Alex Russell wrote:
>> Hi Donald,
>> Sorry for the slow response. Vacation, etc.
>> The situation you describe -- the opener sending events to the opened
>> window -- will indeed be broken by GCF being triggered in the opened window
>> if the parent isn't a GCF-rendered document.
>> I think your suggestion below to poll on cookies isn't terrible, and I'm
>> sorry it's necessary. It doesn't strike me that the normal bag of
>> window.open()-based tricks will work here to create a channel between the
>> windows. Nor, I'm afraid, will postMessage as the window with the GCF
>> document won't be the thing you have a handle to from the parent document.
>> One possible solution might be to not use the header/meta for this single
>> document and, instead, host a GCF ActiveX control (iframe-style) full-page
>> in the popped-up window. That would allow you to keep the scripting
>> connection between parent/child and still use postMessage/onmessage to
>> communicate with the contents of the GCF document.
> To post to this group, send email to google-chrome-frame@googlegroups.com.
> To unsubscribe from this group, send email to
> google-chrome-frame+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-chrome-frame?hl=en.
So while I'm continuing to try to understand what's going on with the
test page you're seeing, the CFInstance wrapper script I wrote *does*
seem to be working for these cases:
>> On Wednesday, 18 July 2012 19:16:31 UTC+1, Alex Russell wrote:
>>> Hi Donald,
>>> Sorry for the slow response. Vacation, etc.
>>> The situation you describe -- the opener sending events to the opened
>>> window -- will indeed be broken by GCF being triggered in the opened window
>>> if the parent isn't a GCF-rendered document.
>>> I think your suggestion below to poll on cookies isn't terrible, and I'm
>>> sorry it's necessary. It doesn't strike me that the normal bag of
>>> window.open()-based tricks will work here to create a channel between the
>>> windows. Nor, I'm afraid, will postMessage as the window with the GCF
>>> document won't be the thing you have a handle to from the parent document.
>>> One possible solution might be to not use the header/meta for this single
>>> document and, instead, host a GCF ActiveX control (iframe-style) full-page
>>> in the popped-up window. That would allow you to keep the scripting
>>> connection between parent/child and still use postMessage/onmessage to
>>> communicate with the contents of the GCF document.
>> To post to this group, send email to google-chrome-frame@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-chrome-frame+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-chrome-frame?hl=en.
