Bug 349021

Comment 1 Steffen Pingel 2011-06-10 09:14:46 EDT

I am also seeing this exception when dropping on the blank editor area:

org.eclipse.swt.SWTException: Failed to execute runnable (org.eclipse.core.runtime.AssertionFailedException: assertion failed: )
	at org.eclipse.swt.SWT.error(SWT.java:4282)
	at org.eclipse.swt.SWT.error(SWT.java:4197)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3563)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3212)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
Caused by: org.eclipse.core.runtime.AssertionFailedException: assertion failed: 
	at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
	at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
	at org.eclipse.ui.internal.ide.EditorAreaDropAdapter.asyncDrop(EditorAreaDropAdapter.java:131)
	at org.eclipse.ui.internal.ide.EditorAreaDropAdapter.access$0(EditorAreaDropAdapter.java:87)
	at org.eclipse.ui.internal.ide.EditorAreaDropAdapter$1.run(EditorAreaDropAdapter.java:81)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
	... 23 more

Comment 2 Benjamin Muskalla 2011-07-20 22:57:36 EDT

Ian, this is a problem of Chromium on Linux which doesn't provide proper data in it's events (in this case, data == null). Chrome on Windows works fine, Firefox on Linux too. Closing this as NOT_ECLIPSE.

Steffen, the exception has not really something to do with MPC. Platform has a drop adapter on the editor area which is more specific than our listeners on the shell (means it comes first). As Platform blindly checks for instanceof String[] and event.data is null, this fails terribly (known bug for years, see 95105, opened bug 352690 to silently ignore id). I had the idea to rethrow the event in case the platform cannot do anything but:
a) rethrowing the event would mean to display#post DNDEvent which is internal to SWT, so we could not even do it with reflection (besides it would be a mess)
b) registering our dropadapter itself on the editor area is not posssible as we'd need to reach into ide internals and break the e4 compatibility with it.

All in all, NOT_ECLIPSE and WONTFIX - platform should take care of proper handling of the input data as part of bug 352690.

Comment 3 Snjezana Peco 2013-11-11 16:33:45 EST

I think this is an Eclipse bug. 

The issue happens because Chrome sets the "text/uri-list" type and html data to a native object that Eclipse recognizes as FileTransfer. However, FileTransfer can't convert a native data object to a Java object if native data are created as html. The end result is that Eclipse creates the DropTargetEvent object that contains a valid type, but doesn't contain any data (event.data=null).

The attached patch solves the issue by adding the "text/uri-list" type to HTMLTransfer.
Since it can happen that transfer data have a type that can't be interpreted by an Eclipse's transfer class, I have also added code to DropTarget that checks a type, but also checks if a transfer object can interpret native data.

See https://issues.jboss.org/browse/JBIDE-15499 for more details.

Comment 4 Snjezana Peco 2013-11-11 16:35:57 EST

Created attachment 237377 [details]
A patch

Comment 5 Carsten Reckord 2014-05-13 15:17:51 EDT

Snjezana, thank you for the patch. I've raised bug 434797 against SWT to get this fixed. Maybe you could attach your patch there? 

One question though: why did you add the "text/uri-list" type to HTMLTransfer? Shouldn't that have gone into URLTransfer instead?

Comment 6 Snjezana Peco 2014-05-14 08:11:52 EDT

(In reply to Carsten Reckord from comment #5)
> Snjezana, thank you for the patch. I've raised bug 434797 against SWT to get
> this fixed. Maybe you could attach your patch there? 
> 
> One question though: why did you add the "text/uri-list" type to
> HTMLTransfer? Shouldn't that have gone into URLTransfer instead?

Because chrome sets html data that is correctly recognized by HTMLTransfer.
I have created https://git.eclipse.org/r/#/c/26513

Comment 7 Carsten Reckord 2014-05-14 08:25:28 EDT

I'll copy this over to bug 434797, so we can discuss there further.

Comment 8 Carsten Reckord 2015-02-11 12:57:54 EST

This was fixed upstream for Mars with current versions of Chrome.

Comment 9 Carsten Reckord 2015-12-16 13:51:50 EST

Cleanup: closing all released fixes.