Project

General

Profile

Bug #4523

JSignal unmarshalling fails with latest chrome version (45.0)

Added by Gaetan Hug over 6 years ago. Updated over 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
10/23/2015
Due date:
% Done:

0%

Estimated time:

Description

The exception listed at the bottom of this issue description got thrown in specific when scrolling in a WTableView that was displayed in a zoomed out chrome tab.

Further testing showed that:

  • the same exception is thrown when the tab is zoomed in
  • the exception is not thrown in firefox

This is seems to be caused by the fact that the javascript event arguments passed by chrome are now non-integer values wether they still are for Firefox.

This has been tested only with jWt v3.3.3 but may affect newer versions.

Chrome User agent string:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36

Firefox User agent string:

Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0

Thrown exception and stack trace:

eu.webtoolkit.jwt.WtException: JSignal: scrolled: could not interpret argument 1 ('117.77778089782346') as type java.lang.Integer
    at eu.webtoolkit.jwt.AbstractJSignal.unMarshal(AbstractJSignal.java:76)
    at eu.webtoolkit.jwt.JSignal4.processDynamic(JSignal4.java:130)
    at eu.webtoolkit.jwt.WebSession.processSignal(WebSession.java:1830)
    at eu.webtoolkit.jwt.WebSession.notifySignal(WebSession.java:1937)
    at eu.webtoolkit.jwt.WebSession.notify(WebSession.java:470)
    at eu.webtoolkit.jwt.WApplication.notify(WApplication.java:2838)
    at eu.webtoolkit.jwt.WebSession.handleRequest(WebSession.java:1553)
    at eu.webtoolkit.jwt.WtServlet.doHandleRequest(WtServlet.java:361)
    at eu.webtoolkit.jwt.ServletApi.handleRequest(ServletApi.java:27)
    at eu.webtoolkit.jwt.ServletApi3.doHandleRequest(ServletApi3.java:98)
    at eu.webtoolkit.jwt.WtServlet.handleRequest(WtServlet.java:255)
    at eu.webtoolkit.jwt.WtServlet.doPost(WtServlet.java:271)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:562)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:395)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:250)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:188)
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:302)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)
#1

Updated by Wim Dumon over 6 years ago

Hello Gaetan,

Browsers have indeed changed their behaviour wrt this point. If you upgrade your JWt version to the 3.3.5 release candidate, this problem will go away.

Best regards,

Wim.

Also available in: Atom PDF