Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 419764

Summary:	New delegated UI API is broken
Product:	[ECD] Orion	Reporter:	Mark Macdonald <mamacdon>
Component:	Client	Assignee:	Mark Macdonald <mamacdon>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	eclipse, Michael_Rennie, sirnewton_01
Version:	3.0
Target Milestone:	7.0
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Mark Macdonald

2013-10-17 16:20:03 EDT

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.

Comment 1 Mark Macdonald

2013-10-25 18:13:29 EDT

5.0

Comment 2 Mark Macdonald

2014-10-15 12:34:09 EDT

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.