-----Original Message----- From: Vojtech Szocs [mailto:vszocs@redhat.com] Sent: Wednesday, January 09, 2013 7:11 PM To: Morrissey, Christopher Cc: Itamar Heim; Costea, George; engine-devel(a)ovirt.org Subject: Re: Question about closing UI plugin dialog Hi Chris, current showDialog() implementation uses native browser popup window via window.open() function. UI rendered within such popup window can close the window by itself simply via window.close() function [1].

However, as we're planning to move away from using native browser popup windows and making showDialog() implementation integrate with Web Admin dialog UI infrastructure, there are two possible ways to go: a) OK/Cancel buttons rendered as part of custom dialog content (as described by Chris) - buttons are contained within the iframe content HTML - Web Admin will transmit custom dialog ID to iframe, e.g. iframeWindow.postMessage('customDialog123', iframeWindowDomain) - within the iframe window, clicking a button would invoke parentWindow.postMessage('close-customDialog123', parentWindowDomain) - Web Admin will receive 'close-customDialog123' message and will close the custom dialog Pros: buttons and content in the same window context Cons: cross-window communication overhead that relies on window.postMessage() b) OK/Cancel buttons rendered as part of Web Admin dialog UI (NOT part of custom dialog content) - this was my initial idea of implementing custom dialog buttons - buttons will be defined via separate argument to showDialog() function, e.g. showDialog(title, contentUrl, width, height, buttons) where 'buttons' follow similar concept as 'actionButtonInterface' in addMainTabActionButton() API, e.g. { onClick: function() {...} } - closing custom dialog can be done right within the onClick handler function Pros: no need for window.postMessage() stuff, button definitions are part of UI plugin (JavaScript) code Cons: buttons and content in different window contexts

Chris, let me know what you think. Note: window.postMessage() should work in IE8 and above, I've tested [2] in IE8/WinXP/SP3 without any problems. However, [3] mentions that "In IE8, it is possible to use win.postMessage for iframes only", I assume this is what you meant by saying that "it doesn't work across windows in IE"? Not sure if this is still an issue for us when using iframe instead of native browser popup window, but we'll have to investigate..

Regards, Vojtech [1] http://stackoverflow.com/a/2076307 [2] http://stevesouders.com/misc/test-postmessage.php [3] http://javascript.info/tutorial/cross-window-messaging-with- postmessage ----- Original Message ----- From: "Christopher Morrissey" <Christopher.Morrissey(a)netapp.com&gt; To: "Vojtech Szocs" <vszocs(a)redhat.com&gt;, engine-devel(a)ovirt.org Cc: "Itamar Heim" <iheim(a)redhat.com&gt;, "George Costea" <George.Costea(a)netapp.com&gt; Sent: Tuesday, January 8, 2013 3:13:44 PM Subject: Question about closing UI plugin dialog Hi All, I've been working on a plugin for the UI that launches a dialog using the showDialog() API. Our UI is actually contained in a frame inside the dialog and is loaded from a separate server. The only information needed for our UI comes in either through the URL as parameters or from the oVirt REST API. The issue is that once the clicks the OK or Cancel buttons in our UI we need to message to the oVirt UI to close the dialog. It looks like using the window.postMessage() API would be great for this, but it doesn't work across windows in IE. Would it be possible to change the code that launches the window to open a window that contains a bit of javascript that sets up a listener for closing the dialog and then launches the URL in an iFrame in the window? Of course, if it were in a native GWT dialog this wouldn't be a problem. ;) -Chris Chris Morrissey Software Engineer NetApp Inc. 919.476.4428

-----Original Message----- From: Vojtech Szocs [mailto:vszocs@redhat.com] Sent: Thursday, January 10, 2013 12:30 PM To: Morrissey, Christopher Cc: Itamar Heim; Costea, George; engine-devel(a)ovirt.org Subject: Re: Question about closing UI plugin dialog Hi Chris, I agree with your point, having OK/Cancel buttons controlled by the content within the same (iframe) window context sounds reasonable. On the other hand, we shouldn't restrict showDialog() API in a way that iframe window *must* provide means (buttons) of closing the dialog, as other UI plugins might just want to add Close button via showDialog() API. So I think a combination of both options (a+b) can be implemented. If your plugin doesn't want to add Close button via showDialog() API, that's OK, you can have OK/Cancel buttons provided by the iframe window.

> This will not be a problem when we're in an iframe. In fact, that is the only place it will work in IE 8 and 9. :) besides postMessage(), we can also use a trick with iframe updating its URL hash fragment, and Web Admin monitoring iframe URL hash fragment value. But I'd like to try using postMessage() first.

