Refactoring of the Popup plugin

[Olek Nowodziński]

Problems

Popup is a utility used internally by various CKEditor plugins. It does the job but it is pretty useless when there's some complex case to handle.

1. ​http://stackoverflow.com/questions/35493182/how-do-i-control-where-ckeditor-api-opens-a-new-new-window-for-the-filebrowserbr – Popup plugin ​overrides any geometry passed with options argument. So setting editor.config.fileBrowserWindowFeatures is useless, because whatever width|height|top|left is passed there, it will be discarded anyway.

2. ​http://stackoverflow.com/questions/12636638/use-popup-window-to-open-html-document-and-call-methods-elements-within-it (​https://dev.ckeditor.com/ticket/9403) – There is no way to obtain the window handler of the popup. Once it's open, there's no way to customise or control it. DOM does not offer any access to child "popup" windows so the only entry point is the value returned by window.open().

Solutions

1. There are many possible improvements:

1.1. editor.popup() options argument could be a plain object, which can be iterated. If any property is included, then it's not generated by the Popup plugin (like: width in options? – don't calculate it). Drawback: losing backwards compatibility (changed type of an argument).

1.2. editor.popup() options argument remains string but is parsed to object and, as in 1.1., the plugin is smart when it comes to actually using it. This solution does not break backwards compatibility.

1.3. editor#beforePopup event, which passes all window.open() options, which can be intercepted by the listener and customised. It could be an independent feature (unrelated to 1.1. or 1.2.), giving control over any popup window, i.e. not limited to editor.config.fileBrowserWindowFeatures.

2. The plugin could fire editor#popup event with the reference to the new window in the event data. One could listen to the event and intercept it.