Community
Participate
Working Groups
While running the CSSSWTEditorWidgets example with the latest code in HEAD, I get the following error trace by trying to change the font-size in the example: java.lang.IllegalStateException at org.apache.batik.css.parser.CSSLexicalUnit.getFloatValue(Unknown Source) at org.eclipse.e4.ui.css.core.impl.dom.Measure.getFloatValue(Measure.java:39) at org.eclipse.e4.ui.css.swt.properties.css2.CSSPropertyPaddingSWTHandler.setPadding(CSSPropertyPaddingSWTHandler.java:150) at org.eclipse.e4.ui.css.swt.properties.css2.CSSPropertyPaddingSWTHandler.applyCSSPropertyPaddingTop(CSSPropertyPaddingSWTHandler.java:90) at org.eclipse.e4.ui.css.core.dom.properties.css2.AbstractCSSPropertyPaddingHandler.applyCSSProperty(AbstractCSSPropertyPaddingHandler.java:24) at org.eclipse.e4.ui.css.swt.properties.css2.CSSPropertyPaddingSWTHandler.applyCSSProperty(CSSPropertyPaddingSWTHandler.java:31) at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.applyCSSProperty(AbstractCSSEngine.java:659)
Reproduced on my end. The computation of default style declarations seems to be causing problems. The snippet below will demonstrate this, just click the button two or more times (as nothing will happen on the first click). If you swap the applyStyles(Object, boolean, boolean) method around, the exception will not occur. ---------- Display display = new Display(); final Shell shell = new Shell(display); shell.setLayout(new FillLayout()); final CSSEngine engine = new CSSSWTEngineImpl(display); engine.setErrorHandler(new CSSErrorHandlerImpl()); Button button = new Button(shell, SWT.PUSH); button.addListener(SWT.Selection, new Listener() { public void handleEvent(org.eclipse.swt.widgets.Event event) { try { // engine.applyStyles(shell, true, false); engine.applyStyles(shell, true, true); } catch (Exception e) { e.printStackTrace(); } } }); shell.setSize(300, 100); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.sleep(); } } display.dispose();
We can prevent this by adding another conditional check at line 609 like so... -if (oldDefaultStyleDeclaration != null) { +if (oldDefaultStyleDeclaration != null && !oldDefaultStyleDeclaration.equals(defaultStyleDeclaration)) { ...but that only hides the problem. I have tried rolling back the changes that I introduced in a patch for bug 282575 but the problem doesn't go away so it doesn't look like AbstractCSSEngine is the culprit.
Created attachment 147065 [details] CSSPropertyMarginSWTHandler patch v1 When push comes to shove, one must climb the stack trace and check the classes one by one. :o I have confirmed that the regression was introduced by bug 284313 between v1.2 and v1.3 of CSSPropertyMarginSWTHandler. http://dev.eclipse.org/viewcvs/index.cgi/e4/org.eclipse.e4.ui/bundles/org.eclipse.e4.ui.css.swt/src/org/eclipse/e4/ui/css/swt/properties/css2/CSSPropertyMarginSWTHandler.java?r1=1.2&r2=1.3 Retrieving the value prematurely seems to be the cause behind the exception. I have attached a patch which will revert this by going back to the old behaviour of retrieving the value as late as possible.
I'll commit this some time this week.
(In reply to comment #4) > I'll commit this some time this week. Maybe not, the patch seems to be insufficient now. There are also problems with CSSValueSWTColorConverterImpl now trying to make a colour out of the string "null".
Remy, the reason I didn't release the patch in yet as it doesn't fix the errors I am seeing in the CSSSWTEditorWidgets example (try switching amongst the various style sheets and you'll see what I mean). As you noted the default style calculation sets a bunch of properties to null, and the parser dies trying to get a float value from null. The right answer is to improve the default value initialization process, but I guess that in the meantime we can always add a null check.
(In reply to comment #6) > As you noted the default style calculation sets a bunch of properties to null, > and the parser dies trying to get a float value from null. The right answer is > to improve the default value initialization process, but I guess that in the > meantime we can always add a null check. This is the stack trace where a "null" CSSValue is passed. This is actually instantiated when the style sheet is parsed for the first time. Since the code is coming from Batik's CSS parser, I'm not sure if there's anything that can be done on our end. The workaround described by comment 2 fixes the problem for the examples but it's hard to say what kind of adverse effects it may have. I think we should investigate 0.9 to see if it was broken then (I hope not). Thread [main] (Suspended (breakpoint at line 38 in CSSPropertyImpl)) CSSPropertyImpl.<init>(String, CSSValue, boolean) line: 38 CSSDocumentHandlerImpl.getCSSProperty(CSSStyleDeclaration, String, LexicalUnit, boolean) line: 222 CSSDocumentHandlerImpl.property(String, LexicalUnit, boolean) line: 216 Parser.parseStyleDeclaration(boolean) line: not available Parser.parseStyleDeclarationInternal() line: not available Parser.parseStyleDeclaration(InputSource) line: not available CSSParserImpl(AbstractCSSParser).parseStyleDeclaration(CSSStyleDeclaration, InputSource) line: 98 CSSParserImpl(AbstractCSSParser).parseStyleDeclaration(InputSource) line: 78 CSSSWTEngineImpl(AbstractCSSEngine).parseStyleDeclaration(InputSource) line: 238 CSSSWTEngineImpl(AbstractCSSEngine).parseStyleDeclaration(Reader) line: 213 CSSSWTEngineImpl(AbstractCSSEngine).parseStyleDeclaration(String) line: 201 CSSPropertyHandlerSimpleProviderImpl.getDefaultCSSStyleDeclaration(CSSEngine, CSSStylableElement, CSSStyleDeclaration, String) line: 272 CSSPropertyHandlerSimpleProviderImpl(AbstractCSSPropertyHandlerProvider).getDefaultCSSStyleDeclaration(CSSEngine, Object, CSSStyleDeclaration, String) line: 38 CSSSWTEngineImpl(AbstractCSSEngine).getDefaultStyleDeclaration(Object, CSSStyleDeclaration, String) line: 579 CSSSWTEngineImpl(AbstractCSSEngine).applyDefaultStyleDeclaration(Object, boolean, CSSStyleDeclaration, String) line: 607 CSSSWTEngineImpl(AbstractCSSEngine).applyStyles(Object, boolean, boolean) line: 319 CSSEditorSWTWidgets(AbstractCSSEditor).applyStyles(Object) line: 105 CSSEditorSWTWidgets(AbstractCSSEditor).applyStyles() line: 124 AbstractCSSSWTEditor$3.modifyText(ModifyEvent) line: 266 TypedListener.handleEvent(Event) line: 167 EventTable.sendEvent(Event) line: 84 StyledText(Widget).sendEvent(Event) line: 1050 StyledText(Widget).sendEvent(int, Event, boolean) line: 1074 StyledText(Widget).sendEvent(int, Event) line: 1059 StyledText(Widget).notifyListeners(int, Event) line: 773 StyledText.setText(String) line: 9454 CSSEditorSWTWidgets(AbstractCSSSWTEditor).setStyleSheetContent(String) line: 581 CSSEditorSWTWidgets(AbstractCSSEditor).fillTextareaWithStyleSheetContent(InputStream) line: 157 CSSEditorSWTWidgets(AbstractCSSEditor).fillTextareaWithStyleSheetContent(File) line: 129 CSSEditorSWTWidgets(AbstractCSSEditor).applyStylesFromSelectedFile() line: 198 CSSEditorSWTWidgets(AbstractCSSSWTEditor).createRightPanel(Composite) line: 467 CSSEditorSWTWidgets(AbstractCSSSWTEditor).display() line: 148 CSSEditorSWTWidgets.main(String[]) line: 116
(In reply to comment #7) > I > think we should investigate 0.9 to see if it was broken then (I hope not). I checked out R0_9, closed my HEAD projects, reran the example, it still spits errors out. :(
I've added a workaround in the examples. We'll have to defer this.
Removing outdated target milestone.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This is a mass change to close all e4 bugs marked with "stalebug" whiteboard. If this bug is still valid, please reopen and remove the "stalebug" keyword.
