Bug 316443

Description Ryan Donnelly 2010-06-10 07:31:55 EDT

I am upgrading from RAP 1.2.1 to 1.2.2 because of the following:

#294981 Several widgets don't work in Firefox 3.6
https://bugs.eclipse.org/bugs/show_bug.cgi?id=294981

and I am running into a problem that causes me to question my WAR deployment procedure:


    In my application, with RAP 1.2.1 as I have it now, in Firefox 3.6.3, for a ToolItem widget with SWT.DROP_DOWN, when I click on the upside-down triangle for the drop-down, nothing happens.  When I upgrade my target platform to 1.2.2, and run in Eclipse, the problem is fixed - the widget works and the dropdown shows.

    However, when I build the application into a WAR and run it under Tomcat, when I click on the widget I get the error:

java.lang.NumberFormatException: For input string: "320.79998779296875"
    java.lang.NumberFormatException.forInputString(Unknown Source)
    java.lang.Integer.parseInt(Unknown Source)
    java.lang.Integer.parseInt(Unknown Source)
    org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBoundsValue(WidgetLCAUtil.java:873)
    org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBoundsX(WidgetLCAUtil.java:853)
    org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBounds(WidgetLCAUtil.java:327)
    org.eclipse.swt.internal.widgets.toolitemkit.DropDownToolItemLCA.readData(DropDownToolItemLCA.java:60)
    org.eclipse.swt.internal.widgets.toolitemkit.ToolItemLCA.readData(ToolItemLCA.java:40)
    org.eclipse.swt.internal.widgets.displaykit.DisplayLCA$1.doVisit(DisplayLCA.java:320)
    org.eclipse.swt.internal.widgets.WidgetTreeVisitor$AllWidgetTreeVisitor.visit(WidgetTreeVisitor.java:28)
    org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(WidgetTreeVisitor.java:59)
    org.eclipse.swt.internal.widgets.WidgetTreeVisitor.handleItems(WidgetTreeVisitor.java:91)
    org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(WidgetTreeVisitor.java:48)
    org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(WidgetTreeVisitor.java:51)
    org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(WidgetTreeVisitor.java:51)
    org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(WidgetTreeVisitor.java:51)
    org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(WidgetTreeVisitor.java:51)
    org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(WidgetTreeVisitor.java:51)
    org.eclipse.swt.internal.widgets.displaykit.DisplayLCA.readData(DisplayLCA.java:327)
    org.eclipse.rwt.internal.lifecycle.ReadData.execute(ReadData.java:26)
    org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.continueLifeCycle(RWTLifeCycle.java:209)
    org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.sleep(RWTLifeCycle.java:312)
    org.eclipse.swt.widgets.Display.sleep(Display.java:790)
    com.lti.swtutils.DispatchLoop.readAndDispatch(DispatchLoop.java:37)
    com.quintron.vx.gui.AppImpl.run(AppImpl.java:1546)
    com.quintron.vx.rwt.WebApp.createUI(WebApp.java:178)
    org.eclipse.rwt.internal.lifecycle.EntryPointManager.createUI(EntryPointManager.java:92)
    org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.createUI(RWTLifeCycle.java:231)
    org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadController.run(RWTLifeCycle.java:119)
    java.lang.Thread.run(Unknown Source)




    Stepping through the code, I can see that running under Eclipse we have an integer here, causing no problem.

org.eclipse.rwt.lifecycle.WidgetLCAUtil.readBoundsValue(WidgetLCAUtil.java:873)

whereas with the WAR/Tomcat we get the non-integer value.



    I can see that there has been work in this area since 1.2.2, such as:

#306842 JS error in TableColumnLCA
https://bugs.eclipse.org/bugs/show_bug.cgi?id=306842

#289336 [ToolBar] Implement new client-side ToolBar
https://bugs.eclipse.org/bugs/show_bug.cgi?id=289336


    Can you shed some light on why I get an integer running under Eclipse and a non-integer running the WAR?  Can I fix this by fixing my WAR deployment procedure or is this likely a bug that was fixed after 1.2.2 or possibly a new bug?  I will open a new bug for the 1.2.2 WAR Deployment procedure, which is unclear to me.



--------------------------------------------------------------
Ralf's comment in response to this question on the newsgroup:


Hi Ryan,

this sounds like a bug. JavaScript doesn't know integers, just numbers.
It seems that there is some rare case that cause a bounds parameter to
be transmitted as a floating point number and we don't handle this case.

It can't be related to Tomcat vs. Jetty. Maybe you have some workbench
layout stored in the settings cookie for the Tomcat server. Could you
open a bug with the stack trace?

Thanks, Ralf