Description Brian de Alwis 2014-04-29 14:24:33 EDT

CSS Engines are expected to return the DOM node corresponding to an element via their #getElement(Object) method.  Ideally an engine should return null for objects that it doesn't support (e.g., the CSSSWTEngine should return null for an AWT/Swing component).  The default implementation, AbstractCSSEngine#getElement(), defers to a configurable IElementProvider instance.  We have an RegistryCSSElementProvider that looks up an element from the extension registry from the "org.eclipse.e4.ui.css.core.elementProvider" extension point.

The problem is that the RegistryCSSElementProvider has no way to know whether an element mapping is appropriate for a given engine.  Thus if you have two different CSS engines that both use a RegistryCSSElementProvider, then it's entirely possible the SWT engine would obtain Swing elements and vice-versa.  I've had this happen with the Modelled Workbench CSS engine, that manipulates the EMF model definition: the SWT engine was handling model objects and the model engine was handling SWT widgets. 

One solution would be to have CSS engines that use the RegistryCSSElementProvider to override their #getElement() method to only handle known object types (e.g., "object instanceof Widget").  But the CSS SWT Engine (AbstractCSSSWTEngineImpl) has some difficulty here as the Eclipse UI Theme bridging support currently requires that the SWT engine be able to handle non-widget elements such as org.eclipse.ui.internal.themes.ThemeDefinitionElement and org.eclipse.core.runtime.preferences.IEclipsePreferences instances so as to propagate color and font definitions.  The CSS SWT engine manages how the properties are applied (i.e., on the SWT thread).

It's probably best that rather than have a single extension point shared amongst all engines to provide object -> element mappings, each engine type have its own extension point.