Community
Participate
Working Groups
There is a bug in the new 'orion.page.delegatedUI' API that uses object references. When an orion.edit.command service wants to open a delegated UI, it calls > editorContext.openDelegatedUI({ uriTemplate, id }) This opens the delegated UI iframe. After that, the delegated UI iframe is expected to post messages to the page, the messages containing one of "status|result|cancelled" fields. However, the page fails to hook up the correct handlers for those fields, so when a delegated UI iframe posts a message, it is immediately closed, and the page never fulfills the action that the UI requested. For 4.0, we need to either: (a) Make this work. (b) Disable the new API and fix bug 410000 in 5.0. This would basically get the Orion page out of the business of communicating directly with delegated UI frames, and instead it would be the plugin's job. I am leaning toward (b) since I would prefer to wait and implement this once correctly rather than introduce a 4.0 API only to deprecate it in the following release.
5.0
I forgot to update this bug until now. Solution (a) was implemented in this commit: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=2f35219 Also added unit tests: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=9550ca7 While writing the tests, I had to refactor editorCommands#_generateEditCommands() to separate Command creation from rendering. I fixed an instance of the "infamous JS loop bug" that was causing every editor command to be rendered with position==100. The fix seems to affect ordering of commands contributed to the 'Tools' menu: although they are still shown an some indeterminate order, it's different after the fix.