Regards, Vojtech ----- Original Message ----- From: "Christopher Morrissey" <Christopher.Morrissey(a)netapp.com&gt; To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; Cc: "Itamar Heim" <iheim(a)redhat.com&gt;, "George Costea" <George.Costea(a)netapp.com&gt;, engine-devel(a)ovirt.org Sent: Thursday, January 10, 2013 3:37:04 AM Subject: RE: Question about closing UI plugin dialog -Chris > -----Original Message----- > From: Vojtech Szocs [mailto:vszocs@redhat.com] > Sent: Wednesday, January 09, 2013 7:11 PM > To: Morrissey, Christopher > Cc: Itamar Heim; Costea, George; engine-devel(a)ovirt.org > Subject: Re: Question about closing UI plugin dialog > > Hi Chris, > > current showDialog() implementation uses native browser popup window > via > window.open() function. UI rendered within such popup window can close > the window by itself simply via window.close() function [1]. Ha, of course window.close() will work! Not sure what I was thinking. > > However, as we're planning to move away from using native browser > popup windows and making showDialog() implementation integrate with > Web Admin dialog UI infrastructure, there are two possible ways to go: > > a) OK/Cancel buttons rendered as part of custom dialog content (as > described by Chris) > - buttons are contained within the iframe content HTML > - Web Admin will transmit custom dialog ID to iframe, e.g. > iframeWindow.postMessage('customDialog123', iframeWindowDomain) > - within the iframe window, clicking a button would invoke > parentWindow.postMessage('close-customDialog123', > parentWindowDomain) > - Web Admin will receive 'close-customDialog123' message and will > close the custom dialog > > Pros: buttons and content in the same window context > Cons: cross-window communication overhead that relies on > window.postMessage() > > b) OK/Cancel buttons rendered as part of Web Admin dialog UI (NOT part > of custom dialog content) > - this was my initial idea of implementing custom dialog buttons > - buttons will be defined via separate argument to showDialog() > function, e.g. showDialog(title, contentUrl, width, height, buttons) > where 'buttons' follow similar concept as 'actionButtonInterface' > in > addMainTabActionButton() API, e.g. { onClick: function() {...} } > - closing custom dialog can be done right within the onClick > handler function > > Pros: no need for window.postMessage() stuff, button definitions are > part of UI plugin (JavaScript) code > Cons: buttons and content in different window contexts > This has a big drawback in that the content often needs to perform actions when the OK button is pressed. This design makes it very difficult and will at least need to use the Window.postMessage() to signal to the content that the dialog is closing. What's worse is that the content may want to stop the window from closing because of an error or keep it open while the actions defined in it are performed (e.g. change the dialog content to a progress bar or something similar). I think it's much better to have the OK and cancel buttons controlled by the content than having the oVirt dialog controlling it. > Chris, let me know what you think. > > Note: window.postMessage() should work in IE8 and above, I've tested > [2] in > IE8/WinXP/SP3 without any problems. However, [3] mentions that "In > IE8, it is possible to use win.postMessage for iframes only", I assume > this is what you meant by saying that "it doesn't work across windows > in IE"? Not sure if this is still an issue for us when using iframe > instead of native browser popup window, but we'll have to investigate.. This will not be a problem when we're in an iframe. In fact, that is the only place it will work in IE 8 and 9. > > Regards, > Vojtech > > [1] http://stackoverflow.com/a/2076307 > [2] http://stevesouders.com/misc/test-postmessage.php > [3] http://javascript.info/tutorial/cross-window-messaging-with- > postmessage > > > ----- Original Message ----- > From: "Christopher Morrissey" <Christopher.Morrissey(a)netapp.com&gt; > To: "Vojtech Szocs" <vszocs(a)redhat.com&gt;, engine-devel(a)ovirt.org > Cc: "Itamar Heim" <iheim(a)redhat.com&gt;, "George Costea" > <George.Costea(a)netapp.com&gt; > Sent: Tuesday, January 8, 2013 3:13:44 PM > Subject: Question about closing UI plugin dialog > > Hi All, > > I've been working on a plugin for the UI that launches a dialog using > the > showDialog() API. Our UI is actually contained in a frame inside the > dialog and is loaded from a separate server. The only information > needed for our UI comes in either through the URL as parameters or from the oVirt REST API. > The issue is that once the clicks the OK or Cancel buttons in our UI > we need to message to the oVirt UI to close the dialog. > > It looks like using the window.postMessage() API would be great for > this, but it doesn't work across windows in IE. Would it be possible > to change the code that launches the window to open a window that > contains a bit of javascript that sets up a listener for closing the > dialog and then launches the URL in an iFrame in the window? Of > course, if it were in a native GWT dialog this wouldn't be a problem. > ;) > > -Chris > > Chris Morrissey > Software Engineer > NetApp Inc. > 919.476.4428 >